Re: Calling TellListener & AUParameterSet in audio thread
Re: Calling TellListener & AUParameterSet in audio thread
- Subject: Re: Calling TellListener & AUParameterSet in audio thread
- From: Marc Poirier <email@hidden>
- Date: Fri, 21 Mar 2003 17:48:21 +0100 (CET)
>
> 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?
It could be generating them for whatever reason by whatever means. I
guess that basically what I'm saying is that I think that the concept
"gestures" should be treated in a more general way. The practical matter
is that we want automation recording to happen properly. If a GUI and
mouse events are required to make that happen, then that's an unnecessary
limitation. Parameter changes, including extended ramps and curves, are
not strictly the domain of GUI mouse interaction, so why impose this
limitation and define the start/end automation events exclusively in the
GUI / mouse-event domain?
>
> 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.
Okay... as long as perhaps this is set a bit more in stone and the
expected behavior more clearly specified. Currently in Logic, parameter
change events generated in this way are not recorded as automation.
Perhaps Logic is doing things incorrectly? Either way, it would be nice
if this was clearly specified. I posted about this a few months ago
(subject "AU parameter notify vs. writing automation" posted December 1st
2002), asking if there was a way to post parameter change notification in
a way that indicates whether or not you want automation data recorded, but
this was never clarified.
>
> 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)
No, of course, that's what I meant too, but since it can be useful to
provide this semantic, it certainly would be nice if it wasn't completely
ruled out as it is now in AU (given that this stuff can only be done from
a GUI). This is one area where AU is unfortunately not as good as the
other existing plugin APIs.
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.