Re: [linux-audio-dev] PTAF link and comments

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Mon Feb 03 2003 - 19:32:27 EET


On Monday 03 February 2003 16.56, Steve Harris wrote:
> 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?

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.

[...]
> > You don't necessarily *have* to implement both. Even the
> > primitive FX plugin API of Audiality have these variants:
>
> 3 sounds like too many.

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.

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

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

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

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.

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

Yep.

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

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.

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 19:46:26 EET