Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Wed Feb 05 2003 - 05:12:13 EET
On Wednesday 05 February 2003 01.58, Tim Hockin wrote:
> > What I'm saying is basically that it's not a goal in itself to
> > create our own "standard" here. If we can get along with the GMPI
> > group and something useful gets out of it, things will be better
> > for everyone. What this would mean to XAP as such is uncertain,
> > of course - but I think we will have *very* little influence on
> > what will become The Audio Plugin API, unless we participate in
> > the GMPI effort.
>
> True enough, though if we finish first, we have a grounds to push
> XAP as a good starting point :)
Yes, that's my idea, basically. Working implementation with nice SDK
sure beats messy design documents! :-)
[...]
> > > 3) graphics+layout - plugin provides XML or something as well
> > > as graphics - host is responsible for animating according to
> > > plugin spec
> >
> > Well, unless we can just whip something almost that good up in no
> > time, from existing, highly portable and suitably licensed stuff.
> > Maybe if libvstgui is released under the LGPL, and we hack a
> > binding for some nice and easy to learn language...?
>
> That's more or less what I was thinking - not too fancy, just
> something to blit simple bitmaps - a background + a 16-state knob
> overlay.
Actually, I'd like to support alpha blending and that sort of stuff as
well - maybe even basic transformations. Basically stuff you could
hack on top of SDL or some canvas widget in a few days, although
getting it seriously fast will take either accelerated OpenGL or more
work. (Or both, if you want *insane* speed... ;-)
Any suggestions for scripting language? Python, Lua, Java...? (Though
Java comes with a *tonne* of "crap" that when used, makes it so slow
you basically can't do anything with it on sane hardware. Most VMs
seem pretty darn fast, though. Fast enough for serious real time 3D
graphics, at least - and we're not talking about OpenGL bindings.)
> > > 4) total - plugin provides binary UI code (possibly bytecode
> > > or lib calls)
> >
> > Byte code? Pretty close to what I suggested for 3. And the same
> > issues, of course. The native code version is probably simpler,
> > but obviously, not nearly as flexible.
>
> libVSTGui was what I was trying to say without saying it :)
Well, it's still native code, but if the code becomes portable, it's
no *major* issue. However, it would be pretty cool if you could mix
operating systems without having to worry about which machines can
host which GUIs. Just run the DSP part where you can, and put the GUI
anywhere you want it.
And of course, not having to compile the GUI for multiple platforms
might make life slightly easier for some developers. Less linker
switches and stuff to worry about, if all you have to do is compile
some DSP C code with essentially no dependencies into some shared
libs for different platforms.
Perfect job for someone who likes compiling compilers, BTW: Build
cross compilers for the major platforms, so you can just type 'make'
and get a plugin bundle that runs just about anywhere. :-)
[...]
> > That is, if anyone's in doubt, I'm back at my old position; we
> > should at least have an adding version.
>
> I'm there, too
I just realized something that might make things look better.
Q: Where do multiple versions of process() make sense?
A: In small plugins that are likely to be used in many instances.
Q: When do you desperatly want to avoid any added complexity?
A: When implementing large "monolith" type plugins, that generally
lots of CPU and/or very rarely will be used in more than one
instance.
There might be one problem though: Monoliths may have lots of audio
ins and outs, which again means per-buffer overhead might start to
matter... Not sure if your average user would use enough audio ports
that this really matters, though. (Audiality certainly won't need
many external ports if you're using the internal mixer for FX, but I
would think that most synths with less strange backgrounds and
motives don't even have internal FX.)
Real world examples?
[...]
> yes - in-place-safe is a hint. Assume broken by default.
Works for me.
[...]
> > > I rather like normalized values. I've been contemplating this
> > > problem, myself. I don't like having to call normalize
> > > functions for every translation, though. Can the translation
> > > overhead be minimized?
> >
> > Consider this:
> >
> > * Controls that are meant to be connected generally
> > have the same units and the same ranges.
>
> What about generic controller plugins? A generic envelope
> controller or LFO. Normalized values just work (assuming we can
> define normalized - it's not easy :)
Well, sort of. I'm foresee trouble with controls that use the same
units but different ranges. PITCH, for example; if you "stretch" it,
it's no longer 1.0/octave - and then, is it really PITCH?
I've mentioned that filter with max cut-off at fs/4 (not Nyqvist/4, as
I said, though it doesn't matter much), and something that generates
PITCH way beyond that.
Now, first of all, I don't like to think of PITCH as a control with
absolute bounds. Where to draw the line...?
Second, unless the filter clamps it's PITCH input itself, the sender
or the host will have to deal with it. How? Well...
1) Do nothing. This means that the full range of the
output is mapped to the full range of the input.
This most certainly means PITCH is no longer
1.0/octave - and that seems evil to me, when it
"just happens" like that.
2) Consider the natural ranges and adjust values
accordingly, so that a PITCH corresponding to say,
8000 Hz still tells the filter to set it's cut-off
at 8000 Hz. This means someone will have to do
clamping as well, since we can't force the output
not to use the full range it explicitly says it's
using.
In short, normalized controls don't solve this. IMHO, they even make
things messier and less obvious in this kind of situations.
> Or we can just say that
> things like that output normalized data, and have to be passed
> through some sort of scalar.
That makes a great deal of sense.
> > > I actually have this in my own notes for XAP - an optional way
> > > for the plugin to save 'extra stuff' with a preset or document.
> >
> > How about combining a few "old" features here:
> >
> > * An output must initialize the connected input
> > as soon as audio processing continues.
> >
> > Now, give one or more row data control outputs a suitable type
> > hint, such as "INSTANCE_STATE", so hosts can just connect them,
> > call process() for 0 frames and store the data somewhere. No
> > extra calls
>
> hmm, so to save a preset you'd have to connect the INTERNAL_CRAP
> control to something and process(0)? I don't know. Just saying
> plug->save_extra_state(raw_data *r); seems cleaner, to me.
Yes, but that requires special case handling on both sides. "Polling"
and/or analyzing comunication between plugins is something you'll
have to do in hosts anyway, unless this save_extra_state() becomes
non-optional and renamed save_state().
That is, if we already have a standard way of keeping track of plugin
states, why use a different API for the non-standard data, rather
than just relying on what has to be there anyway?
> I am
> also contemplating saying that controls need to be readable, just
> because it irks me that they're not.
It's not perfect, but I don't see how we can safely avoid having some
form of "raw data" interfaces. "Private" stuff going on between GUIs
and their DSP plugins is one area where it's rather handy. In fact,
that's the main excuse to have them at all, I think, as this is the
only way you can do anything more useful than just saving and
retrieving the raw data to/from presets.
Considering only the DSP side of things, I still think raw data blocks
are useful. The alternative is using strings containing paths to data
files, and considering what this means when you want to save a full
project, I'm not sure it's all that great. You still have to do it
for large files (audio files and stuff), but I'm not sure I'm willing
to accept that as an excuse to use external files for *all*
non-standard data. Maybe...
//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 ---
This archive was generated by hypermail 2b28 : Wed Feb 05 2003 - 05:12:11 EET