3 Feb
2003
3 Feb
'03
12:04 p.m.
On Mon, Feb 03, 2003 at 02:53:45 +0100, David Olofson wrote:
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.
Well, if the API requires C++ then its dubious IMHBO (in my highly biased
opinion).
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...).
MIDI uses 64 as the default... Maybe that's what inspired this,
somehow?
That was my thought. Its still wrong.
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.
This seems like it would subsume plugin based settings saving, 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.
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.
- Steve
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?
* Is using exceptions internally in plugins safe and
portable?
Exceptions are a C++ feature. 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.