Re: Calling TellListener & AUParameterSet in audio thread
Re: Calling TellListener & AUParameterSet in audio thread
- Subject: Re: Calling TellListener & AUParameterSet in audio thread
- From: Bill Stewart <email@hidden>
- Date: Thu, 20 Mar 2003 21:22:31 -0800
On Thursday, March 20, 2003, at 08:53 PM, Marc Poirier wrote:
Let's step back a moment ... the purpose of TellListener is to inform
the host of a UI gesture in a plug-in's view. Currently the only
gestures that are defined are mouse-down and mouse-up.
The purpose of this functionality is for recording automation
gestures;
looking at the pro consoles with flying faders, and software that uses
the same paradigm, a mouse-down (touching a fader) does not
necessarily
change its value right away (not until the fader is moved), and yet
the
time at which the fader was touched may have a lot of significance,
i.e. stop playing back the existing automation for the relevant
parameter, and prepare to replace it with new automation if the fader
*is* moved.
This is a kind of mixed up mish-mash of GUI and DSP things here. I
believe that that's where Raphael's concerns are coming from. I fully
understand that the purpose of recording a "gesture" is to allow for
proper "touch"-style automation (and any automation that requires the
concept of a gesture), and that's exactly why it doesn't make sense to
split that capability off exclusively into the GUI domain. It should
be
possible for a plugin to begin and end automation gestures for any
reason,
at any time, with or without any GUI interaction.
Why - what does the plugin know about the beginning or end or an
automation gesture?
In addition, it should be possible for a plugin to produce a single
value
change that can be recorded as automation, not necessarily a gesture.
That is what AUParameterSet (notification and listener services for
parameters) are for.
MIDI doesn't really have this concept, at least not with single
controls. You don't know that a MIDI controller was touched until you
get a new value from it.
Now, theoretically we could have high-class MIDI controllers (or do
some already exist ... ?) that send two different control-change
messages, one on/off to indicate when the user touches/releases the
fader, and another continuous value to reflect when the control is
actually moved. In this case the view could indeed be receiving MIDI
messages it wanted to forward to the host for "control-touched" and
"control-released" (the more properly general way to describe
"control-mouse-down" and "control-mouse-up"). And then we would indeed
want to pay attention to the thread context of these messages.
MIDI does not have this concept built into its protocol, but it's not
unusual for MIDI applications to use a time-out method of recognizing
gestures. In other words, if consecutive MIDI events occur within a
certain duration, then they will be considered to be part of a single
gesture. Once the time-out duration elapses after some event (without
any
new events occuring), then the gesture ends.
Yes, but to be clear, this is a semantic that is imposed upon the
stream and has no support in the transport protocol of MIDI (this is
what Doug is describing above).. because of that a plugin that
interprets a MIDI stream cannot make any assumptions about this
begin/end semantic (unless you arrange a specific message to be sent to
you by a host, or impose that semantic yourself)
Bill
Marc
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.