19 Sep
2002
19 Sep
'02
1:12 a.m.
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