[linux-audio-dev] LADSPA and TiMidity++

Likai Liu news at likai.net
Thu Sep 19 03:10:43 UTC 2002

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' *


More information about the Linux-audio-dev mailing list