Re: AU parameter notify vs. writing automation
Re: AU parameter notify vs. writing automation
- Subject: Re: AU parameter notify vs. writing automation
- From: Kurt Bigler <email@hidden>
- Date: Sun, 01 Dec 2002 21:00:54 -0800
I have been watching this thread and the thread about readable/writeable
parameters, and though I know little about these areas, several things have
struck me.
The one thing that gets clearer and clearer is that the potential
variability in how parameter changes might need to be routed is just vast,
and that this discussion can just go on and on.
After this particular message it occurred to me that the whole thing reminds
me of the AUGraph, makes me wonder whether it makes sense to have a kind of
local subgraph for each AU which describes its internal routing of control
info. An AU might provide a default subgraph, but coreaudio might provide a
mechanism for editing or replacing that default subgraph. In the current
context I am thinking of the subgraph as describing the flow of MIDI and
non-MIDI parameter information, however might such a mechanism also allow
clarification of audio routing whenever side-chain kinds of things are going
on?
I wonder whether such a subgraph might also describe parameter display and
editing capabilities in ways that the parameter readable/writeable flags can
not handle. In other words, the "local subgraph" can also describe
connections to the GUI, possibly in ways that allow the base-class
functionality to be more versatile.
I have been hearing people making or implying the following kinds of
distinctions regarding streams of control data, whether the data:
(1) remains internal or is broadcast to listeners
(2) should be recorded for automation
(3) is appropriate for display and/or modification by the GUI
(4) possibly: how to interpret control mods originating from the GUI
(5) whether entire stream of value changes, or only the most recent value is
critical in a given situations, and perhaps attributes describing how a
stream might be either thinned out or smoothed
So it occurred to me that it might be good to make the kinds of needed
distinctions more explicit rather than relying on implicit interpretations
which end up buried inside of code in various AUs.
It appears that compatibility with VST ways is a pretty big issue. And
there needs to be some balance between improved elegance and effective use
of familiar mechamisms which have become part of the culture. Clever
choices in how data structures are interpreted (e.g. parameter
readable/writeable flags) can help ease things a lot for everybody.
However, I hope some people _not_ immersed in the prevalent cultural
metaphors are giving a good look at these decisions, because otherwise the
potential for a clean break which coreaudio represents will be diluted. The
whole discussion of how readable and writeable flags might be interpreted
flagged a kind of "oh-oh" in my mind, though I have to admit my ignorance
here. From my nieve perspective I wondered whether people weren't trying to
overload too much meaning on these flags when in fact additional flags such
as "displayable" might simplify things. I think I recognized a lot of
insider sophistication in that discussion, and wondered whether there might
be any lack of freshness in the thinking, and whether people less immersed
in the VST culture might err on the side of staying quiet because of their
irnogrance, just when they are possibly most needed.
Please consider these as thoughts from an outsider since I have not delved
into this stuff. I hope my outsider perspective might be useful in some way
that compensates for my ignorance enough to make this verbose post worth
reading.
-Kurt Bigler
on 12/1/02 8:11 PM, Marc Poirier <email@hidden> wrote:
>
> What if a user doesn't really care about MIDI CC, and so does not record it,
>
> but wants to record the translated control parameters? I can see a lot of
>
> utility to using MIDI CC as a way to create automation data, but once created
>
> and translated, there may no longer be any reason to preserve the original
>
> MIDI
>
> CC data. Applications like Logic allow you to edit automated control
>
> parameter data as easily as MIDI data, so there is no reason that every
>
> playback should be using CPU power to translate from MIDI CC to control
>
> parameters if you can just record the translated data in the first place.
>
>
>
> It does seem like there might be examples of parameters which should not be
>
> automated. I'm not disagreeing with your idea, I merely wanted to point out
>
> that you shouldn't assume that translated control parameters should never be
>
> recorded for automation - or that you would want to force users to record the
>
> MIDI CC data when they might want the option of recording the translated
>
> data.
>
>
Yeah, good point, I hadn't thought of that. For me, I definitely want
>
MIDI recorded because I use a MIDI fader box which has a MIDI-in and all
>
of the faders respond to incoming messages to calibrate themselves (i.e.
>
the fader positions/values are relative, not absolute), so without the
>
MIDI feeding back in, the fader values will be all out of wack whenever I
>
go back into the song. Also, I would add that translating CCs to
>
parameter values uses a totally trivial amount of CPU. But anyway, it
>
sounds like having a switchable preference here makes sense...
>
>
But the original issue remains: Can an AU change a parameter and notify
>
listeners without causing the host to record automation data?
>
>
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.
_______________________________________________
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.