[gmpi] Re: Reqs 3.8 Events - ramped events
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 13 Jan 2004 15:59:38 +0100
On Tuesday 13 January 2004 13.49, Steve Harris wrote:
[...]
> I dont like things like "oh, you cant connect that input to an LFO,
> because the plugin author didnt want you to do that". OK, so if you
> do connect an LFO to a "slow" control, the control sample rate will
> be low, but it may do something that the user really wanted.
Exactly. No reason to prevent something, unless it would cause really
bad things to happen.
[...]
> The delay example is a bit of an extreme one, because the total
> delay length includes a reallocation (in that implementation - my
> delay lines dont do that) and so is blantantly not a RT control -
> it possibly shouldn't even be changeable while the plugin is
> running.
Reallocation is only non-RT because of limitations in your average
workstation OS. Hosts could get around it, if plugins normally
allocate memory through the host.
> We did discuss non-RT controls IIRC, but I cant remember what we
> decided. Was it just that they would be hinted to produce non-RT
> friendly behaviour when changed?
"Req 44: Parameters must be able to indicate whether they
are safe for realtime usage or not."
I don't quite like it, though, as it's very hard for a host to do
anything at all about it. Meanwhile, it's pretty easy for plugins to
at least avoid stalling the audio thread, and quite doable to just
keep processing while waiting for the results of the control change.
Two examples of how to do it for a delay plugin:
1) When you need to reallocate the buffer, detach it
and start a worker callback to reallocate it. Run
in bypass mode until the buffer comes back.
2) When you need to reallocate the buffer, start a
worker callback that allocates new buffer. Keep
working as usual. When the new buffer arrives,
grab it and dispose of the old one.
(Freeing memory should be done by a worker callback/thread as well,
unless we require that the host->free() call is always RT safe in RT
hosts. That's not too hard to implement...)
Given how simple the minimum implementation is, the chance of greatly
reducing the risk of random system wide glitches while tweaking
parameters, and the fact that most plugins won't have to worry about
it at all, I think it would make sense to require that RT plugins
have only RT safe controls.
As to the "non-RT" hint, that's still useful, though it's meaning
would change to "this control has a random unbounded response time,
and may cause the plugin to temporarilly enter bypass mode, or
otherwise behave differently."
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
