My response to all above discussion about LADSPA and TiMidity++, I've been playing with TiMidity++ for a while, and hacked it a bit as well. For what I think, given the complexity of internals, it is not worth making TiMidity++ an LADSPA host and having to add some TiMidity++ specific MIDI controller events. Only programs that are specifically designed to manipulate LADSPA network in TiMidity++ would be able to take advantage of that feature anyways. An alternative is to make TiMidity++ a jack client, and then you can pipe jack output to an LADSPA network if you wish, via maybe ardour.
It might be even easier and better to just strip off a part of TiMidity++, fork the part, clean up the code, and make it output to jack each individual MIDI channels without mixing them down. Someone will then write a jack multitrack mixer to process these channels through LADSPA network, and perform the final mixdown. I'd like to say I'm that someone to do it, but unfortunately I can't. David Olofson wrote: >Well, buffering is obvious, but there's a *lot* more than that to it, >if you want reliable real time performance. It's all about the design >of the synth engine; chosing determinism before faster average speed, >avoiding (standard) dynamic memory allocation, avoiding certain ways >of talking to devices and other processes etc... > > by the way, since you mentioned it, there is a big flaw in TiMidity++ when it is used as a real time synthesizer. when you start playing midi and it uses some patch or sound sample that was not previously used, then TiMidity++ loads that patch/soundfont from disk into memory, but it takes too much time to do so! You really can hear a blip when that happens. One way to reduce the chance (but not totally eliminate) to that situation is to preload all patches into kernel buffer by something like: grep -r 'yaddi yadda' * liulk _______________________________________________ linux-audio-dev mailing list [EMAIL PROTECTED] http://music.columbia.edu/mailman/listinfo/linux-audio-dev
