Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

[linux-audio-dev] [ANN] QJackConnect 0.0.1

by Dr. Matthias Nagorni

Hi, QJackConnect 0.0.1, a QT based patchbay for JACK, is available from http://www.suse.de/~mana/jack.html or ftp://ftp.suse.com/pub/people/mana/qjackconnect-0.0.1.tar.bz2 This is the first official release (some pre releases have been already in use, but they were based on a bad hack) and its published under GPL. Thanks to Kai Vehmanen for sending a patch which adapts QJackConnect to the current CVS of JACK and finally resolves the bad hack. I also wrote a small FM synthesizer which is both a (minimal) client to JACK and the ALSA sequenzer system. jack_miniFMsynth.c is available from the QJackConnect webpage as well. Have fun ! Matthias -- Dr. Matthias Nagorni SuSE GmbH Deutschherrnstr. 15-19 phone: +49 911 74053375 D - 90429 Nuernberg fax : +49 911 74053483

22 years, 10 months

[linux-audio-dev] anyone interested in porting a GPL'ed VST plugin?

by Paul Davis

it shouldn't be *too* difficult ... ------- Forwarded Message Date: Mon, 04 Nov 2002 20:41:11 +0100 From: "Philipp Mott" <pmott(a)lisa.de> To: <vst-plugins(a)lists.steinberg.net> (VST PlugIns) Subject: [vst-plugins] Rumpelrausch free source code release Hi everyone, I finally decided to release one of my plugins as open source. You can use the sources of ZR-3 under the restrictions of the GNU Public Licens e. And you can (please) donate, if you like. ZR-3 makes the world a better place.. . ;-) Check here: http://rumpelrausch.de.vu/ (ZR-3 is a drawbar organ emulation including effects) ############################################################# This message is sent to you because you are subscribed to the mailing list <vst-plugins(a)lists.steinberg.net>. To unsubscribe, E-mail to: <vst-plugins-off(a)lists.steinberg.net> To switch to the DIGEST mode, E-mail to <vst-plugins-digest(a)lists.steinberg.net > To switch to the INDEX mode, E-mail to <vst-plugins-index(a)lists.steinberg.net> Send administrative queries to postmaster(a)steinberg.de ------- End of Forwarded Message

22 years, 10 months

RE: [linux-audio-dev] anyone interested in porting a GPL'ed VST p lugin?

by Stoll, Jake

If I have the time (in a week or so) I'll have ago. It'd be nice to have as a ladspa plugin but to do the gui justice it might also need to be a jack client? jake. > -----Original Message----- > From: Paul Davis [mailto:paul@linuxaudiosystems.com] > Sent: Tuesday, 5 November 2002 8:43 AM > To: linux-audio-dev(a)music.columbia.edu > Subject: [linux-audio-dev] anyone interested in porting a GPL'ed VST > plugin? > > > it shouldn't be *too* difficult ... > > ------- Forwarded Message > > Date: Mon, 04 Nov 2002 20:41:11 +0100 > From: "Philipp Mott" <pmott(a)lisa.de> > To: <vst-plugins(a)lists.steinberg.net> (VST PlugIns) > Subject: [vst-plugins] Rumpelrausch free source code release > > Hi everyone, > > I finally decided to release one of my plugins as open source. > You can use the sources of ZR-3 under the restrictions of the > GNU Public Licens > e. > And you can (please) donate, if you like. ZR-3 makes the > world a better place.. > . ;-) > > Check here: > http://rumpelrausch.de.vu/ > > > (ZR-3 is a drawbar organ emulation including effects) > > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list <vst-plugins(a)lists.steinberg.net>. > To unsubscribe, E-mail to: <vst-plugins-off(a)lists.steinberg.net> > To switch to the DIGEST mode, E-mail to > <vst-plugins-digest(a)lists.steinberg.net > > > To switch to the INDEX mode, E-mail to > <vst-plugins-index(a)lists.steinberg.net> > Send administrative queries to postmaster(a)steinberg.de > > > > ------- End of Forwarded Message > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

22 years, 10 months

None

by None

January 22, 1998 From: Dan Timis <timis(a)museresearch.com> To: <linux-audio-dev(a)music.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by roar.music.columbia.edu id gA55dDA19818 Subject: [linux-audio-dev] Job in the Bay Area (Menlo Park) Sender: linux-audio-dev-admin(a)music.columbia.edu Errors-To: linux-audio-dev-admin(a)music.columbia.edu X-BeenThere: linux-audio-dev(a)music.columbia.edu X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: linux-audio-dev(a)music.columbia.edu List-Help: <mailto:linux-audio-dev-request@music.columbia.edu?subject=help> List-Post: <mailto:linux-audio-dev@music.columbia.edu> List-Subscribe: <http://music.columbia.edu/mailman/listinfo/linux-audio-dev>, <mailto:linux-audio-dev-request@music.columbia.edu?subject=subscribe> List-Id: The Linux Audio Developers' Mailing List <linux-audio-dev.music.columbia.edu> List-Unsubscribe: <http://music.columbia.edu/mailman/listinfo/linux-audio-dev>, <mailto:linux-audio-dev-request@music.columbia.edu?subject=unsubscribe> List-Archive: <http://music.columbia.edu/pipermail/linux-audio-dev/> X-Original-Date: Mon, 4 Nov 2002 21:35:37 -0800 This may not be a perfect fit with Linux Audio Developers, but there is no Linux Audio Administrators list. If you are not interested directly you may know someone who is. Here it is: ---------- Advanced Systems Programmer Job Requirements Muse Research, a startup music and audio products company located in Menlo Park, is looking for a self-motivated and creative Systems Programmer. Muse is developing cutting edge software/hardware devices for musicians and needs your Linux and system administration skills. Responsibilities Linux Maintenance: Keep customized Linux build up to date and adapt it to hardware requirements Make sure our Linux is optimized for performance and provides the tools users need Work with hardware driver contractors to install their drivers and verify their work Work with hardware team to develop shell scripts or find programs to test hardware functionality System Administration: Perform light administration on small office LAN Help with software installation and hardware troubleshooting Set up and maintain web based applications a bug database, CVS, etc

22 years, 10 months

[linux-audio-dev] amp modelling

by Stuart Allie

Steve wrote: > Date: Sun, 3 Nov 2002 16:39:02 +0000 > From: Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> > Yeah, I'm thinking we're not tackling it right, if behringer can knock out > a virtual amp harware box for E150 it can't the that cycle hungry. There's a good chance I could get my hands on a Behringer V Amp 2 for as long as I need it. If I did, I'd be able to run whatever signal I liked through it and try different amp/speaker settings, different gain levels, etc. and produce a lot of data that would hopefully be of use in trying to produce some sort of "amp modelling" ladspa plugin. I'm open to suggestions as to what would be the most useful things to measure, and what to vary across measurements. My first thoughts were: - a range of pure tones, say starting at 440Hz and going up 3 octaves, - ~5 gain levels, - ~5 amp/speaker simulations, That'd give us 100 "data points" to work with when it comes to testing our models. Comments anybody? Stuart

22 years, 10 months

[linux-audio-dev] Help on threads needed

by Dave Griffiths

Hi all, I'm just trying to tweak SpiralSynthModular's threads to be a bit more efficient, and I can't seem to find much info regarding thread priorities and such. I have two threads, a GUI one and an audio one. I can hand the audio thread over to Jack which works fine, but I'd also like to be able to run ssm in normal user mode and standalone without jack. I think I have two questions: 1. Is there any way to prioritise the threads running as a normal user (SHED_OTHER) my man pages suggest not, which is quite annoying. Should I "nice" the GUI thread down in priority? 2. What is the correct setup for SHED_FIFO? What priorities should I run the audio and GUI threads at, and should the GUI thread use SHED_FIFO too? Thanks for putting up with my ignorance :) Dave : www.pawfal.org :

22 years, 10 months

Re: [linux-audio-dev] Re: [ardour-dev] hardware requirements...

by Patrick Shirkey

How did this end up here? Anyway based on the discussion had so far in this thread I have updated the JACK user Howto to be more precise and yet somehow broader and muddier at the same time :) -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

22 years, 10 months

Re: [linux-audio-dev] ok, jump on slashdot right now, ALSA story in progress

by Patrick Shirkey

>I wouldn't go as fas as to blame any developers for this. ALSA is being >integrated in the mainline kernel and that by itself should keep >everyone busy. >I think its somehow the duty of the people who figured out how to >configure it in an easy way to write it up (cfr. Patricks quicktoots >section). >I'm willing to do just that. >The question is, what is the best place to write these things up ? >Do I start to work on Debian specific documentation, or is it better to >help on some general alsa documentation ? I think it would be best to have this info in the alsa-docs. Here's what I consider still needed to make the alsa-docs complete: - A paragraph on using alsaconf. - Anything that is distro specific. Although it might be better to make a page for this which people can add notes to. - Any info on using the controls for cards that have them. Specifically adat, wordclock, optical. I would like to have a section in the template for this but don't have any cards that use these so cannot test myself. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

22 years, 10 months

Re: [linux-audio-dev] Interesting USB MIDI master keyboards, do they

by John Lazzaro

work with Linux ? > Tim Goetze <tim(a)quitte.de> writes: > > there's a difference though: the usb 1 ms is jitter, there's no way > to reconstruct the original timing. this in contrast to midi, where > you can extrapolate the exact event time quite well (provided you're > looking at a stream of mostly isolated events). oh well, most people > think 1 ms is below human perception limits anyway. People who are into this topic might want to take a few minutes to review Appendix C.1 (pp 66-70) of the MWPP draft: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt It basically describes the three methods MWPP provides for coding timestamps onto MIDI commands when packetizing a MIDI stream. The goal is that whatever your MIDI source is (a MIDI 1.0 DIN jack, an algorithmic composition program, etc), one of these three methods will be the right one to capture the timing as best as can be, into an RTP packet. Feedback is welcome on the topic, we're starting to close in "Last Call" for the document, but there is still a few months left ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 10 months

Re: [linux-audio-dev] Interesting USB MIDI master keyboards, do they work with Linux ?

by Benno Senoner

Hi, I meant of sending midi events from the master keyboard via USB to the PC which runs an internal soft-synth/sampler. In that case USB should improve timing because of the bigger bandwidth, (but will add 1msec of latency due to USB1 polling mechanism as far as I can understand). Correct me if I'm wrong. cheers, Benno You wrote: ----- > Ok if the Edirol keyboards support standard MIDI then there shouldn't be any > problems using them under Linux, but since USB has a much bigger bandwidth > than serial MIDI, I that the timing for notes that belong to large chords is > more precise. Can someone confirm this ? Not really, unless you are spreading those chords on several separate midi outputs. If it just one, then it determines the bandwidth available. Getting things faster to the interface will do nothing because it still has to send the bytes to the external synth at the same old slow 31250 baud speed. ----- -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

22 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev