• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Parameters - Re: SDK Available
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parameters - Re: SDK Available


  • Subject: Re: Parameters - Re: SDK Available
  • From: Urs Heckmann <email@hidden>
  • Date: Sun, 4 May 2003 10:24:54 +0200

Am Sonntag, 04.05.03, um 01:26 Uhr (Europe/Berlin) schrieb Marc Poirier:


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?

Well, as you know or might guess, I'm now following some sort of generic approach in my modular audio objects engine (or whatever to call it, if not "my plugins wrapper" 8-).

Now, to keep it generic, I need to make some sort of list where for each parameter I need:

a) all the AUParameter fields (that come in very handy)
b) references to objects that listen to each parameter (oh, btw, those are groups!)
c) my personal parameter hints: Smooth user changes or not and how much ...

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,

Opaque data structures are used all over Carbon (Uhm, and my GUI stuff as well). I see them as means for customization.

and perhaps even a way using what we
already have in the AU API...

hehe, I still consider myself AU newbie, so this could be true 8-)

Well, I _could_ roll my own parameter format and derive AUParameters from this. That'd be still dual and wouldn't allow for a handy static array of AUParameters. - Instead, I currently use a static list of AUParameters and have the other stuff hardcoded in a dispatcher. Not quite generic.

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.

oops.

I always thought kAudioUnitParameterUnit_Boolean added some radar love to my plug, but I guess I just had some names confused 8-)

Cheers,

;) Urs
_______________________________________________
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.

  • Follow-Ups:
    • Re: Parameters - Re: SDK Available
      • From: Marc Poirier <email@hidden>
  • Prev by Date: AU host properties
  • Next by Date: Re: CoreFoundation (was DigitalCDSound)
  • Previous by thread: Re: AU host properties
  • Next by thread: Re: Parameters - Re: SDK Available
  • Index(es):
    • Date
    • Thread