Re: Parameters - Re: SDK Available
Re: Parameters - Re: SDK Available
- Subject: Re: Parameters - Re: SDK Available
- From: Marc Poirier <email@hidden>
- Date: Sun, 4 May 2003 01:26:46 +0200 (CEST)
>
One old thing I'd like to bring up again is metadata for parameters.
>
>
Something that could enhance user experience would the ability to build
>
groups of parameters. - In an automation driven environment, these
>
groups could be the organizing structure for hierarchical menues when
>
selecting automation tracks. Furtherly, the generic view could adopt
>
some strategies to seperate groups visualy. Obviously, this is
>
important for plugins with many parameters.
>
>
Well, "groups" could have their own presets or at least settings could
>
be loaded seperately from preset xy into current user preset (One could
>
think of additionaly data keys in the settings for this). - Of course,
>
one could do this anyway now, but a general way might be more
>
consistent than isolated solutions. Some sort of discussion might be
>
necessary. Example: The good old Ensoniq synths/samplers have presets
>
for envelopes etc. Very useful.
Hmmm, I like those ideas, sound like very good ideas to me... :)
>
Another suggestion: What about a void* usedata field in AUParameters
>
that could be individually set and would be passed to SetParameter() ?
>
- That way one could get rid of dual representation of parameters for
>
formal AU support and internal dsp. Well, it would also enhance gui-dsp
>
interaction possiblilities (while probably screwing up Marc's remote
>
control idea).
If I understand what you're referring to as "Marc's remote control idea"
(being able to load audio and GUI components in separate address spaces?),
heh heh, I wouldn't call that *my* idea... ;) But anyway, the right way
to do what you're suggesting would be to copy the buffer rather than the
reference. In other words, you would include two values for that bit of
metadata: the pointer to the data and a value specifying the number of
bytes of data. That way the Component Manager can handle the copying of
the actual data between different address spaces rather than simply
copying the reference to the data and then crossing your fingers.
But actually my primary reaction to this suggestion of yours is: how
specifically are you having problems with the current parameter data that
require you to use dual representations of parameters? Adding opaque data
chunks to parameter metadata could be considered sort of a hack, and at
least a last resort, so I think that talking about adding such a feature
is really jumping past the real issue that needs to be discussed which is:
why are you finding yourself using dual representations of parameter
values? There might be a much better way to solve your problems than with
opaque data blocks for parameters, and perhaps even a way using what we
already have in the AU API...
>
One buggy thing I came across that's somehow related (Generic View):
>
>
My current work has no custom gui yet, so the generic view jumps in.
>
Half of the parameters disappear in nirvana below my monitor 8-)). The
>
generic view should become a little smarter and waste less screen
>
estate...
Yeah definitely, and it could check the screen size and use more than one
column of controls if need be.
>
While we're at that, I'd appreciate to find a trigger type of
>
parameter, one that could be represented as a push button and/or a
>
on/off button. That'd be much better than a pulldown menue for indexed
>
parameters with range 0-1.
A pull-down menu with 0 and 1? On/off parameters should be specified with
kAudioUnitParameterUnit_Boolean. You won't get a momentary push button,
but at least you'll get a check box in the Generic View.
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.