[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' *
liulk
More information about the Linux-audio-dev
mailing list