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

[David Olofson]

On Tuesday 17 September 2002 20.33, Peter L Jones wrote:
> Hi there,
>
> Do you (or the list) happen to know if anyone has considered making
> TiMidity++ a LADSPA host?

Can't remember hearing anything like that...

BTW, considering that timidity (AFAIK) was originally designed as an 
off-line rendering tool, more than a real time synth, how well does 
it work in a real time environment?

(I'm talking about low latency mixing with live MIDI input, rather 
than playing back MIDI files with a large audio buffer. And no, I 
don't know how well timidity performs in this regard. Just pointing 
out some potential issues to keep in mind with any soft synth setup, 
basically.)


> I was thinking it might be fun to have a midi sequencer with a
> rather large library of MIDI controllers.  I was thinking of using
> Non-Registered Parameters - one to select the LADSPA plug in (by
> number), one to set its position in the plugin chain, and as many
> more as is required to control it

That sounds a lot like what I'm doing right now, in what's to be 
released as the *real* Audiality Engine (*). The "new" engine is 
formerly known (or probably not!) as the "unnamed audio engine of 
Kobo Deluxe", and is the reason why you get three songs with custom 
sound for practically no increase in download size. (Oh, there are 
some 100 instruments included in the package as an extra bonus.)

Anyway, I'm still using a hacked up MIDI loader/player from an AdLib 
games music player, and although the engine has it's own event 
system, the "musician's interface" is obviously MIDI, whether it's in 
a file or comes in as a live MIDI stream.

Being that I don't seriously believe in MIDI as a standard to design 
new stuff around, I've just kept things very simple on the MIDI side. 
I've mapped a bunch of normal MIDI CCs (no NRPNs - it's hairy enough 
without yet another "level of indirection"!) to mixer/routing 
control. I'm sort of abusing this set of CCs, and the MIDI channels, 
to adress the mixer busses and their insert slots.

Here's some docs from the source: (Particularly note the mess that is 
mapping 0..127 to useful ranges... *heh*)

 *	The control routing model:
 *
 *		         Group
 *		         ^   |
 *		         |   V
 *		MIDI -> Channel -> Patch ---> Voice
 *		 |                        |-> Voice
 *		 V                        ...  ...
 *		Bus Control               '-> Voice

Note that "Channels" are just plain interfaces to the system. The 
"Patch" is in fact a plugin, which may do whatever it likes with 
events sent to the Channel - although the most common setup is that 
events are mapped to one or more audio Voices. (There is a patch 
plugin that plays MIDI files as "instruments", though. In fact, 
that's the very interface to the MIDI sequencer; to play a song, you 
select the MIDI file as "waveform", and just play it as a note.)

Further;

 * Bus Control:
 *	The first 8 MIDI channels can be used for controlling
 *	the signal processing done between the busses, and
 *	between the busses and the output buffer.

(Note: "8" is an arbitrary limit. Dynamic allocation of Busses and 
Channels is high on the TODO. Required to reach the "MIDI plays MIDI" 
milestone without kludges, as MIDIs must have private domains in 
engine space.)


 *	A set of non-standard MIDI CCs are used for this:
 *		CC 39: Select Insert Slot for subsequent CCs.

(Each bus has a chain of plugins, with sends "in all directions" in 
between each plugin. Using CC 39, you select which slot to control 
with the CCs below.)


 *	Slot 0 is used to access the dry/pre insert send level
 *	controls. Thus, CCs 40..45 are ignored for slot 0.
 *
 *	The FX parameter CC range is mapped to according to
 *	[0, 128] ==> [0.0, 2.0]. (That is, you can't reach the
 *	exact value of 2.0, as the highest CC value is 127.)
 *		CC 40: Insert Effect Type
 *		CC 41: Insert Effect Parameter 1 (Time 1)
 *		CC 42: Insert Effect Parameter 2 (Time 2)
 *		CC 43: Insert Effect Parameter 3 (Depth 1)
 *		CC 44: Insert Effect Parameter 4 (Depth 2)
 *		CC 45: Insert Effect Parameter 5 (Rate)
 *
 *	This one is not transformed at all - MIDI CCs 0..127
 *	are used directly. Obviously, it's preferred that
 *	plugins map integer parameters that fit in that range
 *	to Parameter 6.
 *		CC 46: Insert Effect Parameter 6 (Mode/Special)
 *
 *	The following CC doubles as "dry send to master", when
 *	used on slot 0.
 *		CC 47: Post insert send to master ("Wet")
 *
 *	The next set of CC are IMHO, a bit dodgy in the current
 *	implementation. Indeed, they work, but you have to
 *	accept that the engine processes the busses in a fixed
 *	order, meaning that you can only send from lower number
 *	busses to higher number busses - not the other way
 *	around. (In fact, the engine won't even consider the
 *	controls for the "broken" connections when mixing.)

(The aforementioned dynamic Bus allocation will eliminate this 
restriction, as an extra bonus. It has to, as you can't control the 
physical order of Busses when you allocate them dynamically.)


 *	Note that when used on slot 0, these act as *dry* send
 *	levels, as there cannot be an insert in slot 0.
 *		CC 48: Post insert send to bus 1
 *		CC 49: Post insert send to bus 2
 *		CC 50: Post insert send to bus 3
 *		CC 51: Post insert send to bus 4
 *		CC 52: Post insert send to bus 5
 *		CC 53: Post insert send to bus 6
 *		CC 54: Post insert send to bus 7
 *		CC 55: Post insert send to bus 8
 *
 *	Note that the post insert sends won't be considered
 *	if no effect is enabled. (They would just double the
 *	functionality of the pre insert sends, for extra cost
 *	and no use.)


> - unless someone fancies getting
> the LADSPA plugins allocated numbers by the MIDI Manufacturers
> Association...

Well, I think the time would be better spent working on a serious 
control interface, for plugin APIs as well as various hardware links. 
IMHO, MIDI's lack of feedback (you can't ask units about things, 
unless you have two cables - and that's not really part of the 
standard), low bandwidth in it's h/w form, limited resolution, the 
per-channel note ID == note pitch restriction etc etc, makes it a 
major PITA for this kind of stuff.


> I did an archive search on "timidity" and found nothing -- is
> software sequencing off topic or is there somewhere else I should
> go to discuss changes to TiMidity++?

I would assume the timidity list is the right place for timidity 
specific discussion. (Not on it, and I'm off-line, so I can't check 
the info easilly. I'm a lazy bastard; sorry. ;-)

As to "software sequencing on LAD" in general though, I would believe 
that's about as ON topic as it gets! :-)


//David

(*) The name "Audiality" has been used for two former projects; a
    Win16/Win32 audio sequencer that I dropped for obvious reasons,
    and an RTLinux based audio engine core that was quickly rendered
    obsolete when Linux/lowlatency came around.

    It turns out that when I start porting/modifying an old X game,
    the planless hacking around in it's sound effects mixer eventually
    results is something very close to what I originally intended
    with several former, "serious" projects...! (Yes, it contains
    working implementations of some major concepts of MAIA as well.
    It also contains an off-line waveform rendering engine, driven by
    a custom scripting/programming language.)

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