• 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: Mutitimbral - A clarification, sort of
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mutitimbral - A clarification, sort of


  • Subject: Re: Mutitimbral - A clarification, sort of
  • From: Chris Reed <email@hidden>
  • Date: Thu, 17 Jul 2003 14:30:09 -0500

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

On Wednesday, Jul 16, 2003, at 14:38 US/Central, Chris Rogers wrote:

Urs,

We've been discussing your idea about your "part-based" presets and
think we can make this work according to how you'll want it.
First of all, there's no need to be scared of the MusicDeviceInstrumentID
idea with multi-timbral MusicDevices such as the DLS synth.
The concept is completely compatible with your idea. The
MusicDeviceInstrumentID
simply encodes a MIDI patch and bank number, so reporting a certain number
of instruments, simply reports the possible instruments which can be
selected on a particular MIDI channel with patch and bank select messages.
We strongly encourage multi-timbral softsynth developers to support
the notion of patch, bank, so people can change sounds
in real-time from a controller keyboard (or from a MIDI file with
patch change).

We've also defined this idea of "groups" (with MusicDeviceGroupID
and kAudioUnitScope_Group). We've had these in MusicDevice.h for a
long long time.
If you're just dealing with MIDI, then the MIDI
channel can be considered as the group, but in general the group may
represent many more values than just sixteen. Although it's probably
far from clear, we've always intended there to be real-time parameters
addressable on the "group" scope. So, we've been thinking
about allowing presets to be saved and loaded on the group level.
Doug Wyatt suggests that this is equivalent in the hardware synth
world to simply sending a SYSEX message to assign a particular preset
to the "edit buffer" (which may exist separately for each MIDI channel
in some synths). Then in a hardware synth, whatever is stored in the
"edit buffer" can then be saved off into a particular patch/bank.
The same can be true for groups. Whatever preset is currently assigned
to a group may be saved into a particular patch/bank location.
The global preset for the MusicDevice would save/load the state of all
patches/banks. Doug may have some more clarifications about this.

Urs, how does this sound??

Chris Rogers
Core Audio
Apple Computer
_______________________________________________
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: Mutitimbral - A clarification, sort of
      • From: Urs Heckmann <email@hidden>
  • Prev by Date: Re: Mutitimbral - A clarification, sort of
  • Next by Date: Re: [OT] Mutitimbral - philosophy
  • Previous by thread: Re: Mutitimbral - A clarification, sort of
  • Next by thread: Re: Mutitimbral - A clarification, sort of
  • Index(es):
    • Date
    • Thread