On Thursday 19 Sep 2002 04:10, Likai Liu wrote: > 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. That's why I was proposing to use NRPNs.
> Only programs that are specifically > designed to manipulate LADSPA network in TiMidity++ would be able to > take advantage of that feature anyways. Err, the whole point is so I can control the LADSPA plugins from my controller keyboard. Any MIDI controller would be able to do the same. > 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. That's fine if you're controlling TiMidity++ etc from a PC - but how do I fix up the pipeline from my controller keyboard? Also, I don't want to store the rendered output, I want to store the MIDI performance. [snip] > 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. That depends on a number of factors (e.g. how much RAM you have). It's not something that's bothering me at the moment. I'm not skilled enough to be switching patches mid-play :-). > 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' * I only have two soundfonts to worry about - but I guess they get paged on demand, too. > > liulk -- Peter _______________________________________________ linux-audio-dev mailing list [EMAIL PROTECTED] http://music.columbia.edu/mailman/listinfo/linux-audio-dev
