3 Feb
2003
3 Feb
'03
1:39 p.m.
On Monday 03 February 2003 16.56, Steve Harris wrote:
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.
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.
base freq can be set easily enough, its just one MUL and you cant
really get away without it anyway (unless you use tables or
something...).
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.
MIDI uses 64 as the default... Maybe that's what inspired this,
somehow?
That was my thought. Its still wrong.
Yep.
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?
Well you can use it in a sufficient way, assuming you can just
write arbitrary binary data to a FD or whatever. I dont know enough
about reverbs to know if it would be useful there, but I can see it
being useful in loops and feedback delays.
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.
On Mon, Feb 03, 2003 at 02:53:45 +0100, David Olofson
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.
[...]
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.
Ahh, I see. As this is only does a load time it seems like
something along the lines of OpenGL's extension API would work, or
is that what you mean by a dispatcher? You don't
necessarily *have* to implement both. Even the
primitive FX plugin API of Audiality have these variants:
3 sounds like too many. * Hz is not a
good unit for pitch...
* Why both pitch and transpose?
Presumably because they dont understand how to represent pitch.
Base frequnecy + octave cleans this up. 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.)
Its pretty convienint to have a way of retuning every oscilator in
the system, without affecting the pitch values. Different hosts may
want differnt values for pitch=0.0 * Why [0, 2]
ranges for Velocity and Pressure?
1.0 for default/middle kinda makes sense, but I agree its
wrong. * The
"save state chunk" call seems cool, but what's
the point, really?
This could be useful for state storing in hosts, but how many
would use it? I'd certainly be reluctant to implemnt it. This seems like it would subsume plugin based settings
saving,
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.
but
maybe they didn't consider host based saving. Plugin based saving
does sidestep the issue of a standard settings format, but I dont
think thats a good thing.
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.
PS Your point about static metadata is well made, but
some items
that could be considered as metadata (eg. port ranges) may depend
on system varaibles (sample rate etc.), though that should probably
be discouraged.
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 ---