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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA and TiMidity++
From: Likai Liu (news_AT_likai.net)
Date: Thu Sep 19 2002 - 06:10:43 EEST


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

_______________________________________________
linux-audio-dev mailing list
linux-audio-dev_AT_music.columbia.edu
http://music.columbia.edu/mailman/listinfo/linux-audio-dev


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Sep 19 2002 - 06:24:56 EEST