Re: Mutitimbral - A clarification, sort of
Re: Mutitimbral - A clarification, sort of
- Subject: Re: Mutitimbral - A clarification, sort of
- From: Urs Heckmann <email@hidden>
- Date: Thu, 17 Jul 2003 22:05:08 +0200
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()?!?
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)
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.
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)
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.