Re: Mutitimbral - A clarification, sort of
Re: Mutitimbral - A clarification, sort of
- Subject: Re: Mutitimbral - A clarification, sort of
- From: Chris Rogers <email@hidden>
- Date: Wed, 16 Jul 2003 12:38:14 -0700
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
>
Folks,
>
>
here are some bits that hopefully tidy things up.
>
>
>
I think confusion arises from some terms that commonly seem to get
>
mixed up. So here's some explanation (I hope I don't talk rubbish
>
here 8-):
>
>
- AU Music Device offers an API that is "Instrument based".
>
Instruments are not presets. They are entities within that device
>
that are opaque to the host. The host just knows about their
>
existence, but not about any sort of "settings". - In this case,
>
multitimbral means that the device can play several such Instruments
>
at once. DLS Synth is an example, and I think it works out well with
>
existing APIs and conventions. - You can not set a parameter inside
>
a single Instrument...
>
>
- What we are talking about in respect of multitimbral Music
>
Devices, is a completely different approach. - Instead of
>
Instruments, I use the term "part". I could have used any other
>
term, but I just didn't want to confuse it with above "Instruments".
>
A part is different from an Istrument in that it is not opaque to
>
the host. - A part has parameters and presets.
>
>
- The state of an Instrument based multitimbral MD is valid accross
>
all entities of Instruments.
>
>
- The part-based MD has states (settings...) for each part
>
seperately. Better: This should be the case.
>
>
>
>
Problem
>
>
Well. The current API has no concept to properly implement
>
part-based MDs. There is no way to specify a part when loading
>
presets, restoring state, setting parameters etc.
>
>
This is a critical situation, especially if you take into account
>
what hacks / inconsistencies have been used to circumvent this
>
within VST world, where exactly the same problem exists. However,
>
since VST has learned to let the plugin send midi, some use midi CCs
>
with midichannel <-> part mapping instead of parameters to damp the
>
hassle a bit. AUs currently can't send midi as a replacement for
>
parameter changes, an honestly, it's bad style.
>
>
>
>
Proposal
>
>
My suggestion was to merge the AU concept of Elements with the real
>
world concept of parts. This would immediately provide us with a
>
good 50% on the road to a properly working, part-based multitimbral
>
world.
>
>
>
>
Respond
>
>
To respond to the criticism (Frank, we'll carry this out at our next
>
beer night, maybe I simply pay for yours), I'll sum up some basic
>
conditions that I implicitly put in the pot:
>
>
- The property and notification scheme in AU world allows for
>
thorough reconfiguration of what an Audio Unit exposes to the host.
>
Parameters can be added, the parameter list can be altered at
>
"runtime".
>
>
- Parameters are already tied to the Elements scheme. There's about
>
no work to do to enable Element/part-based multitimbrality here. (On
>
the specs side, of course)
>
>
- Presets and state are not tied to Elements, hence not to parts.
>
This would require some modifications in the specs.
>
>
- Extensions to that scheme might be useful, i.e. to deal with
>
overall stuff vs. single part stuff. For example, Element -1 could
>
be used to communicate "He plug! - All parts are meant". Somewhat
>
the like.
>
>
- The modifications of the specs can be done without breaking
>
compatibility to current conventions and existing software. Thus a
>
transition can be seemless. At least I hope so.
>
>
>
Conclusion
>
>
In my opinion, the hassle that people (host developers, hehe) are
>
concerned of, already exists. AUs already offer that complexity,
>
i.e. by the ability to change their properties any time after
>
construction. Proper host design has to take this into account
>
already ( even if it means a delay in AU support 8-).
>
>
It is often said and a valid argument, classical multitimbrality is
>
somewhat obsolete for virtual instruments as we know them.
>
Exceptions may occur, and YMMV
>
>
I see applications beyond classical multitimbrality. - Examples like
>
VBox, FXMachine, or even my superficially described visions, show
>
that plugin space wants its options. So does user scape. I assume.
>
>
In my opinion, minimal effort is required to get rid of the
>
necessity to do "workarounds".
>
>
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.
_______________________________________________
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.