Re: Mutitimbral - A clarification, sort of
Re: Mutitimbral - A clarification, sort of
- Subject: Re: Mutitimbral - A clarification, sort of
- From: Bill Stewart <email@hidden>
- Date: Thu, 17 Jul 2003 15:08:05 -0700
On Thursday, July 17, 2003, at 01:05 PM, Urs Heckmann wrote:
>
Chris,
>
>
I'm obviously too stupid to get it right 8-)
>
>
Note events is no problem, never was.
>
>
But how should I find out about the group in AUParameterSet() or
>
AUBase:SetParameter()?!?
OK: First:
AUParameterSet( AUParameterListenerRef inSendingListener,
void * inSendingObject,
const AudioUnitParameter * inParameter,
Float32 inValue,
UInt32 inBufferOffsetInFrames);
Where AudioUnitParameter specifies scope, element, paramID - so I don't
see the problem here.
AUBase::SetParameter
ComponentResult AUBase::SetParameter( AudioUnitParameterID inID,
AudioUnitScope inScope,
AudioUnitElement inElement,
Float32 inValue,
UInt32 inBufferOffsetInFrames)
{
AUElement *elem = SafeGetElement(inScope, inElement);
elem->SetParameter(inID, inValue);
return noErr;
}
The Scope and Element are passed in - then the element is retrieved...
SafeGetElement is already set up to deal with 4 possible scopes -
Global/Input/Output/Group
So - I'm confused about what the problem is...
We have *always* associated the concept of "group" with MIDI Channel -
thus the MD has a groupID that can be passed in for StartNote...
Parameters on group scope are already supported by the MusicDevice. So
the following are equivalent:
AudioUnitSetParameter (myMD, 0x7, kAudioUnitScope_Group, myGroupID,
myNewVolume, 0);
Where 0x7 is equivalent to MIDI Controller # 7 (Volume)
MusicDeviceMIDIEvent (myMD, 0xB0 | myGroupID, 0x7, myNewVolume, 0);
Where myGroupID *has* to be 0-15 and myNewVolume has to be 0 < 128...
For PitchBend:
AudioUnitSetParameter (myMD, 0xE0, kAudioUnitScope_Group, myGroupID,
myPitchBend, 0);
where 0xE0 is the "generic" status byte for Pitch Bend in MIDI... (I
presented a way we map these values to "paramID" in a compatibly manner
with MIDI for the DLSSynth's usage)...
Controller IDs (found with the MIDI Controller Status) are presented as
is - range of value is 0-127
After Touch - range of value is 0-127
Pitch Bend - range of value is -8192 - 8191
are presented as if the channel number of the status byte is zero. (ie.
0xE0 for Pitch Bend, 0xD0 for aftertouch) - and if we supported
polyphonic after-touch 0xA0)
For the DLS Synth, this means that these "controller" ID's can be set
either with the MIDIEvent API or with the Parameter API's (and we
should probably publish these as group scoped parameters for the DLS
Synth, but we don't yet)
MusicDeviceMIDIEvent (myMD, 0xE0 | myGroupID, fine_Bits, course_Bits,
0);
I think the compatibility with MIDI is important, as MIDI is still the
primary control/performance protocol (and for that matter sequencer
data format)... The thing I always liked about the scheme we've
employed (based on the SASL parts of Structured Audio in MPEG-4) is
that it retains compatibility without being limited by it in any way...
For all that the extended control semantics give you, MIDI is still the
primary means to do this for most musicians....
The question that we really have to answer is this:
If presets are defined to be settable on GroupScope, then you can't
layer presets so that you get the nice layering/splitting of voices
that you can get on the "performance" modes of hardware synths (as
you'd need to assign more than one preset to a particular group)...
We're still mulling this one over.
>
>
Furtherly, how should I find out to which group I assign a Preset on
>
RestoreState()/NewfactoryPresetSet()? (Here having in mind that the AU
>
is not aware of the AUView, where some - but not all - hosts put their
>
preset mechanisms)
Part of the same problem... we talked about this - the way hardware
typically does this is to introduce the concept of "parts".. So, you
create a performance and you have some number of parts... then you
associate the part with a particular midi channel (or in our parlance
group) - which is then used to address the control events to that
voice... So, this allows you to get mutliple layering/splitting of
voices across some number of MIDI channels... (And being a guitarist,
this is a great boon - there was a day when I played my Guitar through
the TX-81Z, one part per string! - 4 out of 10 notes were correct -
almost went by the name of the "stochastic guitarist" :-)
>
A multitmbral-aware host should offer awareness of groups, hence offer
>
group specific automation & state handling. I do not see how this
>
should be accomplished with current implementations, due to lack of
>
GroupID arguments in critical methods.
I think you are confused.
scope == kAudioUnitScope_Group
element = theGroupID
>
Hmmm. Or do I have to understand it this way that in GroupScope,
>
ElementID == GroupID?!? (Which still doesn't solve the State/Preset
>
question, only the parameter/automation issue)
Ah - exactly!
Bill
>
>
Well. I'm tired today. Will come back to it later.
>
>
;) Urs
>
>
>
Am Donnerstag, 17.07.03, um 21:30 Uhr (Europe/Berlin) schrieb Chris
>
Reed:
>
>
> Chris is basically saying here what I originally said (to Urs, I may
>
> not have mailed it to the list), although my answers were not nearly
>
> so clearly stated, and Chris has some extensions of course... I'm
>
> just going to restate things a little more straightforward:
>
>
>
> Basically, MusicDevices *already* support multi-timbrality! You use
>
> group elements for each part or MIDI channel. To select the patch or
>
> preset for each group, you send bank and patch select events. Then
>
> you can address parameter changes and events to that group alone.
>
>
>
> The MusicDeviceStartNote() function lets you explicitly specifies the
>
> group that the note applies to. This is more or less equivalent to
>
> MIDI channel. And MusicDeviceMIDIEvent() takes a channel parameter
>
> that can simply be mapped to a group. (I'm not sure what you meant,
>
> Urs, about not wanting to map MIDI channels to groups?)
>
>
>
> On the UI side, until hosts support presets for non-global scopes
>
> (which I very much like, btw), you can provide your own preset
>
> save/load mechanism for each patch. (And the plugins you are porting
>
> probably already have that anyway, right?) The actual classinfo would
>
> contain the patches for all groups. And you have to provide an UI for
>
> selecting which patch applies to which group, which, again, you
>
> probably would have anyway.
>
>
>
> Something else which would be nice to some way for the user to build
>
> banks of patches so they could use normal MIDI bank and patch select
>
> events to configure groups.
>
>
>
> So, the only thing I see that would prevent a proper multi-timbral
>
> AudioUnit from working right now is that hosts won't handle
>
> parameters on a group (afaik, they may indeed). So you would have to
>
> figure out some way to map global parameters to a particular
>
> group/part/patch. Not that big of an obstacle, imho.
>
>
>
> And in the future, when hosts provide better support for groups, your
>
> plugin will already support the new features. Such fun things as
>
> mapping groups to their own output busses in the host UI (which I've
>
> always wanted--it make so much more sense than doing it in the plugin
>
> itself). And of course proper sub-global preset support.
>
>
>
> cheers
>
> -chris
>
_______________________________________________
>
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.