Re: Private Parameters
Re: Private Parameters
- Subject: Re: Private Parameters
- From: Bill Stewart <email@hidden>
- Date: Tue, 15 Jul 2003 16:46:17 -0700
Glenn,
Its not just your synth actually - a few AU's have not published their
parameter info correctly, in part because of this confusion... so,
please don't feel that you are being singled out here.
On Tuesday, July 15, 2003, at 04:05 PM, Glenn Olander wrote:
James Coker wrote:
On Tuesday, July 15, 2003, at 03:34 PM, Glenn Olander wrote:
I can live with that, but it seems like a narrow definition
of parameter, especially since only #3 will apply to the
majority of plugins. (can anyone seriously see a generic UI
for any major plugins which have been released in the past
year?)
In FinalCut you can. I think some other hosts (LIVE) allow
plugins (VST in that case) to be used w/ a generic UI.
:-). Trust me, a generic GUI has never and will never be used
for plugins like all the recent releases (Absynth, OhmBoyz,
Crystal, Zoyd, Mach 5, Kontakt, etc.)
Well, all of the host apps provide some kind of slider view, so the
paramter information that is published directly affects what
information that the host presents to the user in these views.
Alternatively, we could add a flag to
parameter info that says whether a parameter is automatable
or not. That would seem like a useful thing to have in the
long run.
I assume that if the parameter is readable and writeable,
I can (and will) send it automation data. I also use those
flags to determine which parameters to listen to for changes
so that I can capture 'scene' data separate from the normal
AU preset mechanism.
That's my point, we currently have to assume. But, if everyone
is happy with the narrow definition of parameter, then that
assumption is a safe one.
I don't agree with you that this is a "narrow definition".
We have flags (expert and meta) that can be used to tag a parameter
that should not be seen in normal consumption, but maybe interesting
for some users.... The Generic view that we ship doesn't display
parameters that are tagged in this way - and we'd considered adding a
tab for "expert" mode views...
But the intention of the "published" parameters can still be boiled
down to three uses:
(1) Determine an appropriate generic UI (BTW - I *much* prefer custom
UIs, but for some AU's the custom UI's aren't necessary)
(2) determine which Params a host should listen to changes
(3) determine which parms can be automated/have their value changed
(including ramping)
We talked yesterday about the mapping of external control sources to
parameters... This ties in with (3) of course and a good host should
probably present a mechanism to associate MIDI (or other) sources of
control data to be directed to particular parameter ID's...
If the AU doesn't publish a list of parameters, then the host can't
record parameter gestures and can't map external control sources...
Maybe your UI can take care of the mapping of controls (but then every
UI would have to do this), but you still can't solve (2), unless the
host is aware of the parameters to listen too, which then affects
whether it can change those values...
So, I think the last two (even disregarding the "generic UI") are in
themselves sufficient reason to publish a well described and
appropriate list of parameters for the hosts to care about. Generally,
I also think this is sufficient.
Bill
- Glenn
_______________________________________________
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.