[linux-audio-dev] PTAF link and comments

[David Olofson]

On Monday 03 February 2003 13.32, Steve Harris wrote:
> Commenting on your comment, I'm about to read the doc.
>
> On Mon, Feb 03, 2003 at 12:18:10 +0100, David Olofson wrote:
> > 	* Assuming that audio and sequencer stuff is in different
> > 	  threads, and even have plugins deal with the sync sounds
> > 	  like a *very* bad idea to me.
>
> Yes, I very much doubt this would work.

Yeah. It forces plugin code to solve the wrong problem.


> > 	* GUI code in the same binaries is not even possible on
> > 	  some platforms. (At least not with standard toolkits.)
>
> Agreed, this is not ideal, ohm force are a host based processing
> shop, so haven't thought about these issues. The TDM people will
> obviously have different ideas.
>
> > 	* I think the VST style dispatcher idea is silly. A table
> > 	  of function pointers, with a bunch of reserved NULLs
> > 	  would be simpler, faster and just as extensible for all
> > 	  practical matters.
>
> Ideally this would be abstracted in the API, ELF sytems wouldn't
> need this anyway, its just because COFF is broken.

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


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


> > 	* Hosts assume all plugins to be in-place broken. Why?
>
> It doesn't really matter what the default is as long as you can
> override it. That way is probably safer.

>From what I read, it's not a default, but rather hardcoded into the 
API. Plugins can't override it, and there are no means for hosts to 
ask.


> > 	* No mix output mode; only replace. More overhead...
>
> But how many hosts use mix?

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.


> As a plugin author, having to implement
> both is a pain. I use code generation to make both functions.

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.


> > 	* Buffers 16 byte aligned. Sufficient?
>
> This should just be a host guideline shouldn't it.

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.


> > 	* Events are used for making connections. (But there's
> > 	  also a function call for it...)
>
> If the events are a signalling and the funciton calls make the
> actual connections then this is convienient.

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


> > 	* Note IDs are just "random" values chosen by the sender,
> > 	  which means synths must hash and/or search...
>
> Yup, this is bad. VVIDs are not an obvious solution though.

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.


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


> > 	* 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?


> > 	* 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?


//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 ---