Re: Parts, Groups and Multi-timbrality
Re: Parts, Groups and Multi-timbrality
- Subject: Re: Parts, Groups and Multi-timbrality
- From: Bill Stewart <email@hidden>
- Date: Fri, 25 Jul 2003 16:52:48 -0700
On Friday, July 25, 2003, at 01:22 PM, X. J. Scott wrote:
on 7/23/03 9:42 PM, Bill Stewart wrote:
"control group" - MIDI Channel
...
ParameterID: 224 (0xE0)
This is the pitch bend control. IDs 0xE1-EF are redundant
The value range is -8192-8191, where zero means no pitch bend.
If I understand this correctly, this 'channels ignored' scheme could
preempt
the ability to provide support for guitar controllers and microtonal
processors, both of which require the ability to send channelized pitch
bends to a monotimbral multi-voice patch, spanning many (specified)
channels, on a given midi port.
No... A parameter value is set as follows:
AudioUnitSetParameter (myAU, kPitchBendID, kAudioUnitScope_Group,
myMIDIChannel, myNewPitchBend)
As you can see the channel information is not lost, it is just not
encoded in the Paramter ID (whereas MIDI encodes command and channel in
its status byte) - in the AU case the channel is specified as the
elementID argument to the Get/Set parameter calls.
The guitarist market segment is quite vast, so, even if one chooses
not to
support the market for ethnic scales (arabic musicians, indian
musicians,
african musicians, indonesian musicians.), this could unnecessarily
limit
the market potential of plugins to keyboardists only and not
guitarists.
Ummm... we haven't commented at all about "ethnic scales" so I don't
understand your point. The MusicDeviceStartNote can take a floating
point number as its mPitch argument, and you can get any tuning you
want through this on a note value. As for other schemes for midi tuning
tables, etc, etc, that is way beyond the scope of the current document.
What's needed to provide guitar controllers is simply support for
"omni-off
mono" messages (an important part of MIDI 1.0, see controllers 124 and
126 -
126 specifies the number of polyphonic voices desired), which might be
made
impossible to support under this proposal.
I'm sorry but I don't understand the problem, and I think you have
misread the document.
Perhaps this multi-part scenario could be selected only when a omni
off, poly-on message is recieved (and could reasonably be the default)
and
guitar mode could be chosen as it always has been on robust midi
implementations, whenever a omni-off mono-on message is received.
There is nothing in the document that prohibits this in any way.
The other possibility would be to always implement sysex single-note
retuning messages (specs available at the MMA website), which is good
and
desirable, but would not be backwards compatible with existing
hardware MIDI
guitars.
Doesn't seem necessary to me
Bill
Thanks much,
- Jeff
--
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.