19 Sep
2002
19 Sep
'02
4:09 p.m.
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