Re: AU parameter names and units
Re: AU parameter names and units
- Subject: Re: AU parameter names and units
- From: Frank Schoep <email@hidden>
- Date: Tue, 20 Feb 2007 11:27:43 +0100
On Feb 16, 2007, at 8:59 PM, William Stewart wrote:
We should look into this. Are you running this in the "Generic
View" as seen in AU Lab? This is where I'd expect to see the extra
resolution show up.
I think so, yes. I don't actually see any view drop-down list in AU
Lab, so I think it should be the generic view. The Audio Unit was
created using the "Audio Unit" template in Xcode so it doesn't
provide any custom Cocoa or Carbon view itself, only the parameters.
The pitch parameters themselves range from minus 1200 to plus 1200
cents and I've tried both the semi-tones and cents units. Using semi-
tones you get two decimal digits (from -12.00 to 12.00, high
resolution doesn't add one), but that's still only a precision of one
cent. Using cents there are no decimal digits at all.
You might wonder why such precision is necessary, it's mainly
intended for microtuning where you want to cram (part of) an ET-19
scale into 12 "regular" notes. 1200 divided by 19 is 63.15789…, so
being able to have at least one decimal digit would make the end
result come closer to a perfect ET-19 scale.
This sounds pretty much what I want to do, except I'm changing
parameter *names* instead of values. But I'm probably overlooking
something as my AU never receives a call to GetProperty{Info,}
with AudioUnitPropertyID == AUDependentParameters (== 45?).
That's fine - you are changing the string that you will translate a
parameter's value to.
I'm not sure if that is what I want to do. Let me try to explain this
a bit more carefully.
As I wrote earlier, the AU is a diatonic pitch shifter so it does a
pitch detection on the input signal, decides which note is being
played and then shifts the signal anywhere from -1200 to +1200 cents
based on the note that was played. Using this effect you can create
harmonies or play different (micro)tunings.
The first version of the AU offered twelve "note" pitch parameters
ranging from the C via C# to B. Suppose you were playing in a scale
of C major, you could shift the C +400 cents on a separate bus to
have a simple major interval.
That approach works fine when you always play in C major, but
oftentimes you find yourself playing in different scales and even
tunings. When you wanted to take the C-major preset and apply it to a
D-major scale, you needed to change every single parameter to
accommodate for the new scale (D becomes C and so on).
With the new version I'm creating now things work differently: no
longer do you specify the pitch shift per *absolute* note but you
select a root note and then set the pitch shift per *relative* note
(e.g. unison, fourth, fifth). This offers much greater freedom as you
can now instantly re-use any preset in twelve scales.
In practice, this means that the parameter interface changes from this:
C: -1200 … +1200
C#: -1200 … +1200
…
B: -1200 … +1200
To the new version:
Scale root note: (drop-down) [ C ] or [ C# ] or [ D ] … [ B ]
Unison: -1200 … +1200
Minor second: -1200 … +1200
…
Major seventh: -1200 … +1200
With this out of the way I can begin to rephrase my initial question.
Parameter names like "minor second" do make clear which relative note
they resemble, but for a lot of musicians it's not directly clear
which *absolute* note would be the (for example) minor second of a F#
chromatic scale.
What I want to do is change the parameter *name* of the "unison",
"minor second" … "major seventh" parameters to include the *absolute*
note. So, if you had the following (reduced) preset:
Scale root note: [ C ]
Unison: +400
It should become this:
Scale root note: [ C ]
Unison, C: +400
And if you change the root note to D, it would become this (note that
only the absolute note changes, not the relative name or the pitch
shift amount):
Scale root note: [ D ]
Unison, D: +400
I hope this all makes sense, I could try to elaborate more, but it's
already become quite a story.
You also have to check the elementID - this is the parameter ID
that is your meta parameter ID (and you are describing the
dependent parameters for that meta parameter. That way you are able
to describe different dependencies for different meta parameters.
...
It should be getting called when you open a view in AULab (as well
as other places)
This part puzzles me. I didn't add a check for elementID yet because
the GetPropertyInfo method never gets called with "inID ==
kAudioUnitProperty_DependentParameters".
I'm sure I've set the IsGlobalMeta *and* IsElementMeta flags for the
scale root note parameter, but there is never a call to
GetPropertyInfo with the desired inID.
Searching for "kAudioUnitProperty_DependentParameters" in Spotlight,
Google or the mailing list archive doesn't really turn up much
information. It seems I don't even have a header file defining its
value although when I fprintf it to a log-file, it turns out to be 45.
...
I don't think so - all you have to do here is mark the parameter
with the meta tag. There's no change for the params that are
dependent on that though.
I see. Given my new and more detailed description above, is the meta
and dependent parameter setup still the way to go given I'm not going
to change values but parameter names?
Thanks a lot for the help, I hope we can figure it out.
With kind regards,
Frank Schoep
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden