On Tue, 3 Dec 2002 01:11:11 -0800 (PST) Tim Hockin <thockin(a)hockin.org> wrote: Thats the way. I don't think its smart to try and make one app which does everything. However multiple apps work togther and share components like libsndfile and Secret Rabbit Code is the way to go. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "Perl : this is a blue collar language" - Angus Lees

(Commenting on my own reply. Just thinking too much as usual. :-) Maybe I should point out that a_plugin_t is the *instance* type for an Audiality plugin. Currently, I use a single entry to instantiate a plugin. Example: void delay_init(struct a_plugin_t *p) { p->state = delay_state; p->control = delay_control; p->process = delay_process; p->process_r = delay_process_r; } I suppose one could add a state FX_STATE_VOID (or something) below FX_STATE_CLOSED, and move instantiation and destruction (which is a NOP as of now, as the host manages the a_plugin_t structs) into the state() callback. Then just export the state() call, instead of an extra init func. (Or use a "fake" state() call if desired, which installs the real one in the provided a_plugin_t struct - coder's choice.) However, one should probably have some more arguments for the init calls, to support multiple plugins, variants and stuff in a single .so - so I guess it's better kept the way it is... :-) //David Olofson - Programmer, Composer, Open Source Advocate .- Coming soon from VaporWare Inc...------------------------. | The Return of Audiality! Real, working software. Really! | | Real time and off-line synthesis, scripting, MIDI, LGPL...| `-----------------------------------> (Public Release RSN) -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 03 December 2002 22.58, Tim Hockin wrote: [...unique IDs...] Well, a guaranteed unique ID is really rather handy when you want to load up a project on another system and be *sure* that you're using the right plugins... That's about the only strong motivation I can think of right now, but it's strong enough for me. Now, you could claim that author, plugin name and version should do, but there are no guarantees... Unless you throw a unique author ID in there *as well*. How about this: int author_id; /* Plugin author's unique ID */ const char *name; /* Plugin name */ int version; /* 8:8:16 major:minor:patchlevel */ (And then whatever optional data you may want, which is not considered by the host.) Plugins are assumed to be compatible/equivalent if all of the following are true: * They have identical author_id fields. * They have identical names. * They have identical major version numbers. When loading a net, the host must also ensure that the minor version numbers of loaded plugins are equal to, or greater than the minor versions in the net description. (Older minor verisons may lack features, but newer versions should only *add* capabilities, that shouldn't matter unless you use them. New major number effectively means that you have a new, different plugin.) [...variable # of ins and outs...] IMHO, plugins should not worry about whether or not their outputs are connected. (In fact, there are reasons why you'd want to always guarantee that all ports are connected before you let a plugin run. Open inputs would be connected to a dummy silent output, and open outputs would be connected to a /dev/null equivalent.) Indeed, one could use the "connected"/"not connected" info of ports as some kind of interface to the plugin, but to me, it seems way too limited to be of any real use. You still need a serious interface that lets you configure the internals of the plugin the way you want, just like you program a studio sampler to output stuff to the outputs you want. This interface may be standardized or not - or there may be both variants - but either way, it has to be more sophisticated than one bit per output. I think there should be as little policy as possible in an API. As in; if a plugin can assume that all ins and outs will be connected, there are no special cases to worry about, and thus, no need for a policy. Note that you can still tell the host that you can have anything from 1 through 16 outputs. The plugin may do whatever it likes when the host says "i want only one out" - including being "smart" about the internal routing, disregarding any user presets. (Some hardware boxes seem to do this in some cases, but it seems to be meant more as a helper when you're in that "where the h*ll is my signal!?" situation in the studio. A good software studio would let you turn on various indicators and meters all over the place instead, and preferably also provide a "Free Listen" feature that lets you monitor anything you click on.) Strongest resason *not* to use multichannel ports: They don't mix well with how you work in a studio. If something gives you multiple channels as separate mono signals, you can connect each one wherever you want, independently, which gives you total control without the need for the rest of your plugin chain to understand any multichannel formats. Strongest reason *for*: When implementing it as interleaved data, it may server as a performance hack in some situations. It is still unclear to me, though, whether or not this applies to "your average plugin" in a real virtual studio, and even if it does, whether the complexity/performance ration is anywhere near justifiable. (I suspect not.) Like on a studio mixing desk; little notes saying things like "bdrum", "snare upper", "snare lower", "overhead left", "overhead right" etc. In a plugin API, you could standardize the way of "naming" these in some way, such as always marking things MONO, LEFT, RIGHT, CENTER, BLEFT, BRIGHT, SUB etc etc. Use a string, or a struct with some enums, or whatever; just put it in the API, so hosts can make sense of it. Point being that if the host understands the labels, it can figure out what belongs together and thus may bundle mono ports together into "multichannel cables" on the user interface level. [...] Well, that's the hard part with APIs. Sometimes you forget to consider the implications that minor API changes may have upon implementations. :-) Well, I don't quite understand the voice_ison() call. I think voice allocation best handled internally by each synth, as it's highly implementation dependent. If you want more direct ("tracker style") control over voices, just use monophonic patches, or use some kind of "note ID" system that lets you address individual notes. In Audiality, I'm currently using actual voice numbers + "owner fingerprints" (channel numbers, IIRC) as note IDs, but that means you have to wait until the voice is actually allocated until you know your voice ID. Not a major problem within the engine core (*), but it means you can't keep track of individual notes from, say, another machine over LAN. Starting a voice and getting it's ID (so you can control the voice) requires a client/engine roundtrip, and that's a bad idea in a distributed real time system... (*) Actually, there is one minor problem: Voice allocation/stealing is restricted to buffer granularity, since when someone in the net allocates a voice, there is no guarantee that that voice doesn't belong to someone that runs *later* in the net. This hasn't been a real problem so far, but I dot't like it. I want *everything* sample accurate! ;-) What I'll do in some future version is probably let each channel allocate a range of Virtual Voice IDs (plain integers; 0..N-1), and then have the engine keep track of these VVIDs on a per-channel basis. That way, a channel can always rely on it's allocated VVIDs to be valid - whether or not they have real voices connected to them. In fact, this potentially enables the engine to "unsteal" voices - not that I know if that would be worth the effort. (Normally, you should just get more power when you run out of voices... Voice stealing - however elegant - is just a brutal overload handling system.) "None of those, but instead, anything" would be my suggestion. I think it's a bad idea to "hardcode" a small number of controls into the API. Some kind of lose "standard" such as the MIDI CC allocation, could be handy, but the point is that control ports should just be control ports; their function is supposed to be decided by the plugin author. [...] Yeah, that's required. Should be handled on the UI level, IMHO. (See above.) Doing it down here only complicates the connection managment for no real gain. Yeah... But this is one subject where I think you'll have to search for a long time to find even two audio hackers that agree on the same set of data types. ;-) Just a note here: Most real instruments don't have an absolute start or end of each note. For example, a violin has it's pitch defined as soon as you put your finger on the string - but when is the note-on, and *what* is it? I would say "bow speed" would be much more appropriate than on/off events. Well, yes. There *has* to be a set of basic types that cover "anything we can think of". (Very small set; probably just float and raw data blocks.) I'm thinking that one might be able to have some "conveniency types" implemented on top of the others, rather than a larger number of actual types. Dunno if this makes a lot of sense - I just have a feeling that keeping the number of different objects in a system to a functional minimum is generally a good idea. What the "functional minimum" is here remains to see... Yeah, I know. It's just that I get nervous when something tries to do "everything", but leaves out the "custom format" fallback for cases that cannot be forseen. :-) Right. I think we can conclude that "raw data block" is not a replacement for strings, but either a special kind of strings, or a different type entirely. Well, you can put stuff in external files, but that seems a bit risky to me, in some situations. Hosts should provide per-project space for files that should always go with the project, and some rock solid way of ensuring that 1) all required files can be found and stored in an archive, for moving a project to another system, or for backup, and that 2) users don't accidentally edit global data used by other projects while working with a project. (This is where the per-project file space comes in.) [...] I totally agree. I'm not suggesting that the actual MIDI protocol should be used in any way in the API. (Although people on the VST list seem to believe MIDI is great as a control protocol for plugins, it's never going into another plugin API, if I can help it... What a mess - and how many plugins actually implement more than the most basic stuff? *heh*) See above. (And note that I'm not so sure about the "external data" part, actually. I just think the ID is required for user data portability reasons.) The string has to be unique. Just Google for some common "unique" brand names, and you'll see what I'm worried about. :-) *hehe* Well, no, the size of strings won't matter - and unless I'm missing something, nor does the overhead of "parsing" them. [...] Yes, definitely. A plugin must be able to have anything from 0 and up of each, independently. But I prefer to see it as M mono ins and N mono outs, labeled in a standardized and sensible way, so you and the host know what they are. Right - but I'm *am* talking about limits. :-) If you have a heavily optimized mixer plugin, it's rather likely that it will only support say, 8 busses (no loop for bus sends!), but "any" number of strips. How do you describe that using the same limit for both strip insert loops and bus (or master) insert loops? [...] So do I. I'm just trying to base my examples on well known equipment and terminology. Multichannel == multiple mono ins and/or outs... That's how you do it in analog, and it's how most plugin APIs (of the kind we're discussing here) do it. It's simple and very flexible. /* * Plugin States * Hosts are allowed to inc/dec the FXC_STATE control * by only 1 unit at a time. If you want to "leap", you * must work through the the states in between, to allow * the plugin to do the required actions for each * transition. The toolkit function a_plugin_state() * handles this automatically. * * This arrangement makes it easier to implement plugins; * just check whether the incoming FXC_STATE argument is * higher or lower than the current value, to select one * of two switch() statements; one with code for entering * states, and another for leaving states. * * What To Do in the case of a transition from... * CLOSED to OPEN: * Create private instance user data, and set * p->user to point at it. * * OPEN to READY: * Allocate larger buffers, and buffers that * depend on system parameter settings. * * READY to PAUSED: * Here you're *not* supposed to do anything * that couldn't be done in "interrupt context" * or similar, as this change may be made from * within the actual real time engine core. * Preferably, any time consuming buffer * clearing and stuff should be done in the * OPEN -> READY and PAUSED -> READY * transitions instead of here. * * PAUSED to RUNNING: * RUNNING to PAUSED: * In most cases, you should do absolutely * nothing here. If your plugin cares about the * world outside, these transitions can be used * to manage the real world/engine time slip * when pausing. * * PAUSED to READY: * Now you may kill reverb tails and that sort * of things. * * READY to OPEN: * Free any system parameter dependent buffers. * Basically, free everything except what you * need to store any incoming system parameter * values. * * OPEN to CLOSED: * Delete any private instance data, and set * p->user to NULL. * * The SILENT and RESTING states: * These are just special cases of the RUNNING * state (see below). It's *not* possible to * force a plugin to either of these states. * Plugins may, but do not have to, switch * between the RUNNING, SILENT and RESTING * states by themselves. * * What To Expect, and How To Act when in the... * CLOSED state: * Well, basically, you don't exist yet! Expect * someone to switch you into the OPEN state, * passing a fresh a_plugin_t with a NULL * 'user' field for you to fill in. * * OPEN state: * You must accept calls to control() for setting * system parameters, but you should only store * the values (or whatever you calculate from * them) for later use. Other parameter changes * are not allowed. * * READY state: * If system parameters are changed while in the * READY state, they are expected to take effect * immediately. Preferably, work as quickly as * possible, but assume that no one is stupid * enough to tell you to reallocate you buffers * from within a real time thread. * * PAUSED state: * In this state, there will be no calls to * process() or control(). (After a thread has * put a plugin in this state, it's safe to * operate the plugin from another thread, and * then have that thread change the state back * to RUNNING when done.) * * RUNNING state: * Same as for the PAUSED state, but of course, * frequent calls to process() are to be expected. * * RUNNING, SILENT and RESTING are the *only* * states in which process() may be called. * * IMPORTANT: * Note that process*() may get NULL * input buffer pointers, which is a way * for the host to say that you have no * input. * * The easiest way to handle that is just grabbing * the ever present a_silent_buffer (provided * by the host) and go on. * * The in-place process() call will never get * NULL input buffer pointers, as it has no * separate output buffer pointer. This requires * a special case: the process() callback must * *always* do it's work, thus effectively * ignoring the SILENT and RESTING states. * * However, the idea is that you should consider * this as a useful hint! Most DSP algorithms, * when given silent input, will eventually * produce silent output. When that point is * reached, a plugin should spontaneously switch * to the SILENT state, to tell everyone that * there will be no output for a while, and thus, * that there's no point in calling process(). * * SILENT state: * Just handle control() calls. process() will * be called as usual, but you're not required to * do anything with the output buffers. (Or * rather, you *shouldn't*, as it would just be * a waste of CPU cycles.) * * As soon as you feel like producing output * again, switch back to the RUNNING state and * do so. * * If you know that you will not produce output * again, until you get fresh input, switch to * the RESTING state instead! * * Host designers should note that a plugin in * the SILENT state *is* actually still running, * and also that it's most probably *not* * producing valid output! It's also important * that output buffer pointers passed to * process() are valid at all times, as a SILENT * plugin may switch to the RUNNING state at any * time, for no obvious reason whatsoever. Input * is *not* required.) * * That is, it will need process() to be called * as usual, *even* if only to pass NULL input * buffers. This is to allow plugins to keep * track of time, and of course, to detect any * input that might - instantaneously or after * some time - make the plugin switch back to * RUNNING mode. * * RESTING state: * Do nothing (except the usual handling of * control() calls) until you start getting * input buffers again. You're *not* allowed to * switch from this state unless you get * non-NULL input buffer pointers. * * This state exists to tell the host that a * plugin is *really* done with any tails and * stuff, and that there will be no more output * without fresh input buffers. Hosts may use * this to figure out when to stop recording * and things like that. * * IMPORTANT: You should *NEVER* return from * process() in the SILENT or RESTING * states unless the buffer you just * generated (or should have generated) * actually *is* garbage, or silent! * * ANY OUTPUT WILL BE IGNORED. * * General Rules for Hosts: * * System Parameter changes must *never* be done from * real time context, period. * * * Plugins should *not* be expected to be thread safe. * That is, never use a plugin from more than one thread * at a time, without making sure only one callback is * running at any time. */ Note that the NULL input/SILENT/RESTING deal is a bit of a quick hack. It doesn't deal with individual outputs, since the state is for the whole plugin. (But these sorry excuses for plugins I've written so far only have 1 in/1 out interleaved int32 stereo anyway... This stuff was originally designed to scale to very low end gaming machines, so the FP stuff is still only in the off-line synth. I'll keep extending the scalability upwards in future versions, which includes optional float32 processing and mixing.) Well, yes - although it seemed like a cool idea at the time. I've been happy with this design choice so far, but I haven't written all that many state() callbacks yet. :-) I'm thinking about splitting state() into state_up() and state_down() or something, to simplify the plugin code further. (I don't like the depth of indentation that two switch()es in an if() results in. Tabs are 8 spaces, and there should be no more than 80 characters/line. :-) Parameters are "normal" controls (called "system parameters" for now) that you set before the appropriate state changes. See above. Here's what you *don't* have to do in host code, unless you really feel like it: int a_plugin_state(a_plugin_t *p, a_fxstates_t new_state) { int res, s = p->current_state; /* We don't care about SILENT and RESTING here. */ if(s > FX_STATE_RUNNING) s = FX_STATE_RUNNING; /* Nor do we allow forced switches to SILENT or RESTING! */ if(new_state > FX_STATE_RUNNING) return -1; while(new_state > s) { ++s; res = p->state(p, s); if(res < 0) return res; p->current_state = s; } while(new_state < s) { --s; res = p->state(p, s); if(res < 0) return res; p->current_state = s; switch(new_state) { case FX_STATE_CLOSED: free(p->ctl); p->ctl = NULL; break; case FX_STATE_OPEN: case FX_STATE_READY: case FX_STATE_PAUSED: case FX_STATE_RUNNING: /* Can't happen. */ case FX_STATE_SILENT: /* Can't happen. */ case FX_STATE_RESTING: /* Can't happen. */ break; } } return 0; } [...timestamped event systems...] Well, it's basically about sending structured data around, with timestamps telling the receiver when to process the data. As an example, instead of calling voice_start(v, ev->arg1); directly, at exactly the right time (which would mean you have to split buffers for sample accurate timing), I do this: aev_send1(&v->port, 0, VE_START, wave); where aev_send1() is an inline function that grabs an event struct from the pool, fills it in and sends it to the voice's event port. The sender does nothing more about it for now; it just keeps processing it's entire buffer and then returns. Just as if it had been processing only audio buffers. In fact, the timestamped events are very similar to audio data in that they contain both actual data and timing information - it's just that the timing info is explicit in events. Then, eventually, the host decides it's time for the voice mixer to run (some synth specific safety checks, debug code and crap stripped): void voice_process_mix(a_voice_t *v, int *busses[], unsigned frames) { unsigned s, frag_s; if((VS_STOPPED == v->state) && (aev_next(&v->port, 0) > frames)) return; /* Stopped, and no events for this buffer --> */ /* Loop until buffer is full, or the voice is "dead". */ s = 0; while(frames) { unsigned frag_frames; while( !(frag_frames = aev_next(&v->port, s)) ) { aev_event_t *ev = aev_read(&v->port); switch(ev->type) { case VE_START: voice_start(v, ev->arg1); break; case VE_STOP: voice_kill(v); aev_free(ev); return; /* Back in the voice pool! --> */ case VE_SET: v->c[ev->index] = ev->arg1; if(VC_PITCH == ev->index) v->step = __calc_step(v); break; case VE_ISET: v->ic[ev->index].v = ev->arg1 << RAMP_BITS; v->ic[ev->index].dv = 0; break; case VE_IRAMP: v->ic[ev->index].dv = ev->arg1 << RAMP_BITS; v->ic[ev->index].dv -= v->ic[ev->index].v; v->ic[ev->index].dv /= ev->arg2; break; } aev_free(ev); } if(frag_frames > frames) frag_frames = frames; /* Handle fragmentation, end-of-waveform and looping */ frag_s = (VS_PLAYING == v->state) ? 0 : frag_frames; while(frag_s < frag_frames) { unsigned offs = (s + frag_s) << 1; unsigned do_frames = __endframes(v, frag_frames - frag_s); if(do_frames) { bustab[v->fx1].in_use = 1; if(v->use_double) { bustab[v->fx2].in_use = 1; __fragment_double(v, busses[v->fx1] + offs, busses[v->fx2] + offs, do_frames); } else __fragment_single(v, busses[v->fx1] + offs, do_frames); frag_s += do_frames; // This is just for that damn oversampling... if(v->position >= v->section_end) do_frames = 0; } if(!do_frames && !__handle_looping(v)) { voice_kill(v); return; } } s += frag_frames; frames -= frag_frames; } } In short, this function will process the buffer it's given, stopping and handling any pending events at the correct time. Indeed, there is buffer splitting done in here (or you cannot have sample accurate timing without going to audio rate control streams for all controls - deal with it), but it can be done entirely inside the loop, and it can be optimized in whatever way the plugin designer wants, including "shortcuts" such as reducing the timing accuracy so 4 or 8 sample granularity, or whatever. Well, it's nice to see some action in this area again. (Right in time for the Audiality alpha release - so I might get some bonus publicity there. ;-) Seriously, it's probably time to move on to the VSTi/DXi level now. LADSPA and JACK rule, but the integration is still "only" on the audio processing/routing level. We can't build a complete, seriously useful virtual studio, until the execution and control of synths is as rock solid as the audio. I mean, being that I'm tired of sqeezing my ideas into hardware synths, and don't work with any "real" instruments (well, apart from my voice, if that counts ;-), what am I going to *record* with Ardour...? Audiality, among other things, I hope, and I might use MusE or something else to drive it - but either way, it must all be rock solid and ultra low latency. //David Olofson - Programmer, Composer, Open Source Advocate .- Coming soon from VaporWare Inc...------------------------. | The Return of Audiality! Real, working software. Really! | | Real time and off-line synthesis, scripting, MIDI, LGPL...| `-----------------------------------> (Public Release RSN) -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Wed, Dec 04, 2002 at 01:09:57 -0800, Tim Hockin wrote: The central part can be very open, eg in URIs you're allowed to assign URIs from any domain you have control over, so I could label somthing "http://plugin.org.uk/foo#23". This means that anyone with a website can assign URIs. [NB I know it starts with http:, but it /not/ a URL, me and some others argued it should have a non-resolvable protocol name, but...] I dont really like using strings for UIDs though. Its too easy to read semantics into them. No, its a waste of DSP cycles to check whether something's there or not. This is still complexity (if we have a timestamp system), if ther are no events on the input hte instrument will ingore it anyway. No, thats exactly a good reason to use the word port (unless youre describing something thats actually different). I'm not sure I like the idea of varying the behaviour of the system depending on the number of connections, I have hardware that does this and it drives me nuts. Especially when patchbays come into it. ITs kind of forgivable in hardware, as noone wants to buy a sperate mono and stereo reverb, but in software I dont think theres any such excuse. Dont bundle up channels! People dont do that in studios for a good reason. a single channel on a single connections is simple, unambiguous, obvious. But say you have 2 channels is that L+R, M+S, C+M? how about 8, is it 7.1, 8.1 pre filter, 5.1 in ADAT? What do you do when you have a 5.1 bundle and you want to send it as 5.1 in ADAT? Does that require a 5.1 rebundler? I think its much better just to have discrete, mono channels that can be assigned as needed. I'm not sure about the other arguments, but polyphony control is complex and probably only the instrument can do it usefully. If you want this you might have to do it by telling the instrument what its max poly should be. Jack has strinport comtrols that can be use to move the conceptual time of the jack system, loop, sync etc. I thought this too unltil recent, but Benno demonstrated to me that sample accurate is not significantly harder, and is more efficient in general. If the per-voice params are different to he poer-instrument params then something has gone seriously wrong. Seen as plugins internally work in float, all knobs need to be float ;) voice_on is proably more instrument neutral. Not everything is a note (eg. my LADSPA gong). I dont think you can do anything useful with a generic file string, what could be host use it for? Good, so ditch int and string and replace them with a generic binary type ;) Memeory allocation failures dont really happen in RT systems, you get massive overruns first. I dont bvelieve the host can draw a nice UI automatically, the best it can do is a usable UI. Agreed. - Steve

Hi, Recently Frank Neumann pointed me at some very impressive CSound algorithms implemented by Sean Costello. I was especially looking for a digital implementation of the Bode Frequency Shifter which is among the coolest modules you can have in a modular synthesizer. There is also a vintage stringphaser which sounds incredible. Writing email to Sean Costello to ask whether he would mind if his algorithms were ported to C and published under GPL, I discovered that his email address is no longer valid. Googling for it was unsucessful because there are many Sean Costellos and the CSound author seems to have disappeared. Now my question is whether anybody on this list happens to know Sean Costello and/or knows of a valid email address of him ? Matthias -- Dr. Matthias Nagorni SuSE GmbH Deutschherrnstr. 15-19 phone: +49 911 74053375 D - 90429 Nuernberg fax : +49 911 74053483

On Wed, Dec 04, 2002 at 06:59:12PM +0100, David Olofson wrote: I agree, you dont want event sorting code in every instrument, you will end up with some very odd behaviour due to bugs. Yes, but voice_on/off is a commonly useful abstraction. Hoever making sure htat the API is scale neutral (unlike generic MIDI) is important. I'm not sure what the best way to ensure this is. Obviously pitch and velicty are optional, not all instruments have either. Thats one reason if favour of using well know portt names to indicate what voice parameters normally map to what MIDI controls. OK, that is a good point, it would make the host able to store the session more easily, and package it up my copying the file into local space, and changin the path. But if the api is like LADSPA you're not allowed to do allocation in the RT part anyway, so you may as well stick to malloc and friends. If hte host is desperate to use something else it can override them with LD_PRELOAD. Sure, but simple instruments dont require file i/o or any of that stuff anyway. - Steve

On Wed, Dec 04, 2002 at 09:44:12 +0100, David Olofson wrote: Thats somewhat semitone biased, if we use +1.0 is middle C, +2.0 is one octave higher then we are tuning neutral, and, coincidentally compatible with 1.0volt/octave analogue synths. Well, no, because for advanced instruments (eg. a full featured sampler) we have jack. I think its reasonable to expect a jack app to be able to natively understand MIDI/OSC/CV/whatever. - Steve

On Wed, Dec 04, 2002 at 10:40:01 +0100, David Olofson wrote: OSC? Well, alsa-seq, DMIDI or OSC, the linux MIDI sequencers I've seen support alsa-seq, and some support OSC. All of these will give better timing than hardware MIDI IIRC. - Steve

On Thu, Dec 05, 2002 at 12:40:19 +0100, David Olofson wrote: Its around, there is some support in software for it. Well, alsa-seq seems to be the system of choice. Never used it myself though. - Steve

On Wed, Dec 04, 2002 at 11:05:21AM -0800, Tim Hockin wrote: Thats why its inportant to choose your URIs carefully. It could also be viewed as another rason to issue central ints, they dont expire ;) As long as there is a reserved block for experimentation, its its easy to get real IDs it should all be OK. OK, maybe. But (as discussed elsewhere) in an event system theres no need to check, there wont ever be any events on unconnected inputs. If you think its neccesary, it is meaningless in some cases though and I'm not clear on what it would be useful for. Every instrument feature adds to the barrier to entry and needs to be justified. OK, I'm starting to come round on this one. - Steve

On Wed, Dec 04, 2002 at 10:05:25 +0100, David Olofson wrote: This one sounds good to me, Mattias suggested something similar for LADSPA. - Steve

On Wed, Dec 04, 2002 at 10:49:11 +0100, David Olofson wrote: Sure, sounds fine to me. - Steve

This confuses me. A plugin says it can handle 1-6 channels. The host only connects 2 channels. The plugin loops for i = 0 to i = me->nchannels. There isn't any checking. If the plugin says it can handle 2-6 channels and the host only connects 1, it is an error. Connect at least the minimum, up to the maximum. In typing this, I've seen that discontiguous connections do, in fact, require condionals. Maybe it is safe to say you have to connect ports in order? This is exactly what I'm talking about with the connect methods. Before we go into PLAY mode, we ask for a certain number of channels. hmm, this is interesting, but now we're adding the conditional Yes, I've come around to this. The question in my mind is now about disabling (or just not connecting) some ports. ok, I see now. If the plugin supports disabling, the host can use it. If the plugin is faster to assume all ports connected, it does that instead. I think I rather like that. This is key, again, you've convinced me. just so we're clear, 'voice' in your terminology == 'channel' in mine? Do we need to provide a buffer for ports that are disabled? ok, I'll include something to this effect in the next draft. If the host connects this pad to a mono effect, it knows that the 'left' channel is also named 'mono'. I do not expect the plugin to mono-ize a stereo sample (though it can if it feels clever). I'm agreeing now.. how so - it seems if you want to send a voice-specific event, you'd need this ok, ok. yeah, VSTi also has MIDI - need I say more? I'm becoming convinced, though. They should have the same range as floats - whatever their control struct dictates. with a per-voice pitchbend I don't know if I like the idea of controls being flagged RT vs NONRT, but maybe it is necessary. Or maybe it's not, and a user who changes a sample in real time can expect a glitch. BUt what I don't get is: who loads the data into the control? a) hast will call deserialize() with a string or other standard format b) plugin will load it from a file, in which case host passes the filename to the cotrol c) host loads a chunk of arbitrary data which it read from the plugin before saving/restoring - in which case how did it get there in the first place? (see a or b) Such as? Where does this data come from in the first place? So does Apple Audio Units. I am starting to like the idea.. Interesting how it came about, but why are you helping me turn my API into yours, instead of letting me work on yours? Just curious. I do like to roll my own, but I don't want to waste time.. Tim

Unless I'm missing something - all you really need is a voice-id that is Unique within that instance of that plugin. [... RT vs NONRT controls ...] So how do VST effects do it? I can increase the delay feedback all I like and it doesn't hiccup, stutter, or misbehave at all. You're saying that this is a non-rt control because it might have to realloc() buffers? absolutely - this is why controls have default values.

On Wed, Dec 04, 2002 at 08:43:11 -0800, Tim Hockin wrote: Delay feedback is a RT control, delay time might not be (depending on how its implemented). I'm not sure how this can be handled easily, there are lots of things like loading samples that will be impossible to handle in an RT way, but I'm not sure that something like a sampler belongs in this kind of API. I know there are VSTi samplers, but windows people dont have jack. I could be that everything that can be usfully implemented in this kind of API doesnt need non RT controls. - Steve

On Thu, Dec 05, 2002 at 12:07:35 +0100, Dave Griffiths wrote: Yes, this will work in a system like SSM, but I'm not sure how well generic .so plugins and threads will play together... I guess theres nothing to stop you from cloning a new thread inside a .so, but it may come as a supprise to the host ;) - Steve

On Thu, Dec 05, 2002 at 12:48:49PM +0100, Dave Griffiths wrote: Yes, its fine in SSM, because you know that there is only one host, and you know how it behaves. I dont know, but I'm guessing that it could mess up some generic hosts. Maybe its always safe. - Steve

On Thursday 05 December 2002 12.07, Dave Griffiths wrote: [...non RT controls, VST & delay ...] Applies to Audiality as well. It needs humongous amounts of CPU power for "loading" most sounds as well, since they're actually scripts used to render the waveforms using the off-line synth. There's also another, similar problem: Plugin instantiation. FX inserts are selected through MIDI CC events, which means their instantiation is triggered from within RT context. Currently, they're also instantiated in there, which is just a quick hack. (Which, AFAIK, prevents this engine from running at all on Mac OS classic - can't malloc() from within interrupt context.) What I'll do is throw in a "butler thread" (Benno's invention :-), to which I pass requests to instantiate or destroy plugins, load or unload waveforms and other non RT safe things. There will probably just be an sfifo in each direction, since those are extremely portable and easy to use. The method of waking up the butler thread will probably vary a little between platforms. On systems without threads, the butler will just be a callback that you're supposed to call from the main loop every now and then. //David Olofson - Programmer, Composer, Open Source Advocate .- Coming soon from VaporWare Inc...------------------------. | The Return of Audiality! Real, working software. Really! | | Real time and off-line synthesis, scripting, MIDI, LGPL...| `-----------------------------------> (Public Release RSN) -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Thu, Dec 05, 2002 at 04:10:16PM +0100, David Olofson wrote: And it doesn't appear to be as successful, Cubase and Protools dont use it for thier primary i/o for example (c.f. Muse and Ardour). - Steve

So, I'm incorporating the things that were discussed this week into my API proposal. It's starting to take shape, and I really appreciate the feedback I got (why I can't get that level of feedback even at work, is beyond me). I've hit a couple of large questions that I want to bounce off you all. Per-voice controls vs. Master controls: ---- This is what I am thinking: One of the flags on each control is whether it is a CTRL_MASTER, or a CTRL_VOICE (or both). This allows the plugin to define a ctrl labelled (for example) VELOCITY and the host can connect it to any MIDI input, if it wants. Let's assume a plugin provides a control named FOO which is both VOICE and MASTER. Let's assume the current state of FOO is the value 50.0. Let's assume the sequencer triggers a voice and sets FOO for that voice to 80.0. The user then turns the master FOO down to 0. What happens to the value of the voice's FOO. a) goes to 0 b) ends up at 30.0 c) stays at 80.0 Maybe controls that are both MASTER and VOICE should be absolute values for MASTER and scalars against the MASTER value per-voice? Needs discussion. Triggering a voice ---- I see a few methods, each has pros and cons. 1) * Host calls plug->note_on(timestamp, note, velocity), and gets a voice-id. * Host sends n VOICE_PARAM events to set up any params it wants * Host calls plug->run() * Plugin activates the voice at the right timestamp with the right params. * Host calls plug->get_polyphony() to know how many voices are playing. * Host calls plug->voice_off(voice, velocity) 2) * Host sends a VOICE_ON event with a negative voice-id and params velocity and note * Host sends n VOICE_PARAM events for the negative voice-id * Host calls plug->run() * Plugin receives the VOICE_ON, allocates a voice-id, and and sends a VOICE_ON event with the real voice-id and the negative bogus one back to the host. * Host sends a VOICE_OFF event to the plugin to end a voice, plugin ACKs by sending it back. * Plugin sends a VOICE_OFF event to the host if a voice is done before the host sends VOICE_OFF (short sample, etc) * Host keeps a count of voices, increment on VOICE_ON, decrement on VOICE_OFF. Modifications on those two: a) Same as #1 but with no voice_off() method - use VOICE_OFF events instead. b) Modification on #1 and #2 - don't pass velocity and pitch params, instead have them as controls c) Same as b, except Velocity is not a continuous control - pass velocity but keep pitch as a control (possibly pitch and pitch-bend being different? not sure). Preset and state save/restore ---- Should each plugin provide serialize() and deserialize() methods (thus storing plugin state from the plugin itself in an arbitrary string) or should the host be expected to write-out each control's data? I'm leaning towards serialize/deserialize. So, I'm looking for ideas and discussion! Tim

On Saturday 07 December 2002 12.21, Steve Harris wrote: I'm still not sure I understand the terminology here... Considering some recent posts, I assume that the following applies: Instrument: Monophonic or polyphonic plugin, capable of maintaining one set of "patch data" (or "one instrument sound") at a time. In popular MIDI synth terminology, an Instrument would correspond to "one part". Voice: An abstract object inside an Instrument, representing "one note". A polyphonic Instrument may maintain several Voices at a time. Physically, a Voice may be anything from a single oscillator to a network of oscillators, filters and other objects. Is that what you mean? Personally, I'd rather not use the term "Instrument", but rather just Plugin. In my terminology, an Instrument (as defined above) would be a Channel, and Plugins may or may not be allowed to have multiple Channels. As to the control protocol, if you want to do away with the "channel" field, you could just allow synths to have more than one event input port. One might think that that means more event decoding overhead, but given that you'll most probably process one channel at a time anyway, it would actually be an *advantage*. Oh, and you wouldn't have to use separate negotiation schemes for instrument/plugin controls and voice/note controls - you can just use separate ports. <audiality_internals> BTW, in Audiality, there's no real plugin API for the synth engine yet (it's used only for insert FX), but just objects with event ports. As of now, there is one event port for each Channel, and one event port for each physical Voice. "Virtual Voices" (ie Voices as defined above, which I would rather call "Notes" or, just that; Virtual Voices) are not defined in the "API", and may not exist in some patches - the Patch Plugin (which is what converts Channel Events into... anything, basically) decides how do deal with Channels and Voice events. </audiality_internals> I agree. When I implemented the simple "2D positional" sound FX API for the Audiality engine, I quickly realized that this <pitch, velocity> tuple is just an arbitrary set which has been hammered into our minds through the years. It's a sensible compromize to save bandwidth, and it works well for most keyboard controlled instruments, but that's about it. I think it's time we stop thinking of two arbitrary parameters as an obvious part of any "note on" message. As to the "gets a voice ID" thing, no, I think this is a bad idea. The host should *pick* a voice ID from a previously allocated pool of Virtual Voice IDs. That way, you eliminate the host-plugin or plugin-plugin (this is where it starts getting interesting) roundtrip, which means you can, amond other things: * send controls *before* you start a voice, if you like * implement smarter and tighter voice allocation * use a timestamped event system * pipe events over cables, somewhat like MIDI Yes, I think so. There's slightly more overhead, obviously, but the alternative is to maintain a performance hack in the API, all plugins and all hosts... Also note that event size (which has to be fixed) increases if you must squeeze in multiple parameters in some events. ++host_does_serialising; //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

Combining three replies: Steve Harris &lt;S.W.Harris(a)ecs.soton.ac.uk&gt; wrote: Whether they are defined together or seperately, there are certainly controls that apply to each voice and to each (instrument, channel (midi), plugin). For example volume. What advantage do you see to defining them seperately? Certainly the structures are analogous, if not identical. So no one has offered me any suggestions on how we handle the clash between Master and per-voice controls. To re-ask: <RE-ASK rephrased="true"> Let's assume a plugin provides a control named VOLUME which is both VOICE and MASTER. Let's assume the current state of VOLUME is the value 5.0. Let's assume the sequencer triggers a voice and sets VOLUME for that voice to 8.0. The user then turns the master VOLUME down to 0. What happens to the value of the voice's VOLUME. a) goes to 0 b) ends up at 3.0 c) stays at 8.0 Maybe controls that are both MASTER and VOICE should be absolute values for MASTER and scalars against the MASTER value per-voice? </RE-ASK> I agree, mostly. I threw this in as a bit of a red-herring, to see what people were thinking. Absolutely. HOWEVER, I have one design issue with it: Velocity is not a continuous control. You can't adjust the velocity halfway through a long note. You can adjust the pitch. You can adjust portamento time. Velocity relates SPECIFICALLY to the attack and release force of the musician. Unless we all agree that velocity == loudness, which will be tough, since I think _I_ disagree. Could I get you to accept voice_on(velocity); and pass all the rest as events? Two votes for this - I'll consider it decided. David Olofson &lt;david(a)olofson.net&gt; wrote: Correct. Correct. So I haven't come to this note in my TODO list yet. So we want to support the idea of (MIDI word) multi-timbral plugins? Given that it is software, we can say 'just load a new instance for the new channel'. It prevents anyone from doing an exact software mockup of a bit of hardware, but I'm inclined not to care that much.. Are you using multiple event ports, then, or just having one port per instrument-plugin and sending EV_VOICE_FOO and EV_MASTER_FOO (modulo naming) events? Other than Organs, which you've mentioned, what kinds of instruments don't have some concept of velocity (whether they ignore it or not..). As I've said above I have a hard-time reconciling velocity with any timed event other than on/off. I'm still not clear on this. What plugin would trigger another plugin? Do you envision that both the host and a plugin would be controlling this plugin? If so, how do you reconcile that they will each have a pool of VVIDs - I suppose they can get VVIDs from the host, but we're adding a fair bit of complexity now. you can do this already - any voice-control event with a timestamp before (or equal to) the note_on timestamp can be assumed to be a startup param. I don't see what you mean by this, or how it matters. I see voices as being the sole property of the instrument. All the host knows about them is that they have some (int) id that is unique per-instrument. umm, I thik this is not solely dependant on vvids - I think timestamps will work just fine as proposed. It's a matter of taste, unity, and presentation we're discussing. Ahh, now HERE is something interesting. I'd always assumed the plugin would return something, self-allocating a voice. This is what you've called the round-trip problem, I guess. But it seems to me that even if you were piping something over a wire, you have some sort of local plugin handling it. THAT plugin allocates the voice-id (arguing my model). The question I was asking was: is voice-id allocation synchronous (call plug->voice_on(timestamp) and get a valid voice-id right now), or is it async (send a note-on event and wait for it to come back). This raises another question for me - the host sends events to the plugins. Do the plugins send events back? It seems useful. The host has to handle syncronization issues (one recv event-queue per thread, or it has to be plugin -> host callback, or something), but that's OK. Do timestamps matter to the host, except as bookkeeping? Why does it have to be fixed-size? It doesn't strictly HAVE to be. On one hand I HATE when an API says 'you have three available params' foo->param1, foo->param2, foo->param3. If you need more, too bad. On the other hand, there are performance advantages to having events pre-allocated, and thereby, fixed sized, or at least bounded. This API is not purely instrumental. It can certainly be for effects and sinks, too. That said, we're spending a lot of time on the instrumental part because it's the new ground wrt LADSPA. Tim

So one should not be able to manipulate a per-voice volume and a master volume? I'm not sure we can reasonably do that. We can say that no one control applies to both master and voice, but then we end up always (or rather, often) defining two volume controls, two pitch controls, two filter controls etc and making them slightly different and behave differently in each plug. Are we better to define the behavior, or at least offer a suggestion? ok, we agree on that. MIDI has 2 velocities - note_on and note_off. I see velocity as specific to those two events. Isn't a new velocity event really a new strike or attack of the instrument, or, in other words a new voice (even if it cancels the previous voice)? That said, I hate that Velocity is special. I could be convinced. I could also stand and argue. Not sure I know which I prefer... I agree, and simplicity is better, I think. Still needs more noodling. If it is obvious and easy, then I don't really mind it. channel pressure would be a separate control, just as it is in MIDI. but if a plugin controls another plugin (as suggested by David) the 'pseudo-master' needs to either be a full-fledged host, or needs to get a pool of VVIDs from the host via a host->get_vvid() callback. It's not TOO bad, I guess.. But I don't see it as being a big-win on any front as compared to a synchronous vid = plug->voice_on() mechanism. Me neither, but it is becoming morer apparent that a plugin DOES need to send events back. Arguments? Assuming that control changes are the only types of events that flow. some events, off the top of my head.. VOICE_ON (plugin to host) ? VOICE_OFF (plugin to host and host to plugin) VOICE_CTRL (host to plugin) MASTER_CTRL (host to plugin) SILENT (plugin to host - sent when reverb tails or whatnot have died..) yes, and let's not make this a wire protocol :) Seperate project. Well, assuming a LADSPA wrapper in this API, a host can transparently use LADSPA plugins in a multi-channel way. Stereo reverb can be built out of two LADSPA mono reverbs. Just an idea.

On Sun, Dec 08, 2002 at 12:29:24 +0100, David Olofson wrote: As long as its not required, you can't allways tell (eg. gong again). - Steve

On Saturday 07 December 2002 11:29 pm, David Olofson wrote: I think velocity is special because it is often needed by the synthesis algorithm only at the beginning of the note. For instance, if you have a physical model of a bell then the velocity will determine the shape and magnitude of the impulse function you use to represent the striker. Changing it midway through the note, after the bell has been hit, is meaningless. That said, it would be cool if you could support multiple velocity-like parameters, so that it would be possible to control the position of the striker and the strength of the strike independently for each note. Multiple poly-aftertouch-like controllers would also be cool, but I think they are a different thing.

On Sun, Dec 08, 2002 at 12:26:32 +0000, Nathaniel Virgo wrote: A Bell is a good example of something where you want multiple velocity events, you could call voice_on() or whatever to initialise the physical model instance, then you send simultaneous velocity and position events to indicate that the bell has been struck. Its not true for a impulse derived bell but a weaveguide model of a bell struck twice has a different sound to a pair of identical ones each struck once at the respective times. - Steve

On Sun, Dec 08, 2002 at 10:35:39AM +0000, Steve Harris wrote: Nice examlple. To me it clearly illustrates that velocity (ie. force of note on/off) is indeed a property of the note event. The handling of velocity for said bell depends on the implementation of the synth; a physical modelling synth could when retriggering with the same pitch adjust the sound of the bell. Simple sample playback synths would most likely not have this level op sophistication. The violin example using the bow speed property is something different. In fact, the bow speed is indeed a sort of continious controller, while the strings could be hit by the bow with different velocity. How could one otherwise achive a pizzicato effect? (I might use the wrong phrasing, but I mean hitting like slapping a bass guitar the violin's strings using the bow.) Though not in the scope for the instrument plugin discussion, I'd like to see compatibility with MIDI or other real-life protocols be considered. In the end our sequencer applications would need to transparently support both flavours. Frank. -- +---- --- -- - - - - | Frank van de Pol -o) A-L-S-A | FvdPol(a)home.nl /\\ Sounds good! | http://www.alsa-project.org _\_v | Linux - Why use Windows if we have doors available?

We're not discussing discarding velocity. We're discussing whether it is a property of the note on/off events, or whether it can be unified with the rest of the event model and become a simple event delivered at note_on time. If a plugin wants to handle continuous velocity changes (a violin?) it can. It CAN, but it doesn't HAVE TO. That is the markings of a good API, in my mind, and that is why I have conceded this point :) Tim

On Sunday 08 December 2002 19.12, Mark Knecht wrote: Again, what has this to do with the *interface*, rather than the synth design? We're not discussing whether we should do away with "instantaneous note velocity" or not, but *how* we should communicate it to the synth. I vote *against* hardcoding an old MIDIism into the API, just because most people have never played anything without a traditional keyboard. :-) Of course. Different control entirely. Well... How could there be another way to do this, specifically? If you want to select a sample based on the velocity when a note is started, just do that. If you tell the host that your Velocity control has a range of [-1.0,1.0], and that it's not a continuous control (ie does not support ramping; *does* react on every change, regardless of value), you can just consider any positive Velocity change a "note on", and overy negative Velocity change a "note off". Actual velocity is obviously fabs(value). //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

Do we really want to have different controls for different channels? I can see how it might be neat, but since multiple channels is convenient for hardware people, shouldn't we leave the controls the same, too? :) Simpler perhaps: nchannels master_controls[] channel_controls[] voice_controls[] or, if we agree flags for this are best: controls[] (each is flagged MASTER/CHANNEL/VOICE) Even though I have conceded this point - JUST IGNORE IT? Whatever, it's old news :) Uggh, can we keep the get() of control values simpler than events? My previos proposal had a control->get() method and a ctrl->set() method. Obviously, the set() is superceded by events. Is the get, too? I noodled on your state-model and realized that a state-change is just an event. :)

Well, my first thought is that we don;t want to send a CTRL_CHANGE event to the host every time a control changes, Do we want the host to have to send CTRL_GET events and wait for CTRL_VALUE events, or can we say 'one tick granularity is all the host can get' wrt CTRL_GET?

I'll buy that. Once the host reads the initial values, it should refrain from bothering the plugin. Aside: Do we see a need for plugins to spontaneously change a control? What of a plugin that has a velocity-capped control (you turn a knob fast, and it eventually gets there) or something that crossfades between two values automatically. Do we need to send CTRL_CHANGE events to the host, or should we do a 'watcher' callback. Watchers is how AudioUnits works. I don't really like it. Also to think about - what if the host sends a bad value, and a control wants to reject it? Ahh, asyncronicity. I guess for this case the plugin sends back some FAIL event or simpler sends back a CTRL_CHANGE with the old value (or the min/max if the host has gone too far). Arpegiator is what finally convinced me of this, yesterday evening (California time). Just out of curiosity, where are you located physically, in the real world? Our timezones are certainly not in sync. Tim

Well, if the host is auto-generating a UI, or it is, in-fact tracking the values itself (no get() method) then it needs to know. I was more thinking that some controls would disable certain functions, or limit other controls. Assuming that there is no get() method for a control, and the host knows the value by remembering, then the plugin does need to alert the host if it 'ignores' something, or the host will have the wrong value. Ahh. Sunny England. For the record, I am in the San Francisco area. Tim

On Monday 09 December 2002 13.14, Steve Harris wrote: It doesn't have to, unless it actually cares. If you save a preset with a "bad" value in some field, the plugin will just fix it when you load the preset. There's just one problem: In what order do you write the controls back to ensure you end up with the exact same result? Anyway, if the host *does* keep track of "last value written", supporting the "I'll make that X instead!" event is just a matter of writing X into that "last value written" variable. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 09 December 2002 15.16, Steve Harris wrote: Well, let's put it as simple as this: If your plugin has controls that may refuse certain values within the valid range, they *must* tell the host when this happens. Otherwise, automation and preset save/restore will most probably not function properly. Now, whether *hosts* care to implement it is another matter, but I would think that most hosts would, as you can't have preset save/restore without it. Either way, this might just be another thing that can be built into the host SDK lib, maybe in the form of a default handler for plugin->host events on Master Event Ports. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 09 December 2002 16.09, Steve Harris wrote: Hmm... Well, yes, but how do you handle these enum controls with "random" modes that can be disabled depending on the values of other controls? IMHO, such controls would be a sign of bad design, and in that case, we could basically just rule them out, or rather ignore (*) them - but I could be missing something. (*) That is, force plugins to accept and keep the values. If a value is "bad", the plugin should have a concistent way of internally using a different value, in a way that guarantees that any set of parameters, written to the plugin in any order, always results in the same internal configuration Maybe (hopefully) that's all there is to it? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

The order the plugin presents them to you? If there are dependencies between controls can we have the plugin author be responsible for making their indices reflect it? Otherwise we can add yet another field to controls which says the order in which to write presets. Ick. Serialize/deserialize solves this nicely, btw :) Exactly. If a plug doesn't support it, no big deal. If it does, cool.

On Sunday 08 December 2002 22.59, Steve Harris wrote: Defaults should be part of the control description, just like with LADSPA ports, IMO. And why is reading controls for saving to a file different from the usual "remember what you say to the plugin"? That, and/or there should be ramp events. Those can be a bit hairy to deal with at times, but please, do suggest an alternative if there is one that is simpler and still sufficient for sample accurate control... (No, no audio rate "raw" control ports, please!) Yes, that's a good point. You're using the same plugin every time, right? And the plugin is what defines the exact details of what a control actually does. (If you want to know what it does internally, read the code! :-) Well, I'd prefer plugins being able to say whether their control ranges are hard, or just recommendations - and when they're hard, expect out-of-range values to cause the plugin to crash, div-by-zero or whatever! *lol* Yeah. IMHO, in the new API, no host should *ever* use an out-of-range value when dealing with hard ranges. So, ranges *may* be hints, but if they're *hard*, they're much more than hints. Dito, except that I'm in Sweden. :-) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 09 December 2002 13.34, Steve Harris wrote: [...] Well, ok. You can have those *too*. (I'm Santa! :-) Just have a Bay with audio input (or output) channels for each audio rate control. Then you can connect audio signals to controls and vice versa. Then implement an audio->control transformer, and a control->audio transformer and have the best of two worlds. :-) Have you considered that timestamped events may actually have *better* than sample accurate timing...? ;-) (Well, I actually suspect that subsample accurate timing will show up sooner or later - as a buzword or because it actually matters. Maybe we should allocate some bits for it while we're at it?) And more seriously, how efficient is audio rate controls when you have tens of them for every channel...? Should you keep recalculating all of you filer coefficients, reprogramming all of your LFOs and envelope generators for *every sample* all the time? Or first test for change in every control for every sample? I don't think that DSPs or generic CPUs will *ever* be fast enough that you can completely stop worrying about performance. You think convolution is heavy stuff? Wait until you see what the cutting edge high end effects look like in ten years... Trust me, only big studios will have enough power to run them in real time - just like it is now. I'm quite sure timestamped events are here to stay - for a very long time. We'll never have infinite numbers of clock cycles to waste. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 09 December 2002 15.29, Steve Harris wrote: Where's the bloat? We need audio ports anyway, right? Yes, but without converters, you can't do things like applying audio effects on controls... Yes, but that's only one bit per sample. Is that sufficient for the most extreme accuracy nuts? Anyway, no I don't think there would be much point in messing this, at least not until we've actually seen it in use, and understand better *why* it's used. [...] Well, yeah - and if you can run hundreds of *those*, it probably doesn't matter that every single synth voice spends more CPU time processing control data than audio. :-) Yes - but I'd rather not wait ten years before I can actually *use* my software! :-) In fact, I've already waited *more* than ten years already for PCs to become at all usable for serious audio synthesis and recording. Now they are, but since I didn't have Linux/lowlatency some years ago, I never got around to write any hopelessly inefficient software that would have been just fine today. ;-) Do they use that for *everything* (like all parameters, switches etc), or just where it actually matters? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 09 December 2002 16.57, Steve Harris wrote: So, what do you do if you don't *have* the source signal you want in audio format? Hack the plugin? (Yeah, ordinary users will love that...) So, *that's* how desktop applications got as insanely slow as they are these days... :-) "If I don't need to optimize this, I don't need to optimize that..." Well, that sounds ok. :-) Well, there's a practical problem with off-line stuff as well; tweaking until you get the perfect sound takes ages... *hehe* BTW, I did write some Amiga software back then - but that actually ran in real time, and obviously couldn't sound all that great. (And though the 25 MHz A3000 helped a lot, it was still very far from even the lowest end synths. Either voices or quality; not both.) Well, we'll need a *few* more registers to do this on workstations, I think...! :-) Until we can do away with blocks, we probably can't do away with events either. Those sort of belong in the same order of magnitude of work vs overhead. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

Good lord you guys were busy while I was asleep. I'm going to spend all day just digesting the 70+ emails I have to read, and forget about replying to them all. How does this sound, since I seem to be the scribe: I'm just going to shut up for a while and sort all the emails into questions, reasons and decisions. When I am done, I'll repost a list of things that have been decided, and things that are still open or need more discussion. I'd like to have another draft API done by next Monday. That gives me one week and one weekend to do it. I hope my boss doesn't mind me spending some time on it :) I have a long TODO and you keep dragging items up to the top of it. I have asked a lot of these questions, but want to focus on resolving some before asking more :) brain spinning... Tim

On Mon, Dec 09, 2002 at 10:01:15 +0100, David Olofson wrote: It doesnt have to be that expensive, but you have to design your system that way from the ground up, and it basicly rules out conventional plugins. Aren't they :) There is a good one for Windows, called SyncModular. You can drill down right into the basic filters and see a bunch of z^-1's and amplifiers :) You could do better under linux with Free Software, but I just dont have enough free time, or GUI skills :( Linuxsampler is using a similar approach, but its not blockless (and it wouldn't be noticably better if it was). Still if anyone ever wants to tackle this they can have a fair chunk of my spare brain cycles. - Steve

On Tuesday 10 December 2002 01.07, Tim Goetze wrote: Not if it generates machine code. That way, it could (theoretically) be about as efficient as the corresponding "effect" implemented by hand in C. There doesn't have to be any more per-sample overhead than in the inner loop of your traditional plugins. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Tue, Dec 10, 2002 at 02:03:42 +0100, Tim Goetze wrote: No, it really isn't that slow. SyncModular does a similar trick. - Steve

no, atomic is 32 bits on x86. its only 24 bits on sparc, where the need to provide a spinlock to cover cache write-back effects forces it to 24 bits. you can do atomic exchange and compare-and-swap on pointers for x86. --p

Hi, ams-1.5.5 is available from http://www.suse.de/~mana/kalsatools.html. It fixes a serious bug in synth.cpp which causes the machine to freeze when ams is started as root. Some example patches for the bode frequencer LADSPA plugin included in the new 0.3.3 version of Steve's plugin set have been added as well. Have fun ! Matthias -- Dr. Matthias Nagorni SuSE GmbH Deutschherrnstr. 15-19 phone: +49 911 74053375 D - 90429 Nuernberg fax : +49 911 74053483

Steve Harris wrote: nope, i meant dynamic updates on a realtime (lock-free) code path; it's an interesting problem with, afaict, no obviously elegant solutions. yes, this is a huge plus. yeah, i agree it's the ideal method of processing. i'm not convinced it would run anywhere as fast as block-based processing though. cache effects are an argument (filter histories, delay lines, lookup & wave tables etc would all frequently move in and out of the cache lines) and the implementation effort, including dynamic code updates, would probably be huge. and you'd have to drop some possible applications of simd (vectorized) instructions. tim

Steve Harris wrote: yep, i was thinking about direct code generation (relocation if you will) assuming it'd give the best execution speed. rt modification of such constructs can easily set your thoughts spinning for a few hours. i have yet to notice a power increase in the local cpu. ;) sigh, yes. i've been thinking about a simplistic dsp-only scripting language for similar purposes lately, but concluded that for the time being gcc producing dynamically reloaded .so's would be the way to go (unfortunately saol produces executables, hint ;). tim

On Tue, Dec 10, 2002 at 10:56:41PM +0000, Steve Harris wrote: This came up a looooong time ago when I looked into making LADSPA a target for sfront. IIRC, you are correct: John L. said that some global variables would prevent multiple instances of the same plugin being loaded at once. Then JACK came along, and I decided to drop that idea and pursue getting sfront to compile JACK clients. It works, mostly... and one day I'll clean it up enough to submit to John L. to distribute with sfront... really, I will... honest... -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"

On Wed, Dec 11, 2002 at 12:20:29AM +0000, Steve Harris wrote: OK, I've finally released it ... http://www.slinkp.com/linux/code It patches cleanly against current sfront (0.85 I think). Works with jack CVS of Dec. 5th. Input isn't working currently, but output seems fine. Input *was* working but I did a big refactoring and must have broken something. -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"

On Tuesday 10 December 2002 15.08, Tim Goetze wrote: There's no problem if you just wait until no processing is going on (this is when you'd normally block on the audio deice), and then switch in the new version. Obiously, you'll have to remake connections and all that stuff as well, but that's no different from non-compiling approaches. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 11 December 2002 00.05, Steve Harris wrote: Well, yeah - but I was under the impression that the idea was to *avoid* that. :-) Yeah. I was rather thinking about connections to the host or "outside world" - and then there's state data, of course. Indeed. You can't beat passing data through registers without copying, and flow control by placement rather than jumping. :-) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Tue, Dec 10, 2002 at 01:07:48 +0100, Tim Goetze wrote: Naah, this isn't true it just requires the the engine to recomiple the dsp code. It makes changes a bit laggy (<1 sec typically), but its actually quite efficient. You could have an interpreted mode, where it tries to evaluate it noramlly, but that /will/ be slow. - Steve

On Tue, Dec 10, 2002 at 08:53:02 +0100, David Olofson wrote: Well, you dont have to interpre part syou've allready compiled, jsut the bits that are different. Given they way you would design this in an Free Software system (ie. the source code is really there, not some VM type stuff) it shouldn't be too hard to make conventional-ish .so's that are blockless, its just that they will be slow. - Steve

On Sunday 08 December 2002 21.19, Tim Hockin wrote: Interesting question... Sounds like pure implementation details to me. What you do is just say "these controls are *target* values". In fact, most plugins in most APIs do this anyway, since anything else will result in clicking and zipper noise. Sounds like a bad idea to me... You want one callback per sample, or some arbitrary resolution? If you really want a plugin to tell the host (or another plugin) what it's doing internally, publish that through an *Output* Event Port. I don't think there's a good reason to have controls act as both inputs and outputs at the same time, since you can have the exact same functionality with one "target" input control and one "actual value" output control. It can't. The host f*cked up, and the plugin may even *crash* without the plugin author deserving as much as a "you might want to fix this" email. Possibly. In fact, that could be a rather nice feature for some stuff. (Say an enumerated integer control, where some values in the middle may not be valid under some circumstances.) Anyway, that would be an *optional* feature. Plugins that just tell the host about the type and range of a control should not be expected to even range check the values they receive. (Why check data stored in the sequencer's data base over and over again, for example? If the host gets data from an untrusted source, check it before it's given to any plugin...) [...] //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Mon, Dec 09, 2002 at 12:27:58AM +0100, David Olofson wrote: Yes, I agree entirely. Maybe... It's likely that the instrument is using some unknown finely tuned interpolator/filter combination though. I also dont think it matters :) - Steve

On Sunday 08 December 2002 12.11, Tim Hockin wrote: Why not? Just like the host isn't supposed to flood the system with events, neither are you, as an event generating plugin. (And there's a reason why some APIs have ramp events and the like.) Well, either could work... I don't see any major advantages with either, except that the event based approach can be made sample accurate with minimal effort. (Copy the timestamp field. In fact, the way I do events in Audiality, you can even reuse the event struct of the request, rather than throwing it away and allocating a new one for the reply.) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

personally, i think ardour is an excellent proof-by-implementation that yes, busses are really just a special class of strip, with no basic difference in the kinds of controls you'd want for each. these days, an AudioTrack in ardour is derived from the object that defines a Bus. the only differences are that a Bus takes input from "anywhere", whereas an AudioTrack takes input from its playlist (via a DiskStream) and can be rec-enabled. other than, they are basically identical. slightly off-topic, but your question leapt out at me. --p

(Either I forgot to comment on this yesterday, or I missed some stuff...) On Sunday 08 December 2002 06.52, Tim Hockin wrote: Not different *sets of controls*, but (obviously) different *instances* of them. See my earlier post about this Bay concept; a Bay may have any number of Channels, but these Channels must all be identical in terms of Control sets and other parameters, since those parameters belong to the Bay object in the initialization stage. Yes. But if you for some reason *want* two kinds of Event Input Channels, with different sets of controls (say synth channels and mixer busses), you can have that. Just have one Bay for each. May differ between Bays. (You may not want to have as many mixer busses as you have synth channels, for example.) These would belong to only Channel of the non-optional Master Bay. (Since it would make sense to use the exact same protocol for all Event Channels, this one could actually have Voice Controls as well... May sound silly, but remember that I once mentioned that a synth that supports only one Channel may use the Master Event Port for everything. That's when you'd want this.) Channels of some Event Input Bay. Same Channels of the same Bay - only different events. Or use -1 for the "voice" field when sending Channel controls - but I strongly prefer different events for complexity and performance reasons. Nicer with some more cases in the ever present event decoding switch, than if() statements inside a bunch of the cases. (And you can still merge them, if you really want to, for some reason...) Well, that's another way of describing the same thing. It's just a matter of initialization API design. Nothing performance critical or anything - just do it the cleanest and simplest way possible. Well, yes! If your violin simulator doesn't simulate the "thud" when the bow impacts the strings, what would you use velocity for? It's already decided that the "bow speed" control (whatever you call it) is the primary "loudness" control of this instrument. (That's something that should be in the hints, BTW, so MIDI->event converters and the like will have a chance of doing the right thing.) Still not 100% sure about this... I *think* you might as well use events both from the complexity POV and the performance POV, but I think I'll have to hack some actual code to be sure. Yes (MAIA philosophy again!) - but some of those state changes cannot be done inside the RT thread. And since there's no easy way to have callback driven plugins detach themselves from the RT thread, I think it's much better if they let the host worry about that, and just assume that these state changes will be requested through calls made from a suitable context. That said, you can *still* use events sent to the Master Event Port + calls to run()/process(), instead of calls to state(). However, there are less obvious problems with this. The first one I think of is that event allocation and deallocation is not inherently thread safe, so you'll have to give the plugin another host struct (different event pool, different host event port etc) before you can send that STATE event and call run()/process(). (Or the plugin would potentially crash and/or crash the RT thread upon freeing the event you sent it.) Can be done, but is there really a point? You can't really change state of a plugin in the middle of a buffer anyway, so the timestamps are of no use. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Sun, Dec 08, 2002 at 12:03:14 +0100, David Olofson wrote: Nothing, OAPI or whatever will be a superset I imagine, but that implies that LADSPA will still be simpler. - Steve

On Sunday 08 December 2002 01.02, Tim Hockin wrote: Of course. And there should be nothing preventing that. Unless I'm missing something, the only really significant difference is that LADSPA plugins don't have event ports, while "New API" plugins will. You could probably even build a simple event->control semi-wrapper into the host, to make LADSPA plugins fit in with minimal impact on the rest of the host code. LADSPA plugins will then act just like "New API" plugins that quantize timestamps to buffer boundaries. Or you can have the semi-wrapper do full or quantized buffer splitting... //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

umm, veto?

I once suggested OPI, but was stringly suggested to include 'audio' or 'sound' or something in it. Problem is that 'Plugin Interface' or 'Plugin Architecture' takes up two letters, and we all know good acronyms are THREE letters. Also 'Plugin Interface' (which I prefer to 'architecture') happens to be the last part of the already well defined 'API' acronym. Maybe we can leave that bit out? As for 'Linux' I prefer it be OS neutral. And please don't say GNU. I've converted it to PAPI for now, since it is easier to speak, and I 'speak' in my head as I write. {Portable, Public, Puerile} Audio Plugin Interface. or 'PAPI Audio Plugin Interface'? My personal preference is for something that doesn't have to be spelled to be spoken. I know most people say VSTi as 'visty'. Tim

Steve Harris wrote: Yeah, when I went to buy a SCSI Zip disk a few years ago when I was living in Austria, I was surprised to learn that they pronounce SCSI Es-Tseh-Es-I (in other words, exactly as the individual letters are pronounced in German.) In the US we say "scuzzy". I kept saying "Haben Sie ein scuzzy Zip-Laufwerk?" and getting strange looks. I've not heard anyone pronounce ls "luss" before, though. -dgm

On Sunday 08 December 2002 23.10, Steve Harris wrote: [...] Same in Sweden - although we tend not to spell "acronyms" that long... Anyway, that's another advantage of TLAs; just three letters to spell, if you're into that. :-) *hehe* //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 09 December 2002 08.54, Tim Hockin wrote: Doesn't strike me as "Wow! *This* must be The Plugin API to use!" :-) (Besides, it's four letters - but it's getting harder and harder to come up with unique, yet nice TLAs...) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

David Olofson wrote: Woops, dgm= tool. The X isn't the problem, as my earlier message would imply. What about XAP = eXtended Audio Plugins? -dgm

On Mon, Dec 09, 2002 at 01:44:03AM +0100, David Olofson wrote: Well, taking a cue from xylophones and Xerox, I would pronounce it ZAP! ... with the exclamation point ;) --PW -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"

On Monday 09 December 2002 03.14, Paul Winkler wrote: Well, that would be the american way, I guess? In swedish, we actually pronounce the X, as in Xenon (Xe) - I've heard it pronounced as "ksennawn" as well as "eksennawn" (might be easier for some to say), but never "zennawn" och anyting like that. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 09 December 2002 09.45, Tim Hockin wrote: [...XAP...] Oh, I forgot to say what I was *actually* thinking: eXtensible might actually be true, if we allow a bit of "you may see things you can't know about here - try to load a support/interface plugin for it!" (Such as the multiple datatypes mess I've been talking about every now and then.) Anyway, this night, I realized that MAIA already contains a term for that "channel kinds" thing I suggested in a previous post: "Bay". A plugin can have any number of Bays. (Hardcoded, I *think*... See below.) A Bay is described to the host with a struct or something, containing this information: struct XAP_bay_descriptor { const char *name; XAP_channel_type channel_type; int min_channels; int max_channels; /* * Maybe some other stuff */ }; If you like, you may have several Bays with Audio Input Channels, for example. These would be totally independent WRT min/max channel counts, audio format or whatever properties Audio Channels may have. Number of Bays hardcoded or not? Well, why would you ever want to *change* the number of Bays of a plugin? Well, consider a plugin that wraps other plugins... If plugins could add extra Bays as parameters change (or whatever), the wrapper plugin could just export the actual Bays of wrapped plugins, as if they were Bays of the wrapper plugin. Does that sound cool, or just insane? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 10 December 2002 02.15, Tim Hockin wrote: Correct. Well, a Channel can have p Controls OR p Audio Ports. I would say that a Channel can vave p *Slots* - where a slot can be one of: Audio Input Slot Audio Output Slot Control Input Control Output Event Ports don't really belong in this picture. They're like a flexible resource that the Plugin may use pretty much as it desires. They are owned by the Plugin instance, and their relation to Bays, Channels, Controls, phase of the moon or whatever, is controlled entirely by the Plugin. When asked to connect a Control Input, a Plugin will hand you the address of a suitable Event Port, as well as a 32 bit Control ID that the Plugin may encode in any way it feels like. (As described in an earlier post.) This is how you can chose between single Port/one Port per Channel/one Port for every N Channels/one Port per Control or whatever you might find useful, efficient or just generally cool. Actually, one event port per channel. Then I realized you don't have to specify this in the API at all! Bays are actually a way of grouping channels of the same kind together. I initially called them "Channel Kinds", until I realized that I had already "invented" the term "Bay" for exactly this thing for MAIA. You have those too? :-) Yeah, since there will probably be a few "system" events that plugins *must* implement anyway... Or maybe not. No big deal. We'll see. These won't be public. (See above.) This sounds pretty much like my Bays. You have one template for each "kind" of channel you want, and then you can have varying numbers of channels of each kind? Still a 1D array of channels, that is? I'm thinking about Bays as an array of objects that each has an array of Channels - but it doesn't have to be that way physically, obviously. I just think it seems easier with arrays of arrays (2D) since Bays have independent Channel counts, that might even change during the lifetime of the plugin. (That's another issue we have to deal with...) Mine look like this: typedef struct AEV_port { /* * Note that when 'first' is NULL, 'last' is undefined! * (If there's no first event, there can't be a last * event either - makes sense, eh? :-) */ AEV_event *first; AEV_event *last; const char *name; } AEV_port; But again, note that this is a very low level thing, that plugin and host code well nearly always treat as an opaque data type. It's part of the API, but ports don't have public names or anything. (My name field is only for debugging, so you can look at a port and see where it belongs.) Well, it just happens that channel + voice control is a very practical model for most synths. It's probably not perfect and without restrictions, but I think we can do a lot of cool stuff before seeing much of these issues. Anyway, I can see two ways of handling this: 1. Have two control ranges for Event Input Channels. 2. Allow only one range of controls per Event Input Channel, and instead, use an extra bay of Voice Control Channels, if you want Voice controls. One could mark the Bays with hints suggesting that they are closely related. Now that the strict physical relation between channels and Event Ports is eliminated, this doesn't matter at all performance wise, but it might make the API a bit cleaner. I'd rather think of Bays as being in/out neutral, and use different Channel types for input and output. Only one array of Bays needed that way. [...] Yeah, that sounds like what I have in mind. It's just that it creates some nasty issues for RT engines... I see. Bays would be different from Templates in that each Bay can have only *one* kind of objects in it. It means that relationships between for instance control inputs and audio outputs cannot be expressed by grouping them together - but I think we have concluded earlier that this is not very useful anyway. Linking Bays WRT Channel count may be useful, though... (If you have a mixer, you'd probably want exactly one strip automation control input for each stip audio input. :-) BTW, this multichannel "group" issue... That "granularity" (or "group_size" or whatever) field would be in the Bay, and would still effectively say "for one imaginary channel, you actually need N real channels". This would make that Bay linking a whole lot more useful, since it would allow M Channels on one Bay to correspond to N Channels on another. [...] //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Tuesday 10 December 2002 07.17, Tim Hockin wrote: Because then you only have to worry about types and styff for the *Bay* not for one or more Channels. Fewer dimensions of indexing when referring to things. In short, I'd prefer as much type and hint info as possible to be concentrated in as few places as possible. Here, basically *everything* is in the Bay level. The rest is just about saying how many Channels you want each Bay to have. Channels might have names, but not even that is required; you only really need to have names, type, hints and stuff on Bays. No. An Event Port is basically just a queue with both head and tail pointers. You can add events at the tail, and get events from the head; that's how communication is done normally. The physical Event Port object is what you refer to whether you're writing to it or reading from it. Event Ports that are owned by the Plugin are used for input, period. (Well, you could use them internally in whatever way you like, but that's another story entirely.) Control Output is not done through ports, but rather something I'd call a Control Output Slot, which is probably better thought of as an abstract object from the plugin POV. Internally in a plugin, it would loos omething like this: struct MY_control_output_slot { XAP_event_port *port; Uint32 control_id; }; When you're told to connect an output, you'll get * A Bay:Channel:Control address of the output control to connect. * A pointer to the Event Port to send related events to. * A control ID to mark events you send with, so the receiver knows what you're talking about. (That ID generated by the receiving plugin, remember?) Control Output of yours to the specified port, marking them with the specified control ID in the "index" field. (Or maybe we should call it "cid" or something? It may not be an index at all, and either way, senders should never try to understand the values.) Yes. I think that's as simple and yet flexible it gets. Well, the intention is that it should be thought of something like a physical "panel" or area on a real device, where you have a number of jacks, all of the same kind. For example, my Layla has one bunch of analog inputs, and one bunch of analog outputs. In MAIA, the inputs would go in one Bay, and the outputs in another. Maybe there's a better word for it. Simply "Group"? No, "Group" makes me think of something *much* more lightweight; more like something you would have on the UI level to keep physically unrelated (from the API POV) channels together. Controls are on a different level, and slightly more lightweight than Channels. Channels are physical objects, while Controls (from the API POV) exist only as indices or control IDs. So, with Audio, you have one Channel that handles exactly one mono audio stream, and that's it. With Controls, you have one Channel that has an array of Controls - but not even the *Channel* must have an Event Port. The closest you ever get to a Control of a Plugin is the control ID (or cookie) that you get when you want to connect to it. That could be useful - but I also think it's rather restrictive, and more importantly, that it doesn't belong in this level of the Plugin API. Expressing these relations is better done through some kind of lightweight hinting, IMHO. A stereo in-stereo out effect would have two input Channels (one Bay) and two Output Channels (another Bay), and at least one Control Input Channel with a bunch of Controls (a third Bay), the way I see it. There are not different controls per Channel, but rather, you may have more than one Bay of Control Input Channels - and then, each Bay may have it's own set of Controls, since the Bays are completely independent objects on the API level. Anyway, looking at most h/w synths, they have a number of channels, each controlled through it's own MIDI channel. Then there's a mixer section - but oops - there are no MIDI channels for this, so the mixer can't be controlled using normal MIDI CCs! Instead, most synths publish the mixer parameters only through custom SysEx. Now, comparing by idea to MIDI in this context, Bays would be like (physical) MIDI ports. Adding a separate Bay for mixer controls would be like adding an extra MIDI port on the synth, meant specifically for mixer control and automation. Let's compare that to the crude hack I'm currently using to let MIDI files control the mixer section. I've simply stolen a range of CCs from each MIDI channel, which are routed to a mixer channel instead of a synth channel. So, you can control 16 synth channels and 16 mixer channels. However, as of now, there are only 8 mixer channels... So what happens if you send mixer events on the other 8 MIDI channels? (Nothing.) How nice and clean is this? (Not very, IMHO.) I'd rather not have a brand new plugin API that forces me to do the same thing. Yes. However, I don't see what is made simpler with the Template approach. I'm probably missing some points, since I can't even tell for sure whether your Templates do provide the same number of dimensions of indexing or not. The reason is that the host would just see two normal Bays of Control Channels. One just happens to be hinted "these are Voice Controls for that other Bay", in case some higher levels of the host (or the user) cares. The point is that you would only need to implement "get info on Controls for Bay N" in the host, and for connections "connect to Control X, Channel Y, Bay Z". No special cases for Voice Controls. And if someone comes up with a third kind of Controls (whatever that would be), they won't need explicit API or host support either. If you don't care about Voice Controls at all, you don't even have to know they exist. Yes, I think so. It's about the same thing as with the Event Ports; if you ask for Bay:Channel (audio), or Bay:Channel:Slot (controls), or whatever and the plugin just gives you "something" to connect to, and perhaps a cookie to mark data with, the Plugin can arrange things in any way it wants physically. I see. (I realized later that the struct you proposed simply doesn't exist when you don't have Event Ports as visible objects in the API.) There is no such thing. When the host wants to connect a Control output on plugin A to a Control input on plugin B, it'll have to ask plugin B about the port and control ID of that control, and then tell plugin A to connect to that. It doesn't. There are no output ports, just Event Output Slots, as described above. The plugin just tells the host about their existence by mentioning a Bay of Control Output Channels, and then the host will assume that the plugin knows what to do when it's told to connect these outputs to various places. Exactly. We should try to avoid building more implied structure into the API than required, since that adds restrictions as well as complexity. As few different kinds of objects as possible; "everything is a..." (within reasonable limits) etc. There's just one problem: Voice Controls need an extra argument (VVID) that is irreleavant to Channel Controls. You can hint Controls as Voice Controls, mark them as different by using a different Channel Type or whatever - but fact remains: They Are Different. Voice Controls need a slightly different protocol. (Either different events, or use of an argument that's ignored by Channel Controls.) Weird things (or nothing at all) may happen if you connect Channel Control outputs to Voice Control inputs or vice versa. A Channel *is* an "I/O port" the way I think of it. A Control Channel may have multiple Controls, which is actually in conflict with my philosophy - but then again, Controls are not physical objects on the API level. Hmm... One might say that if Bays are horizontal, Templates are vertical. Since you can have multiple arrays of different types of channels inside a Template, one could say that a Template contains a bunch of something that resembles Bays. So, how about using the "Bays or Channels" system in the low level API, and then provide (optional?) information that provides the grouping information of the Templates? If a plugin provides no Templates, Bays are to be considered completely independent, except for the only hard relation I can see that they might need: Linked Channel counts. Hosts may ignore Templates entirely, and just have users go by Bay naming to figure out the relations. (Not too hard if Bays are named "Strip Inputs", "Strip Insert Outs", "Strip Insert Ins", "Strip Controls", "Bus Controls", "Bus Inserts" and things like that.) They are not, in any way I can think of. You may have only Control inputs and Audio outputs, or vice versa, and nothing is both an input and an output. That's because it's just a special case. Many real mixers indeed have insert jacks that are both inputs and outputs (stereo 6mm where one "channel" is used as the return), but that just means you'll need special cables to connect anything to it. (Anything with normal, separate inputs and outputs, that is, which goes for the vast majority of devices AFAIK.) How does that apply here? So do I. All you have to say is this: Bay 0: Type: INPUTS, CONTROL, CHANNEL Min Channels: 1 Max Channels: 1 Granularity: 1 Linked w/ Bay: -1 Channel Names: {"Control Input"} Info: <list of control names + hints> Bay 1: Type: INPUTS, CONTROL, VOICE Min Channels: 1 Max Channels: 1 Granularity: 1 Linked w/ Bay: 0 Channel Names: {"Voice Control Input"} Info: <list of control names + hints> Bay 2: Type: OUTPUTS, AUDIO, FLOAT32 Min Channels: 2 Max Channels: 2 Granularity: 2 Linked w/ Bay: 0 Channel Names: {"Left Output", "Right Output"} Info: <> ...and you have a stereo synth with one channel; both channel and voice controls. The host will eventually give you an array with two audio buffer pointers (saying it's for Bay 2, but you don't have anywhere else to put it) and then it might start to ask you for Event Port pointers and cookies for the controls you've listed for Bay 0 and Bay 1. Just give it your only event port, and return index as is for cookie. You may ignore the "channel" and "bay" arguments, since different events are used for channel and voice control. Most synths will have only outputs in the master section. Why even mention inputs if you don't have any? With Bays, you don't have to fill in zeroes in a bunch of fields for things you don't want - you just don't export any Bays for that stuff. Besides, Bays + Channel Type enum means you can add Channel Types to the API without breaking binary or source compatibility with older plugins. You might even be able to use *new* plugins in old hosts; you just won't be able to use Bays of unknown types. Why would they be different? Channels include control channels as well as audio channels in my design. Sure. And this should not be a major issue. Adding new Bays on the fly comes with a bunch of interesting problems, though - but it might not be *that* much harder. It's just that it doesn't mix well with the "host calls some plugin function to get a list of Bays during load time" design. Adding Bays would be something that a plugin *instance* does spontaneously through a host callback, as a result of a control change or something. That's not a nice assumption to make, IMHO. Hosts and plugins should at least not be explicitily *prevented* from doing this stuff in real time. (This is another reason to proide some form of generic "call this function from some other thread" feature in the host. Standard hosts would just do it in the RT thread and take the risk of a drop-out, but more sophisticated implementations would be possible.) Ok, but I think there's a lot of "I don't want this and I don't want that..." filling in to do, and also hard restrictions built into the API. Small, simple structs and enums allow you to extend things later on without breaking minary compatibility, and it also allows plugins to *completely* ignore things they don't care about. I don't think they are. This is just a special case that applies to mixers and some other things. Exactly. That's why I don't even want to *suggest* anything about 1:1 relationships on this level. :-) The only required feature I can see is this "link" thing, which you only use when two or mora Bays actually *have* 1:1 relations. Yes. I'm suggesting that we use as small and simple objects as possible, and have one for each type of channel we actually want. What I don't like about your design is basically that the set of supported connection types (audio and control) is hardcoded into the Template struct, rather than available as an enumeration or similar. Yeah, I think we're getting somewhere here. Some real hard problems have been solved in rather nice ways, and it seems like we're mostly arguing about cosmetic details and how to balance simplicity and flexibility. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Wednesday 11 December 2002 01.42, Tim Hockin wrote: You could say the Channel *is* the port (either I or O) for audio, whereas for Controls, it's more like MIDI and CCs; one Channel has an array of Controls. Not from the host side - but that's rather unimportant. (Stuff that goes into the host SDK anyway.) Yes, that's about it. Bays can have only one array of Channels of a specified type, whereas Templates have one array of each supported Channel type, some of which may be disabled by allowing only 0 Channels. Yeah, that's about it. The word Channel isn't appropriate for this... Maybe Port or Jack would be better - but neither works very well with both audio and controls. Besides, those Control Channels/Ports/Jacks may take other events than Control events - we need to deal with those as well. Well, how explicit does it have to be? Isn't the fact that the very meaning of the link feature is to tell the host (and everyone else) that there *is* a 1:1 mapping sufficient? Then, how is grouping them in a struct used during initialization? Both are effectively just data as soon as the plugin is actually instantiated. *heh* Yeah, Ports would be better. (And these Event Ports should be renamed Event Queues or something.) Yeah, probably. We can't know in what way the API will be extended at this point, so preparing for it isn't worth all that much. [...] Or we can use host callbacks, or build a queue of events to describe the plugin. (The latter is what the tiny MAIA prototype did.) More flexible, but may not look very clean... One advantage is that if you forget to send something, the host will notice that it never came in, so you won't have garbage or non-intentional NULLs without knowing about it. *hehe* Well, most useful types probably require some level of host support, so it's probably not very useful. It could work for custom audio formats, custom events and that kind of stuff, but even then, you'd need host support for managing buffers of custom sizes. (Interleaved multichannel for inter-plugin busses and that kind of stuff.) We'll see when we've dealt with the *basic* issues. :-) [...] But that's something decided by the plugin author - not by the API. Either way, I think the issue I'm getting at here can be solved either way. Just have multiple Templates. Yeah! Actually, no. The relation is this: The channel control bay, the voice control bay and the audio in bay must have the same number of Channels. That's what the link field means; "I must have the same number of Channels as Bay X." (I didn't say that anywhere? Oops...) Yeah. There are too many objects in this design, or too many of them have inappropriate names... *heh* Yes indeed. Ok. Here's another confusion. (Probably caused by me not describing what "linked bays" actually mean.) A Bay would not have controls, but each one of it's Channels would. Channels are indeed a lot like MIDI channels in this respect. A preset should always be for the entire Plugin. A Bay is just a bunch of Channels, all of the same kind, so slicing that way would basically be like storing a preset for all the faders of a mixer, but not the other controls on each strip. (Although in the API, all strip controls would obiously be on the same Bay normally.) That's a good questing, actually - and it demonstrates this need to deal with events that are *not* about controls. There will most probably be a few of those, but frankly, I can't tell for sure whether they're *really* needed or not. For example, you could express note on/off "events" as changes of a control "velocity" to positive and negative values, respectively. You would have to hint the control as "change trigged" rather than "continous", to make hosts and users aware of the fact that something that sends continous velocity will do strange things with this instrument. Anyway, no, events can be about other things as well. I would propose that the term "Audio Port" is used for audio, and that the term "Control Port" replaces this silly "Control Channel" thing. That way, a Port is just something you use to make a connection to a Channel - regardless of whether we're talking about audio or controls. A Channel would then refer *only* to an abstract object inside the plugin. But there's a problem with this as well: The Channels of a Plugin don't *have* to be all of the same kind... For example, a Mixer would have Strip Channels as well as Bus Channels. The former would have a control port and some audio ports each, while the latter would have a control port and some audio ports as well, but a different set of controls and possibly different numbers of audio ports. So, what's the big deal? Well, nothing - just that it might be rather confusing if there can be several "Channel 3" in the same Plugin, that are in fact completely different things. One could be mixer strip 3, while the other would be bus strip 3... *Unless* all ports that belong to one "class" of Channels are kept in one "container" with a sensible name. Maybe that would be a Bay, provided that a Bay can have multiple types of Channels. Yes - although referring to an EventQueue as an output might be more confusing that helpful. A Plugin will *never* use an EventQueue for output, but rather just send each event to whatever EventQueue the host told it to send that kind of events. Often, the EventQueues you send to are the actual input EventQueues of other Plugins, but they may also be Shadow EventQueues that the host use to get a chance to efficiently sort/merge events when multiple senders are intended to send to the same EventQueue. Yes. The BayTemplate also contains info on how many Ports (as in my "Audio Port" or "Control Port") the Bay may have. BTW, granularity: That's about grouping Ports together. For example, stereo pairs would be expressed as a granularity of 2, which means that you must allocate even numbers of Ports on this Bay, and that all Ports in each granule belong to the same Channel. This now appears to be a mess that is not needed if you can have multiple arrays of Ports of the same type, that are linked together by other means. So, instead, the stereo pairs could be expressed as two Bays, linked together in Port Count, both with Audio Input Ports. One Bay would be named "Left Inputs" and the other "Right Inputs". My idea is to have exactly one instance of each BayTemplate. No, that's a misunderstanding - my Bay instance is exactly what you describe here. (And the term Channel as I used it then would correspond to your Port.) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 12 December 2002 09.28, Tim Hockin wrote: An array of them actually. Oh, well... My original terminology was indeed confusing, so I would like to mention that Channels are abstract objects, while these things that can have only one I/O are *Ports*. One Channel may have multiple Ports of various kinds. Question is how to describe them to the host and users. I think there are better ways, though. How would you do that - and how would anyone know that Ports belong together in pairs, one pair per Channel? Then we'll need that granularity thing again... We're just pushing the problem around here. [...Total Control chassis...] Yes... No matter how we keep turning things around and inside out - I don't think there is a single structure that fits all, without having a rather large number of indexing dimensions. All "sensible" solutions are only sensible for a few kinds of plugins. *heh* And I'm beginning to think that there is no point in doing that. :-) What is a stereo I/O? How is it described, and how do you index them when making connections? This was what granularity was about; specifying that one Channel corresponds to a certain number of Ports in this Bay, so you can have stereo, 5.1 or whatever. Physically, the ports are just one long 1D array, but the granularity field bundles them together in a "soft" structure that may be of use to hosts and users. It also makes linking of Bay Channel counts useable, since you link *Channel* counts, rather than Port counts. So, if the synth has one Control Port for each set of 5.1 (6 audio Ports), you get one Control Port (in the Control Bay) and 6 audio Ports (in the Audio Bay) for each Channel. I'm not all that happy about this any more, though. Read on. Nor am I... Agreed! :-) Well, I did it in the headers as well. Now, I just call them Queues - since there is only one kind of them in the system anyway. Yes. It's just that we tend to get too many dimensions whatever we try... Well, I already have "User Events" in the headers... I'm not sure I want to think about the implications of that right now, though! :-) Either way, if we can make sense of this Bay/Channel mess, I suspect that at least multiple audio datatypes will fit in rather nicely. It's kind of like the note/linear pitch thing; equal type IDs fit, different IDs do not, and need conversion. So, if everyone just uses float32, there's basically no difference from having *only* float32. Port types will have to be compared before connections are made anyway. Yes. Some will have multiple *kinds* of 1:1 relations. (Mixer strips and bus strips.) Yeah. "Soft" description of a hard relation. So, if we remove both, we can get away with only Channels and Ports? ;-) Ok. Right. Well, yeah, considering that we're talking about multichannel synths, it would actually be pretty much a *required* feature. Didn't think of that, for some reason... (Probably just forgetting that the host really *is* supposed to handle *all* preset data.) Yes... Connections, possibly. Since a plugin just gets a pointer and a cookie, there are no RT issues with this - and so the host may as well feed the data to plugins through events, instead of function calls. Sample accurate timing for (dis)connections - whatever that might be useful for. Tempo changes? And these scary User Events, should we decide to allow them at all. Can't think of much, really. Most things are best described as Controls - and those are manipulated using a small set of standard Events. [...] Or a bunch of them - or you see one that's shared by multiple Control Ports. Doesn't matter, as you're simply supposed to send Events to whatever Queue the plugin tells you to use. :-) Yes... Well, the problem with addressing Channels 1D is that Channels move around if you change the number of Channels of a certain kind. So, you're pretty much forced to reinstantiate the plugin to change the Channel count. Anyway, the term "Bay" needs to be redefined, I think. But it introduces the need for Events to contain full target addresses, and for the Host to dispatch the Events to the various target Ports they're meant for. Theoretically, every single output Control may be connected to it's very own Queue. Nope. You kill the "automatic" Event routing that sending directly to Queues brings. That too. With direct sending, the only extra work ever done is for these shadow queues that are needed sometimes. Other than that, the only checking is the one that Plugins have to do all the time anyway. Yes, but why? (Except for studying the event flow into plugins, obviously. Hmm... There is an upcoming market for cool debugging plugins here. :-) Exactly. NULL Queue pointer means we ignore anything to do with that Control output. (Or if you have *lots* of Controls, just keep all connected Controls in a list, and use that as a task list. Plugin author's choice.) It will have to explicitly tell the Plugin to disconnect a Control, before actually removing the target Queue or anything - or Bad Things(TM) will happen. The point here is that I don't want to have the Host directly mess with pointers and stuff that the Plugins use. I'm not even sure that should be allowed for Audio Ports... For MAIA, I had this idea about using events for changing audio buffer pointers. That way, you could change buffers in the middle of the process() call, and even have plugins deal directly with buffers of different sizes. However, there is one major problem with that, which becomes obvious when you actually try to implement an event controlled plugin: It is no longer straightforward to use buffer pointers + indices in the inner loop. If you studied my example from Audiality, you might have noticed that there's an offset tracking the start of each "fragment". That offset would all of a sudden become invalid if buffer pointers are allowed to change mid-buffer! So, we might as well do it fast and simple: Hand arrays of host controlled buffer pointers to Plugins. That's not my original idea of a Bay - but it's closer to what I have in mind now. Ok... A few questions on this: * Is a *_channel_desc able to express whether it's an output or input? * What is the relation between control and I/O channels? * How would you handle say, ctrl in + one audio in + two audio out? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

On Thursday 12 December 2002 22.26, Tim Hockin wrote: [...] But the host is allowed to assume that it is in fact an *index*; not just a cookie? Comparing this to Control Input cookies, the latter can be anything, and you *could* say they can have up to 32 dimensions theoretically. (The plugin can do whatever it wants with them.) Obiously, it's not recommended to ever think of these as indices anywhere outside the plugin that created them and understands them. :-) [...] I see. (No problem as long as there is no assumption that anything is both an input and an output and that kind of stuff.) How about a mixer with variable insert count? There are several ways to implement that, but I can't think of one that doesn't require either that dreaded "link" feature, or an extra level of "grouping"... So, you basically have a bunch of control channel descriptions and a bunch of io channel descriptions, and then the host can test for valid combinations of those when adding new channels? Interesting idea - but why restrict it to one ctrl and one io per channel? What I'm thinking is, why not just have Port Templates, and then think of Channels as abstract objects to which you may attach various numbers of Port Sets (instance of Port Templates) of various kinds. Or mabybe we should use the term Bay for this concept? /* * This struct describes a single type of Bay. * A Plugin may have any number of Bay Templates. * A Bay is an object that contains a 1D array of * Ports, all of the same type, and the Bay Template * defines the type of those Ports, as well as * min/max count and other info. */ struct XAP_bay_tmpl { const char *name; /* Name of the Bay type */ XAP_port_types type; /* Type of the Ports */ int min; /* Minimum # of Ports */ int max; /* Maximum # of Ports */ const char **labels; /* Port labels (*) */ XAP_control *controls; /* (ignored for Audio Ports) */ }; (*) Given that you can have Bays with variable Port counts, it might be a better idea to provide a call or something for hosts to get the Port labels after setting or changing the Port count. I'm thinking in terms of 1 Port ==> "mono" vs 2 Ports ==> "left", "right". I don't like the last field, but rather that than different kinds of templates... I think. Maybe there are better ways. Expressing the whole Bay Template as a string could work... I think I like that idea. Either way, next; there are two approaches, simple... /* * This describes a single type of Channel. * A Plugin may have any number of Channel Templates. * A Channel Template defines one valid combination * of Bays that can form one Channel instance. * A Channel may contain any number of Bays. * Bays are not optional, and each entry in the * Channel template corresponds to exactly one Bay * in a Channel instance. */ struct XAP_channel_tmpl { const char *name; /* Name of this type of channel */ int nbays; /* Number of Bays */ const char **labels; /* Bay labels */ XAP_bay_tmpl **templates; /* The Bay Templates */ }; ...or a bit more flexible... /* * This struct forms one entry in the list of * Bay Templates referenced by a Channel Template. * The Bay Strip describes a 1D array of identical * Bays. If min < max, the Bay count in the Strip * is variable. */ struct XAP_bay_strip { const char *name; /* Name of this array of Bays */ int min; /* Minimum # of Bays of this kind */ int max; /* Maximum # of Bays of this kind */ const char **labels; /* Labels for the Bays */ XAP_bay_tmpl *template; /* The Bay Template */ }; /* * This describes a single type of Channel. * A Plugin may have any number of Channel Templates. * A Channel Template defines one or more valid * combinations of Bays that can form one Channel. * A Channel may contain any number of Bays. */ struct XAP_channel_tmpl { const char *name; /* Name of this Channel type */ int min; /* Min # of channels of this kind */ int max; /* Max # of channels of this kind */ int nstrips; /* Number of strips */ const char **labels; /* Names for the strips */ XAP_bay_strip **strips; /* The Bay Strips of this Channel type */ }; (Note that there are some inconsistencies WRT what min/max and labels/names apply to. That's confusing and must be dealt with.) Now, one way or another, the Host gets a bunch of XAP_channel_tmpl structs, and then it can start asking for instances of those. That sounds pretty cool. I'm not sure I'm seeing the full picture yet, though; I'll have to thing some about it. Yeah. The only problem with that is that you can't have multiple "groups" of Ports of the same type in a ChannelDesc. There is only room for one group of control inputs, one group of audio inputs etc. My proposal above is essentially the same structure, but makes the ChannelDesc dynamic, so you don't have to add extra ChannelDescs for extra Ports. For example, the audio ins and outs of a mixer strip would be for the input and bus sends. Where would you fit the inserts? How would you support variable numbers of inserts? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---

Here is a draft incorportaing a lot of what we've talked about. It is missing a lot, and some is probably wrong/inconsistent. We've been talking a LOT. :) Notes: * All VVID stuff is missing * All pitch stuff is missing * Currently uses a monolithic ChannelType for channels until actual answer is decided (though I rather like the simple monolith) * several things are not commented or are insufficiently commented * Several FIXMEs * several things still on the TODO list Have at it... Tim /* $Id: $ */ /* * Tim Hockin &lt;thockin(a)hockin.org&gt; * Copyright (c) 2001-2002 Tim Hockin * * This header file defines the API for the XAP - the XAP Audio Plugin * interface. * * Goals: * The main goal of this API is to provide an API that is full-featured * enough to be the primary plugin system for audio-development * applications, while remaining as simple, lightweight, and self-contained * as possible. * * Credits: * This API originated from LADSPA by Richard W.E. Furse et al. and evolved * through dialog between Tim Hockin, David Olofson, Steve Harris, and * others via the linux-audio-devel mailing list * (linux-audio-dev(a)music.columbia.edu). * * Overview: * Plugins are loaded from shared object files. A shared object file holds * one or more plugin descriptors, accessed by index. Each descriptor holds * all the information about a single plugin - it's identification, * capabilities, controls, and access methods. */ #ifndef XAP_H__ #define XAP_H__ #ifdef __cplusplus extern "C" { #endif #include <stdint.h> /* * The current version of the API: read as "major.minor.micro". */ #define XAP_VERSION 0x000010 #define XAP_MKVERSION(maj, min, mic) (((mar)<<16) | ((min)<<8) | (mic)) /* * A single audio sample: this datatype is used for passing audio data * between plugins and hosts. Data is normalized between -1.0 and 1.0 * as the 0dB value, with 0.0 being silence. */ typedef float XAP_sample; /* the fundamental XAP types */ typedef struct XAP_descriptor XAP_descriptor; typedef struct XAP_channel XAP_channel; typedef struct XAP_port XAP_port; typedef struct XAP_host XAP_host; typedef struct XAP_control XAP_control; typedef enum XAP_ctrl_type XAP_ctrl_type; typedef struct XAP_ctrl_int XAP_ctrl_int; typedef struct XAP_ctrl_float XAP_ctrl_float; typedef struct XAP_ctrl_enum XAP_ctrl_enum; typedef struct XAP_ctrl_string XAP_ctrl_string; typedef struct XAP_raw_data XAP_raw_data; typedef struct XAP_ctrl_raw XAP_ctrl_raw; typedef struct XAP_event_port XAP_event_port; typedef struct XAP_event_queue XAP_event_queue; typedef struct XAP_event XAP_event; typedef enum XAP_event_id XAP_event_id; typedef uint32_t XAP_timestamp; /* * A plugin descriptor: this structure describes what an plugin can do. * Every plugin has exactly one descriptor, which the host must treat as * READ-ONLY. */ struct XAP_descriptor { /* * The ID is a bitmask of the vendor code (high-order 16 bits) and * the product code (low-order 16 bits). The vendor code is * assigned by a central authority, and the product code is vendor * assigned. For plugins that are in development, or for vendors * who have not yet received a vendor code, the vendor code field * should be 0. Vendors/authors MUST NOT distribute plugins with * the vendor code set to 0. */ uint32_t xap_id; /* * The api is the XAP_VERSION that this plugin understands. Hosts * should use this to allow older plugins to load without * overstepping the plugin's capabilities. */ uint32_t xap_api; /* * The serial is simply a number by which the host can compare two * versions of a plugin and pick the later version. The actual * value has no meaning to the host. The only requirement for this * field is that the value never gets smaller in new releases. */ uint32_t xap_serial; /* * The label is a file-unique, non-whitespace, string identifier for * the plugin. Hosts can use the filename and label to identify a * plugin uniquely. The label is all upper case, by convention. */ const char *xap_label; /* * The name is an arbitrary string, which hosts can display to * users. */ const char *xap_name; /* * These are display-friendly fields, which hosts can display to * users. */ const char *xap_version; const char *xap_author; const char *xap_copyright; const char *xap_license; const char *xap_url; const char *xap_notes; /* master controls and I/O */ int xap_n_controls; XAP_control **xap_controls; int xap_n_ports; XAP_port **ch_ports; /* channel descriptors */ int xap_n_channel_types; XAP_channel *xap_channel_types; //FIXME: how to get the num/info currently instantiated channels? //FIXME: enumerate negative return values == better error reporting /* * create: instantiate the plugin * * This method is used to create an instance of the plugin described * by the descriptor. Memory will be allocated and state will be * initialized in this method. * * Arguments: * descriptor: a pointer to the plugin descriptor. * host: a pointer to the host callback structure. * rate: the host sample rate (see xap_set_rate below). * * Returns: * This method returns a pointer to a plugin-private handle. If * initialization fails for any reason, this method must return * NULL. */ void *(*xap_create)(XAP_descriptor *descriptor, XAP_host *host, int rate); //FIXME: how to enumerate errors from this? //FIXME: return something better than void *? /* * destroy: destroy an instance * * This method is used to destroy and clean up after an instance of * the plugin. All allocated resources must be released. After * this method is invoked, the plugin handle is no longer valid. * This function can not fail. * * Arguments: * plugin: a pointer to the plugin instance. * * Returns: * This method does not return a value. */ void (*xap_destroy)(void *plugin); /* * set_rate: set the sample rate * * This method may only be called on plugins that are not active. * There is no required set of supported sample rates, but plugins * should support the common sample rates (44100, 48000, 96000) to * be generally useful. Hosts should always check that all plugins * support the desired sample rate. * * Arguments: * plugin: a pointer to the plugin instance. * rate: the desired sample rate. * * Returns: * This method returns 0 on success and -1 if the sample rate is * not supported or some error occurred. */ int (*xap_set_rate)(void *plugin, int rate); /* * activate: prepare a plugin for running * * This method is used to prepare a plugin before being run. This * is an optional method, and if provided, will be called once * before the first call to the run() method. This method will not * be called again by the host until the deactivate() method has * been called. Plugins may interpret or ignore the quality * parameter as they see fit. * * Arguments: * plugin: a pointer to the plugin instance. * quality: an integer between 1 (lowest) and 10 (highest). * * Returns: * This method returns 0 on success and -1 on error. */ int (*xap_activate)(void *plugin, int quality); /* * deactivate: stop a plugin after running * * This method is used to shut down a plugin when the host is done * running it. This method, if provided, will be called at least * once some time after a call to the activate() method and before * the destroy() method. Hosts may use the deactivate()/activate() * pair as a way to reset the plugin's state. * * Arguments: * plugin: a pointer to the plugin instance. * * Returns: * This method returns 0 on success and -1 on error. */ int (*xap_deactivate)(void *plugin); /* * connect_port: connect buffers for data * * Hosts must connect ports to buffers in order for a plugin to * operate. The Plugins are expected to handle the case of the * input buffer being the same as the output buffer (in-place * operation) transparently to the host. The host must connect * every port except if the host and plugin agree to disable a * port (see xap_disable_port), in which case it does not need to * be connected. * * Arguments: * plugin: a pointer to the plugin instance. * channel: the channel number or CHANNEL_MASTER * port: the port number (zero-based value). * buffer: the buffer in which to read/write audio data. * * Returns: * This method returns 0 on success and -1 on error. */ int (*xap_connect_port)(void *plugin, int channel, int port, XAP_sample *buffer); /* * disable_port: request that a port not be used. * * If a host does not want the plugin to operate on a given port, it * may ask the plugin to disable the port. This method is optional, * but highly recommended if the plugin can save cycles. If the * plugin provides this method and this method succeeds, the port * does not need to be connected. If this method is not provided, * or this method fails, the host must follow normal port connection * rules. If a host disables a port and later connects it, the port * is enabled. If the host wishes to disable it again, it must call * this method again. * * Arguments: * plugin: a pointer to the plugin instance. * channel: the channel number or XAP_CHANNEL_MASTER * port: the port number (zero-based value). * * Returns: * These methods return 0 on success and -1 on error. */ int (*xap_disable_port)(void *plugin, int channel, int port); /* * get an event port, XAP_CHANNEL_MASTER for master */ XAP_event_port *(*xap_event_port)(void *plugin, int channel, int index); /* * run: use the plugin * * This method invokes the plugin for a number of audio samples, * which are provided on connected ports. * * Arguments: * plugin: a pointer to the plugin instance. * nsamples: the number of samples available on port buffers. * * Returns: * This method returns 0 on success and -1 on error. */ int (*xap_run)(void *plugin, int nsamples, XAP_timestamp now); }; struct XAP_channel { char *chan_label; char *chan_name; uint32_t chan_flags; /* how many instances of this channel are allowed? */ int chan_count_min; int chan_count_max; /* channel controls and I/O */ int chan_n_controls; XAP_control **chan_controls; int chan_n_ports; XAP_port **chan_ports; }; /* an audio port */ struct XAP_port { char *port_label; char *port_name; char *port_hints; uint32_t port_flags; }; /* flags for various control types */ #define XAP_PTFL_INPUT_P 0x01 #define XAP_PORT_IS_INPUT(port) ((port)->flags & XAP_CTFL_INPUT_P) #define XAP_PORT_IS_OUTPUT(port) (!((port)->flags & XAP_CTFL_INPUT_P)) /* common port labels - a good source of hints to the host! */ #define XAP_PORTHINT_MONO "MONO" #define XAP_PORTHINT_FLEFT "FRONT_LEFT" #define XAP_PORTHINT_FRIGHT "FRONT_RIGHT" #define XAP_PORTHINT_FCENTER "FRONT_CENTER" #define XAP_PORTHINT_RLEFT "REAR_LEFT" #define XAP_PORTHINT_RRIGHT "REAR_RIGHT" #define XAP_PORTHINT_SUB "SUB" #define XAP_PORTHINT_SLEFT "SURR_LEFT" #define XAP_PORTHINT_SRIGHT "SURR_RIGHT" /* * A XAP host: this provides callbacks for plugins to access host-provided * resources. This puts control of things such as failures in the hands of * the host, not the plugin. */ struct XAP_host { //FIXME: some sort of host ID/version ? uint32_t host_api; //FIXME: how does the host know where an event came from? XAP_event_queue *host_queue; void *(*host_malloc)(size_t size); void (*host_free)(void *ptr); void *(*host_realloc)(void *ptr, size_t size); void (*host_alloc_failure)(void); //FIXME: get_buffer(int nsamples) ? //FIXME: free_buffer() ? //FIXME: get_silent_buffer(int nsamples) ? }; struct XAP_event_port { XAP_event_queue *evp_queue; uint32_t exp_cookie; }; /* the various types that a control may be */ enum XAP_ctrl_type{ XAP_CTRL_INT = 1, XAP_CTRL_FLOAT = 2, XAP_CTRL_ENUM = 3, XAP_CTRL_STRING = 4, XAP_CTRL_RAW = 5, }; /* for declaring ctrl sub-types */ #define XAP_CONTROL_COMMON_FIELDS_ \ /* \ * Label is a unique (within this plugin), non-whitespace string \ * identifier. The label is all upper case, by convention. \ */ \ const char *ctrl_label; \ /* display-friendly name */ \ const char *ctrl_name; \ /* hints to the host */ \ const char *ctrl_hints; \ /* the type of control */ \ XAP_ctrl_type ctrl_type; \ /* global and per-type flags - XAP_CTFL_* */ \ uint32_t ctrl_flags; \ /* hints about real-time behavior of controls - XAP_RTFL_* */ \ uint32_t ctrl_rtflags; /* a knob, button, etc. of a plugin */ struct XAP_control { XAP_CONTROL_COMMON_FIELDS_ }; /* to help in declaring arrays of pointers to structs statically */ #define XAP_DECL_CONTROL(type) (XAP_control *)&(XAP_ctrl_ ## type) /* the expanded structs for each control type */ struct XAP_ctrl_int { XAP_CONTROL_COMMON_FIELDS_ int ctrl_min; int ctrl_max; int ctrl_default; }; struct XAP_ctrl_float { XAP_CONTROL_COMMON_FIELDS_ float ctrl_min; float ctrl_max; float ctrl_default; }; struct XAP_ctrl_enum { XAP_CONTROL_COMMON_FIELDS_ int ctrl_min; int ctrl_max; int ctrl_default; const char **ctrl_options; }; struct XAP_ctrl_string { XAP_CONTROL_COMMON_FIELDS_ const char *ctrl_default; }; struct XAP_raw_data { int raw_size; /* bytes */ void *raw_data; }; struct XAP_ctrl_raw { XAP_CONTROL_COMMON_FIELDS_ XAP_raw_data *ctrl_default; }; /* flags for various control types */ #define XAP_CTFL_PERVOICE_P 0x01 #define XAP_CTRL_IS_VOICE(ctrl) ((ctrl)->flags & XAP_CTFL_VOICE_P) #define XAP_CTRL_IS_CHANNEL(ctrl) (!((ctrl)->flags & XAP_CTFL_VOICE_P)) #define XAP_CTFL_INPUT_P 0x02 #define XAP_CTRL_IS_INPUT(ctrl) ((ctrl)->flags & XAP_CTFL_INPUT_P) #define XAP_CTRL_IS_OUTPUT(ctrl) (!((ctl)->flags & XAP_CTFL_INPUT_P)) #define XAP_CTFL_HARDLIM_P 0x04 #define XAP_CTRL_IS_HARDLIMIT(ctrl) ((ctrl)->flags & XAP_CTFL_HARDLIM_P) #define XAP_CTRL_IS_SOFTLIMIT(ctrl) (!((ctl)->flags & XAP_CTFL_HARDLIM_P)) //FIXME: renumber, re-examine #define XAP_CTFL_SCALAR 0x01 /* is scalar to the sample rate */ #define XAP_CTFL_LOG 0x02 /* is logarithmic */ #define XAP_CTFL_FILE 0x04 /* is a file name */ #define XAP_CTFL_DIR 0x08 /* is a directory */ #define XAP_CTFL_BOOL 0x10 /* is a boolean */ #define XAP_CTFL_FRAMES 0x20 /* is a measurement of frames */ #define XAP_CTFL_RDONLY 0x40 /* is read-only */ /* flags to identify real-time behavior of controls */ #define XAP_RTFL_NEVER 0x01 /* is never RT safe */ #define XAP_RTFL_MALLOC 0x02 /* allocates/frees memory */ #define XAP_RTFL_HMALLOC 0x04 /* allocates memory through the host */ #define XAP_RTFL_HFREE 0x08 /* frees memory through the host */ #define XAP_RTFL_FILEIO 0x10 /* performs file I/O */ #define XAP_RTFL_SLOW 0x20 /* is 'slow' in general */ /* common control labels - a good source of hints to the host! */ #define XAP_CTRLHINT_VELOCITY "VELOCITY" //voice #define XAP_CTRLHINT_AFTERTOUCH "AFTERTOUCH" //voice #define XAP_CTRLHINT_CHPRESSURE "CHPRESSURE" //channel #define XAP_CTRLHINT_PITCH "PITCH" //channel,voice #define XAP_CTRLHINT_MODULATION "MODULATION" //channel,voice #define XAP_CTRLHINT_BREATH "BREATH" //channel,voice #define XAP_CTRLHINT_FOOTPEDAL "FOOTPEDAL" //channel,voice #define XAP_CTRLHINT_PORTATIME "PORTATIME" //channel,voice #define XAP_CTRLHINT_VOLUME "VOLUME" //channel,voice #define XAP_CTRLHINT_BALANCE "BALANCE" //channel,voice #define XAP_CTRLHINT_PAN "PAN" //channel,voice #define XAP_CTRLHINT_EXPRESSION "EXPRESSION" //channel,voice #define XAP_CTRLHINT_HOLDPEDAL "HOLDPEDAL" //channel,voice: bool #define XAP_CTRLHINT_PORTAMENTO "PORTAMENTO" //channel,voice: bool #define XAP_CTRLHINT_SOSTENUTO "SOSTENUTO" //channel,voice: bool #define XAP_CTRLHINT_SOFTPEDAL "SOFTPEDAL" //channel,voice: bool #define XAP_CTRLHINT_HOLD2PEDAL "HOLD2PEDAL" //channel,voice: bool #define XAP_CTRLHINT_SNDTIMBRE "SNDTIMBRE" //channel,voice #define XAP_CTRLHINT_SNDRELEASE "SNDRELEASE" //channel,voice #define XAP_CTRLHINT_SNDATTACK "SNDATTACK" //channel,voice #define XAP_CTRLHINT_SNDBRIGHT "SNDBRIGHT" //channel,voice #define XAP_CTRLHINT_FXDEPTH "FXDEPTH" //channel,voice #define XAP_CTRLHINT_TREMELO "TREMELO" //channel,voice #define XAP_CTRLHINT_CHORUS "CHORUS" //channel,voice #define XAP_CTRLHINT_CELESTE "CELESTE" //channel,voice #define XAP_CTRLHINT_PHASER "PHASER" //channel,voice #define XAP_CTRLHINT_POLYPHONY "POLYPHONY" //channel #define XAP_CTRLHINT_TEMPO "TEMPO" //channel #define XAP_CTRLHINT_VOICECTRL "VOICECTRL" //channel //FIXME: describe these controls, maybe have a macro to declare them [0.0-1.0] // or [-1.0 to 1.0] or whatever /* An event queue - where events are actually stored */ struct XAP_event_queue { XAP_event *evq_first; XAP_event *evq_last; }; /* * An event - passed to plugins on their XAP_event_queue. The ev_time field * is a sample count, from some arbitrary start. Hosts pass the timestamp * of the start of the buffer to the plugin run() method. */ struct XAP_event { XAP_event *ev_next; uint32_t ev_cookie; XAP_timestamp ev_time; XAP_event_id ev_event; uint32_t ev_voice; XAP_event_ramp ev_ramp_type; XAP_timestamp ev_ramp_length; }; /* The known events */ enum XAP_event_id { XAP_EVENT_NULL = 0, XAP_EVENT_CTRL = 1, }; /* ramp styles */ enum XAMP_event_ramp { XAP_RAMP_NONE = 0, XAP_RAMP_LINEAR = 1, }; /* how the host learns about the plugin */ XAP_descriptor *xap_descriptor(int index); /* * utility functions */ /* return true if time0 is after time1 */ static inline int xap_time_after(XAP_timestamp time0, XAP_timestamp time1) { return ((long)(time1) - (long)(time0) < 0); } #define xap_time_before(t0, t1) xap_time_after(t1, t0) /* return true if time0 is after or equal to time1 */ static inline int xap_time_after_eq(XAP_timestamp time0, XAP_timestamp time1) { return ((long)(time1) - (long)(time0) <= 0); } #define xap_time_before_eq(t0, t1) xap_time_after_eq(t1, t0) #ifdef __cplusplus } /* extern "C" */ #endif #endif /* XAP_H__ */

Generally I agree with David, but there are a few things wher I dont: On Fri, Dec 13, 2002 at 02:30:32 +0100, David Olofson wrote: LADSPA has them and its useful sometime, eg. for selecting plugins in command line apps, and for developers. Well, you might want to refuse to instantiate, based on the sample rate. This should not be allowed, if you want to run the instrument at a different rate, reinstantiate it. Agreed. I think tis less confusing to have to indicate that a plugin /is/ deterministic though. Don't do what ladspa did though and mix together RT safe-ness and determinicity (is that a real word?). And many of us still think doesn't belong in the API... :) - Steve

On Fri, Dec 13, 2002 at 05:22:06 +0100, David Olofson wrote: Yes. Redundancy in APIs is as bad as missing features. But it duplicates pitch. If you dont allow note_pitch then you dont miss out on anything, all the plugins that would be possible still are, it just makes a small number of specialised actions *slightly* harder. I haven't seen any convincing argument that it isn't redundant and likly to cause problems. - Steve

On Friday 13 December 2002 7:05 pm, David Olofson wrote: ...but what's been said recently about note_pitch and scales means that you have to just "guess" what scale you're in anyway. Solution: have a hint on the input that says it's expecting (1/12)/note. That way it does make sense to cast between them. Simple. It is to me. I think you have to understand that anyway in the other system. At least in this case only the people who actually want to use scale converters have to understand them. The note_pitch thing isn't just about sanity checks, though, it's a completely different representation of the same thing. You can't prove a negative. I think that it's possible for it to cause quite big problems, which is why I'm still harping on about it.

On Fri, Dec 13, 2002 at 11:47:13 +0100, David Olofson wrote: Right, so dont allow plugins to talk notes... I still dont think its necceasry, its just programmer convienvence. If you dont have it there cant be any compatibility problems. No, thats right, its not explicity related to a scale, thats what makes it so useful. When? What examples did the VST people give for wanting this? - Steve