On Monday 03 February 2003 13.32, Steve Harris wrote: Yeah. It forces plugin code to solve the wrong problem. It doesn't have much to do with object file formats either way, as this all goes through entry points in a struct. It's just a question of whether to have two function pointers to functions with dispatching switch()es, or lots of direct function pointers. Another alternative would be to use arrays of function pointers, but I'm not sure it's much point. Besides, you can have the same "advantage" by allowing the host and plugin structs to grow without breaking binary compatibility. (Means you have to check the size before allocating, and size or version before testing for post 1.0 callbacks. The LADSPA approach makes this slightly easier, but only until you run out of reserved struct space.) Yeah. I was just wondering whether or not you can actually trust C++ exception to stay *entirely* within a plugin as long as you catch all of them, or if using the exception handling of some compilers will screw up the host no matter what, unless it's built with the same compiler and exception handling. API. Plugins can't override it, and there are no means for hosts to ask. At least with VST; very few - but that's because there's no standardized output gain control. Mixing is always 'buf[s] += output', so if you need anything else, the feature is useless. You don't necessarily *have* to implement both. Even the primitive FX plugin API of Audiality have these variants: void (*process)(struct ADY_plugin *p, int *buf, unsigned frames); void (*process_r)(struct ADY_plugin *p, int *in, int *out, unsigned frames); void (*process_m)(struct ADY_plugin *p, int *in, int *out, unsigned frames); ...and you only *have* to provide *one* - any variant will do. If you don't provide all of them, the host "SDK" will emulate the others using the ones that are provided. Yeah, probably. Depends on architecture, really. There are (or were?) CPUs that cannot process large words at non-aligned addresses *at all*, but on those, you generally have to align internally and "fix" starts and ends anyway. Nope, the event replaces the call when the plugin is in the active state; that seems to be the whole point. (You can't pass events in the other states.) No, VVIDs are just a performance hack... I don't think there is an obvious solution that avoids having synths do a lot of look-up work, but there might be something slightly cleaner than VVIDs. And I think the base frequency should be fixed, so plugins can use optimized, hardcoded conversions. No big deal, though; "master tuning" could be a compulsory control in linear pitch, but I don't really see the point. Sequencers will have transpose and other features anyway, so why not just have them output the right pitches directly? (Instead of receiving and applying master tuning in every synth, that is.) MIDI uses 64 as the default... Maybe that's what inspired this, somehow? Right... I'm not even sure what state we're talking about here, but I *assume* it's basically all you need to continue playing from where you saved the state. Freezing reverb tails and stuff? Sounds fun but pretty useless... Might help some very special apps - but then, will it be sufficient? //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 03 February 2003 15.12, Sami P Perttu wrote: It's a primitive performance hack. Once upon a time, these things actually mattered... ;-) Well, that cover's all the cases, and you *can* still optimize with alternative inner loops if you like. Just check for 0.0 gains - but remember that the gain controls will most probably be normal *ramped* controls, so you can't just check the initial value. Looks like a great idea. As to NANs, I think you're pretty screwed if you get them in an audio stream anyway. Plugins that generate NANs are broken, as are hosts that allow plugins to operate on garbage buffers. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 03 February 2003 16.42, Steve Harris wrote: Well, it is for chains of inserts among other things. Yeah, that's what I thought at first. However, if you track the previous_gain and gain controls, you can select between a number of optimized inner loops internally. What you get is basically the same thing as a bunch of different callbacks, except that it's not part of the API, and plugins can handle it any way they like. Oh, you *do* have to check the control events for those two controls, of course. That said, I still think it seems easier to just provide a few different callbacks of which plugin authors can pick one or more. A fully optimized plugin would implement all of them, but you'll get away with just one. It's not as flexible, but all the complexity is in the host SDK; all you have to do in the plugins is copy/paste some code. (Which I don't like of course, but really; if you want to optimize, there's no other way, unless source level macro abuse counts...) //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 03 February 2003 16.56, Steve Harris wrote: No, the VST and PTAF style dispatchers are the only way to get at host and plugin calls. You can't ask for the pointers, but have to go through the switch() functions for every single call. I don't like it and I don't see the point. However, your question gives me an idea: Transform the dispatchers into functions that just return direct function pointers by index. Dead simple, and you can deal with unknown and unimplemented functions in any way you like. You have to ask for all the call you'll need at some point (say, right before activating the plugin, so it has a chance to select specialized versions, if any), but it's cleaner and simpler than dynamic size arrays on both sides, I think. [...] Yeah, two cover most useful cases. IIRC, the reason why I have three is that one of the replacing versions is in-place with a single buffer pointer. Don't ask me why I considered that useful, though... The only important differences are that the single pointer version one is (obviously) *guaranteed* in-place safe, and that the dual pointer version can take NULL input for optimized silence. Nothing you can't handle with only dual pointer calls. Actually, it's an ADD if you do it on the linear pitch side. :-) (And you probably *are* using tables unless you're optimizing only for P-III or better. Not sure, though.) Yeah, but it makes life just slightly easier for hosts at the expense of all plugins. It's another control (or something) that you *must* support if you receive PITCH input. Yep. They're mostly based on variants of feedback delays, so you basically have a bunch of delay buffers, and you need to save the data and position for each one. Actually, I don't think it's related at all. Plugin state is the state of voices, contents of delay buffers and other internal stuff; ie everything that *isn't* available as parameters or controls. I think it's a very bad idea. If you *really* want opaque custom data, just pack it into strings or raw data blocks - whatever the control API supports. It doesn't get any easier than that. No file I/O, no directory scanning or anything like that, and thus, lots of portability issues are eliminated. Well... I can't think of a good example of something that would change with the sample rate or similar right now. Filters will just have to deal with the limitations of the implementation. You can just have a fixed [5, 25000] range or something, and clamp it internally. Thinking about it from the host POV, there isn't really much point in letting the host do the clamping. If you're playing live data, you *have* to do the clamping on the fly, and when you're playing sequenced data, you'd have to modify the data destructively, or cache the clamped values, to avoid clamping in real time. In other words, *someone* will have to check those ranges anyway... To counter the "avoid complexity in plugins" argument; that's exactly what plugin side clamping does! You have to calculate your absolute limits regardless. After that, it's probably easier to just clamp your control input, than to pass the limits to the host. Output controls, or what? And what happens if some of your limits depend on other controls? Then you're screwed as soon as one of those controls change in the middle of a block, since it takes a roundtrip to tell the host/sender about your limits. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 03 February 2003 3:26 pm, ian wrote: Indeed, and using code generation to get both isn't too hard. If you're using C++ you can do it with templates (see the latest version of cmt for some LADSPA plugins I wrote that do this in an admittedly hacky way)

On Mon, Feb 03, 2003 at 03:26:26 +0000, ian wrote: Thay can, but do they. Host authors aren't keen on having multiple code paths either. - Steve

I'm not convinced.. How does this affect in-place vs not in-place? All that means is that the input buffer is the same as the output buffer, no? If the plugin has to buffer, it has to buffer, regardless...I'm not a DSP head, so here is where I may be missing stuff. What does that have to do with mix/no mix? maybe I am missing something, again? Like a piece of hardware, what comes out a port is entirely decided by the plugin. If it mixes in some dry signal, it probably has a wet/dry control. Some may choose not to provide any dry signal at all. What does mix mean for them? Tim

I can deal with it as a boolean - I hated the idea of grades of runtime :) I'll add it to my notes as I spec.

On Tuesday 04 February 2003 00.41, Steve Harris wrote: How would you handle (audio time?) seeking and reverse processing? Well, of course, it's no problem if the plugin is *designed* for it... Actually, plugins do know the *maximum* buffer size they can get. This is a critical API feature for many plugins. Good point. But that also means that plugins with delay *have* to do this properly, or they'll ruin the host's efforts to compensate for FX latency. //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 -' --- http://olofson.net --- http://www.reologica.se ---

On Monday 03 February 2003 23.52, Tim Hockin wrote: Seems like you can start talking to the created plugin, basically. That is, whan you get is something barely alive, that can only handle some basic communication. I guess the idea is that the host can give the plugin some info before asking the plugin for the "meta-data". There is a comment abot keeping the creation and destruction operations low cost, whenever possible, since hosts may have to scan loads of plugins at startup... Compared to XAP, it looks like PTAF has a plugin state where we have the "plugin factury/meta-data level", sort of; ie the next two states corresponds to the two states we've proposed for XAP. The simplest and/or most "straight" mapping you can figure out. Say, map 2 ch stereo to front-left and front-right or best match in whatever surround format you're outputting. Well, you can't know *exactly* what will happen, as there might not be an obvious solution... On the contrary, this is exactly when you need the bypass feature, since the host can't just rip the plugin out temporarily. Well, yeah. It's not a strict definition, but rather "do something that sounds as if the plugin is doing nothing." Yeah, that should work. Just make sure structs *can* grow in the first place, and then it's just a matter of checking versions and pointers. (Which can all be done by the host SDK for lazy/effective host writers, of course.) It doesn't, basically, as what you have physically is just normal 8 bit strings with some extra control codes in them. It matters when something actually tries to render the strings, though, and that's the point. UNICODE without using 16 bit "char", basically. Yes. (See below.) Yes. In PTAF, it seems like the point is just that plugins can assume this alignment, and hosts are supposed to guarantee it. The newer SIMD extensions work with 128 bit words AFAIK, and 128 bit memory busses are getting more and more common... That's where the 16 bytes are coming from, I think. Uhm... Right! :-) It's the same kind of scalability feature I have in Audiality (not that *that* would clear anything up...), where it among other things allows you to use various types of interpolation for the voice resampling. You can't do adaptive cubic/linear-oversampled on an old Pentium, but you can just switch to linear or even nearest to save cycles. PTAF uses float, subdivided in four ranges; [0,.25], [.25,.5], [.5,.75] and [.75,1], where the lower two ranges are for real time use, and the higher two are for off-line use. Yeah... It's guessing and various hacks anyway for many plugins, so you can't require much, and I don't think there's much point in going below block granularity. It gets hairy, and I think few hosts and plugins will make full use of it even when it's theoretically possible. Just too much work, and it actually *costs* cycles when you need them most: when all plugins are running full throttle. This is different from quality. Consider a disk sampler with a butler thread. That just won't run off-line, because the audio part isn't driven by a stable time base, and it won't do the right thing (ie *block*) when the audio part runs too fast. Similar problems with animated GUIs and the like. If plugins just get a hint about what's going on, they can deal with this quite easily, or just avoid doing silly things. Yes, but that's not explicit sending to the host, as in using a special API for only that, as they do in VST, and apparently in PTAF. Plugins just have control ins and outs; that's all. Plugins can't even tell whether these are connected directly to other plugins in the same thread, or to other threads or processes through host managed gateways. I don't see a need for duplicating major parts of the API, and introducing tonnes of special cases in plugins, just for this kind of stuff. Well, it's rather similar to our voice control system. Voices/notes have a bunch of controls (generally continous, just like ours), which have default values that are loaded when you create a voice context. In PTAF, that's done with the same event that starts the note... They have two note-off's though; one for the actual note-off, and one to release the voice context, when there are no more control changes to send. Anyway, the defaults would normally be hardcoded into the synth or something - but as I understand it, PTAF has some kind of "parameter sets" or something that you can throw at voices instead of flooding them with the same control data for every note. That is, if the sender is going to play lots of notes where most voice controls are identical, but not the voice defaults, the sender can build a parameter set and refer to that instead, or something like that... As to XAP, I would prefer a light weight hint based solution for this. Allow plugins to specify a range of Channel controls that map 1:1 to the Voice controls on that Channel. Whenever the synth creates a voice context, it just grabs the defaults from those Channel controls, instead of using some internal constants. You get two things: 1) Senders/hosts can change all the default voice controls as desired, using normal Channel control events. 2) Bonus: The Default Voice Controls automatically get into presets, since they're just normal controls. Yeah, but is it really that useful? Ok, VST seems to survive with the same restriction, but I'm not sure if it actually solves more problems than it creates. Anyway, *if* one is using [0, 1], the conversion calls that ptaf have (but VST lack, AFAIK) are essential, of course. Yeah, but that's a different thing. This is explicitly for stuff that isn't accessible through any other interfaces. For storing presets, I don't see a reason to have anything like full plugin side preset load/save. I moves quite a lot of non-portable code into plugins for no real reason. Just have the host store the control values, and use string or raw data block controls for anything that simply won't fit in standard controls. The host collects the data through the standard control API, does the file I/O and all that. Yeah, that would be reasonable, I think. In the few cases where plugins can't be in-place safe (or the author is too lazy), we even have a nice, cache friendly solution: The audio buffer pool. (A LIFO stack of preallocated buffers. Optimized hosts will probably use one anyway, instead of fixed buffers all over the net.) Yeah. Only the last two are relevant, really, and maybe even two is more than we need... That's a good point. That's why the inplace-with-single-buffer-pointer version is irrelevant to "real" plugin APIs. They don't really have to scale the input... If the idea is to optimize the inplace case in a configuration where you're doing "in bus" wet/dry mixing, you can just scale the buffer before calling the plugin. No extra buffers needed, and that's the big win, I think. It *could* be optional... The host SDK would deal with plugins that don't bother to implement those controls. Anyway, the problem with this is that there doesn't have to be any obvious or known relation between inputs and outputs. You can still do inplace processing on some input/output pairs, but then, what are you actually doing? In-place replace is obvious (reuse the buffers becaues we don't need the audio after the plugin has read it), but in-place add or mix...? Yeah... Well, the problem with that case is that you need an extra buffer to do that mixing. If the plugin has an adding mode with a standardized gain control, you can skip both the intermediate buffer and the extra mixing stage, and then it starts to matter. Why not? They could just be normal ramped controls. out[i] = previous_gain * out[i] + gain * myoutput; previous_gain += dprevious_gain; gain += dgain; That's all there is to it, apart from moving those variables into the array of controls, so they get hooked up with the RAMP events. Yeah. Yeah. run_adding() is indeed nothing but a performance hack. Question is if we really need it these days. I'm not saying that we'll ever have enough cycles to just waste them, but focus is shifting continously. Things are getting higher level. VST is a really rather old API, and that memory bandwidth in new PCs have increased quite a bit even after LADSPA was finalized... Not saying that run_adding() makes no difference to anyone *now*, but in a few years, it'll probably just be a source of annoyance. It doesn't really matter when you pass the buffer pointers. Even if you do it at connection time, you can pass the same buffer to a lot of plugins in a chain, since that's pretty much what a per-plugin dynamic buffer assignment system with a LIFO stack would do anyway. Either way, I can't really think of more than two variants; process() and process_mix(), where the latter would have a standardized gain control, to avoid using both an extra buffer and a mixing loop where chains end and the like. I think that's about it... Right. I don't think it is, really. Just don't fix the size of structs in the API, and you have unlimited expansion possibilites *and* a clean API. Right. And it seems that doing this in plugins bring nothing but trouble and extra work for plugin authors in the APIs that do it that way... Yes... We have strings and raw data block, it seems. Yeah, that's an issue. You could use outputs and "request" events, but then these request events make it all non-standard anyway. OTOH, plugins have to assemble this data somehow, as it's probably rarely raw dumps of internal structs. (That tends to be very flaky and non-portable.) Thus, there's no data you can just read; you have to get some code in the plugin put it together for you. Or do you? Looking at normal controls, you never have to read the inputs, since you can track whan is sent to them when you need to. Why wouldn't that apply to these raw data blocks as well? Remember that the DSP plugin (that receives and uses the data) and the GUI (which generates the data) are separate plugins, using basically the same API. The host would just intercept and store the raw data blocks like any (other) control values, when they come from the GUI. Or, when you load a preset, it would send the blocks to the inputs of both the DSP plugin and the GUI. //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 -' --- http://olofson.net --- http://www.reologica.se ---

Steve Harris wrote: Of course. The ranges given in the PTAF docs were only suggestions of use. That's why the quality setting is dissociated from the "rendering context" information. -- Laurent ==================================+======================== Laurent de Soras | Ohm Force DSP developer & Software designer | Digital Audio Software mailto:laurent@ohmforce.com | http://www.ohmforce.com ==================================+========================

On Tuesday 04 February 2003 08.54, Steve Harris wrote: Yeah. Some plugins might non-deterministic (ie highly input dependent, and/or processing huge internal buffers without scheduling the work evenly over process() calls) if you use the highest quality modes, though - but then they'd just flip the "RT capable" hint, or maybe just set a warning hint. How do you mean? I think 0.0 for "worst" and 1.0 for "best" would do. Is that too specific? ;-) [...] Yeah, I'm not arguing against the feature; just against making it more complex and sophisticated than most plugins and host have any use for. A way of saying whether you generated output (any, or per output buffer) during the process() call might be another. Yeah. It's just a matter of who does the conversions. If we're thinking in modular synth style terms, you'll need some form of gain + offset control, at the very least, to connect ins and outs that aren't really supposed to be connected. I don't think that's an issue. As long as you connect ins and outs of the same type, they'll generally have compatible ranges. If not (say, your filter can't handle more than Nyqvist/4, but the PITCH output that controls it has no absolute limits), you most probably want *clamping* rather than scaling, so just making everything [0, 1] won't be of any help. Well, it *is* an implementation thing... Hosts can just figure it all out beforehand, so all buffers will be in place before the net enters RT context - and then there would be no need for an RT safe audio buffer pool, of course. Seems like a pool of audio buffers would be a nice and simple way to provide RT safe "dynamic" memory allocation to plugins, though, and that's the idea. You could (ab)use events for that, but they're really rather small. :-) (32 bytes, most probably.) Basically the same thing as plugins implementing only one of run() and run_adding() - you *can* emulate one with the other, although it's not free, of course... Ok, how about this: * Hosts must provide basic information such as audio sample rate, maximum buffer size, audio thread characteristics (RT/offline) etc, when asking a plugin lib's "plugin factory" for meta-data. * If this information is changed, all meta-data is invalid. Hosts must ask for new meta-data before trying to instantiate plugins again. *How* expensive? I'm aware of the serious impact when it causes cache misses, but how much does an out[i] += in[i] * gain; stage cost? (I could just benchmark it, but I have only PC133 memory machines here.) Yeah, and this has been going on for a good while... However, DSP code seems to follow the same trend; more cycles/sample, for higher quality and/or cooler effects. That, OTOH, does not apply to inherently simple/fast effects, such as basic state variable filters and gain/pan controls. These will always waste CPU cycles stalling on memory access, and will do more of it as memory bandwidth keeps lagging behind. One could say that as long as we're dealing with a few large heavy effects and polyphonic synths and samplers in a net, this isn't much of an issue. In a virtual mixer with lots of little EQ plugins and whatnot, it might be a real performance issue. Even worse with anything like a modular synth. Ok. //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 -' --- http://olofson.net --- http://www.reologica.se ---

Well, at some point we talked about hardlimited ranges. If we have a control that has hardlimited ranges, and you connect joe random to it, it can go out-of-bounds and blow up. Either all controls check their own bounds, or we have to provide scalar plugins to convert control streams, or we normalize controls. We have a few classes of numerical value controls: unbounded (one or both bounds are infinite) bounded (both bounds are well-defined) enum (a special class of bounded) positive only negative and positive (zero-centered, hopefully) It's hard to normalize for all these. 0-1.0 can make sense for bounded, but is useless for unbounded. hrrmm.. If a plugin can flag itself as in-place-safe, is that good enough? We then push that into the host, which is OK, I guess. Better ideas welcome... We need to change the meta-data as a function of some control. Perhaps wrappers need special attention? Add a flag that says they are a wrapper, and a flag on the control that changes the universe? What if it is multiple controls? So we standardiz: if your plugin provides MIX_WET and MIX_DRY controls, the host can use those and you assume run_adding() behavior. If you do not provide those, you are replacing. If you want to supprt run_adding() behavior, you need to specify those two controls (or is one percentage control enough ?) The host still only calls run(), but if you provide those, it can use you without a send-return loop. Is that good enough? This is what hints are there for, after all. Tim

It's not pretty, but it is useful. LADSPA plugins in a XAP<->LADPSA wrapper. VST plugins in a XAP<->LADSPA wrapper. XAP subnets in a XAP<->XAP wrapper. Yeah. process(replacing) is easy. Nothing extra needed. process(mix) NEEDS a standard WET/DRY gain pair. I mean, I guess it can run without them, but isn't that why people never use it in VST in the first place? If you have a plugin with WET and DRY, but want to use it as replacing, those values still probably have meaning, no? Simpler is better. Can we pass a static wet_gain and dry_gain to run_adding() ? Do we need a gain at all? All these 'flags' may be better off as descriptor->meta_flag(XAP_CAN_INPLACE) style stuff, rather than bitmasks. But simpler is better. Simpler is better. My new mantra Simpler is better

really? I don't know. I still don't even really see where it will be used at all except on returns from sends.

On Tue, Feb 04, 2003 at 05:06:42 -0800, Tim Hockin wrote: Please dont refer to these as wet/dry its not the same thing. - Steve