On Tuesday 17 September 2002 20.33, Peter L Jones wrote: 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.) 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.) 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 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 -'