4 Feb
2003
4 Feb
'03
11:19 p.m.
On Wednesday 05 February 2003 01.58, Tim Hockin wrote:
Yes, that's my idea, basically. Working implementation with nice SDK
sure beats messy design documents! :-)
[...]
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.)
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. :-)
[...]
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?
[...]
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.
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?
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 :) 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...? 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. 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 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. 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 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 ---