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

[David Olofson]

On Thursday 19 September 2002 05.10, Likai Liu wrote:
> 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.

Not if you implement the MIDI "interface" in a sensible way. It would 
be just like your average studio sampler.


> 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.

Well, it would have to "mix down" voices into one output for each 
MIDI, but that should be more or less trivial.


> 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.

Couldn't one of the existing applications serve as a mixer in such a 
setup?


> 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.

Uh oh...


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

Yeah, but that doesn't sound very reliable - and it doesn't eliminate 
the dependency on the file system (which, AFAIK, still means that 
other applications can interfere), and it doesn't eliminate the need 
for timidity to load, parse and "install" the sound. If the patch 
happens to drag in a few MB of data, you're in trouble...

I think the only proper solution is to load patches directly when 
Program Change is received (unless that's what it's doing already - 
would make sense), and perform the actual loading in a separate 
thread. When the data is ready for playback, the "patch butler 
thread" can just push a pointer onto a lock-free FIFO or something, 
so the real time engine can install it next time it wakes up, or when 
it's time to play the first note with it.

The only remaining problem is that the MIDI file played on your 
"external" sequencer can't possibly know how long it takes to load a 
sound. Then again, even studio synths like Roland JV-1080 (which has 
a single RISC CPU - no MCU to blame...) needs a few tens of a second 
to "load" a patch!

What you do as a composer is simply make sure you send Program 
Changes some time before the first note is played. I generally select 
one patch for each MIDI channel, as the first event of each track, 
and then just skip the first bar. Even a sampler should have time to 
load "normal" sounds in that time...

As to the resulting MIDI files (if you actually release those), this 
shouldn't be a problem, as timidity should use sufficient buffering 
while just playing back MIDIs. The current loading method should work 
just fine for that.


//David

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`---------------------------> http://www.linuxdj.com/maia/ -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'