[linux-audio-dev] PTAF link and comments

Steve Harris S.W.Harris at ecs.soton.ac.uk
Mon Feb 3 11:05:00 UTC 2003


On Mon, Feb 03, 2003 at 02:53:45 +0100, David Olofson wrote:
> 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.
> 
> 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).

> 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.
> 
> 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...).

> 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.
> 
> MIDI uses 64 as the default... Maybe that's what inspired this, 
> somehow?

That was my thought. Its still 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.
> 
> 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



More information about the Linux-audio-dev mailing list