On Monday 03 March 2003 07.49, [EMAIL PROTECTED] wrote: [...] > > Yes, although it might make sense to have a standard > > "SILENCE_THRESHOLD" control, so hosts can present it as a central > > control for the whole net, or for a group of plugins (mixer > > inserts, fo example), or whatever. Where it's not present, the > > host will assume that the plugin consideres only absolute > > silence, provided the plugin supports silence at all. > > ok ... so we are going one level up now... > standard names for controls...
Yeah, that's how we intend to hint which controls go where when connecting plugins. It's handy for users, and hosts can use it for automatic "cable" connections. "PITCH goes to PITCH, VELOCITY goes to VELOCITY, ..." [...] > how will the silence be indicated ? Each buffer will probably be a struct, containing a buffer pointer (which will always be valid for outputs) and a flag field. At least, that's the way I do it in the Audiality mixer, and it's quite handy. > NULL is not so good for inplace processing :) Right. :-) I use that in Audiality for the FX plugins, but those can only be stereo in, stereo out. Obviously, it doesn't work with the single pointer inplace version of the process() call, but that's a silly idea anyway. (Inplace is better done with separate in and out pointers and a replacing process() call.) > is there inplace processing in XAP ? I'm not sure if we have decided on this. At first though, it seems like it would just be a matter of a flag saying whether or not a plugin can safely be given a shared buffer for an input/output pair. However, it's far from that simple! Just consider multichannel plugins. These are often inplace safe within channels, but *not* across channels. This is a result of channels being processed one at a time, rather than all in parallel. There are loads of non obvious issues related to this. The related "output modes" (replacing, adding, possibly others) add another bunch of issues, such as the need for standardized gain controls to make adding mode useful. (VST doesn't have it, and as a result, process() [the adding version] is essentially useless in most situations.) The general impression is that to be truly useful, it gets pretty complicated. A popular opinion is that we should support only one output mode, and just have a plugin global flag to mark plugins as inplace safe. I'm on the fence myself, though I have a feeling that adding/mixing mode could make sense for plugins with low CPU/output ratios... (That is, fast plugins, or plugins with loads of outputs.) [...] > a fixed DC of 1000 means something completely different to a > frequency modulator than silence... > but silence is only dcsilence(0) Sure - but then it's not silence, IMHO. Anyway, buffers with "silent" flags *are* already structured data of sorts, but we have to draw the line somewhere. Or should we express audio as linear ramps, splines, wavelets, or something else...? > > (At least in XAP, we don't use audio inputs for control data. We > > use sample accurate timestamped events with linear ramping.) > > a frequency modulator takes audio input as i see it. Right. > even if linear ramping would be extended to polynoms > and other nonlinear things it would never have the power > of an audio rate control... Of course - but an audio rate control input is an *audio* input. Audio inputs *could* inherit some of the control semantics (specifically "fixed value"), but I think this opens up a big can of worms. I strongly doubt that your average plugin will have much use for DC input optimization, and I don't think your average plugin author would want to be *forced* to deal with it. It can be made optional, and hosts can translate as needed, but if it's going into the API, there has to be a good motivation. [...] > > Yeah, I understand that, but I don't see how plugins that use any > > significant amount of cycles can make use of this. "Register > > instead of stream" kind of optimizations are pretty much > > irrelevant for most plugins, I think, and all the special cases > > it would require (one case for every likely combination of > > active, silent or DC inputs) are just not worth it. > > i guess you are right... but if you think this somewhat further it > is a nice idea... making up a different very complex protocol It's a nice idea in theory, but your own words "very complex protocol" is what turns me away from this approach. Any useful API is going to be quite complex enough anyway. > it should be handled like extended ramping events... If you think about how to actually implement sending and receiving code for that, I doubt you'll ever want to implement plugins that support this... :-) Keep in mind that most plugins will have multiple inputs and outputs per channel, and as a result, you'll be confronted with *mixed* input modes. That is, one inner loop with ramped control and one with audio rate controls (for the extended ramping events) just won't work. You'll have to process each control separately, and at that point, it will probably run slower than hardcoded audio rate controls - even with host side control->audio conversions. I think most people would rather spend their time tuning the DSP code than messing with this. //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://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---
