8 Dec
2002
8 Dec
'02
8:30 p.m.
On Sunday 08 December 2002 22.59, Steve Harris wrote:
That, and/or there should be ramp events. Those can be a bit hairy to
deal with at times, but please, do suggest an alternative if there is
one that is simpler and still sufficient for sample accurate
control... (No, no audio rate "raw" control ports, please!)
Well, I'd prefer plugins being able to say whether their control
ranges are hard, or just recommendations - and when they're hard,
expect out-of-range values to cause the plugin to crash, div-by-zero
or whatever!
Dito, except that I'm in Sweden. :-)
//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 -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
On Sun, Dec 08, 2002 at 12:19:06PM -0800, Tim Hockin
wrote:
Defaults should be part of the control description, just like with
LADSPA ports, IMO. And why is reading controls for saving to a file
different from the usual "remember what you say to the plugin"?
I'll buy that. Once the host reads the
initial values, it should
refrain from bothering the plugin.
I think the host should be able to give the instrument its initial
values, read for deafults, or a settings file etc. Aside: Do we
see a need for plugins to spontaneously change a
control? What of a plugin that has a velocity-capped control
(you turn a knob fast, and it eventually gets there) or something
that crossfades between two values automatically. Do we need to
send CTRL_CHANGE events to the host, or should we do a 'watcher'
callback. Watchers is how AudioUnits works. I don't really like
it.
I'm afraid I'm not familar with the AudioUnits API, but I
dont/think/ this situation requires the instrument to inform the
host, it should just be able to damp (slew rate limit) the control,
shouldn't it? The result from playing back automation data will be
the same, so no harm done.
Yes, that's a good point. You're using the same plugin every time,
right? And the plugin is what defines the exact details of what a
control actually does. (If you want to know what it does internally,
read the code! :-)
Also to think
about - what if the host sends a bad value, and a
control wants to reject it? Ahh, asyncronicity. I guess for
this case the plugin sends back some FAIL event or simpler sends
back a CTRL_CHANGE with the old value (or the min/max if the host
has gone too far).
Bad value? LADSPA has the concept that there are no bad values, the
plugin has to accept anything. It can choose to ignore it, but it
mustn't segfault or whatever. This is not necceserily the right thing, but it does
make some
things simpler. I'm not aware of any situations where this has
required the plugin to tell the user "that was a crap value",
usually the wideband distortion is hint enough ;)
*lol*
Yeah.
In practice most hosts only send values within the
range hints.
IMHO, in the new API, no host should *ever* use an out-of-range value
when dealing with hard ranges. So, ranges *may* be hints, but if
they're *hard*, they're much more than hints.
Just out of
curiosity, where are you located physically, in the
real world? Our timezones are certainly not in sync.
England, UK. GMT+1. I'm not a mornings person though ;)