Re: Panther MIDI Receive Channels Missing bug!
Re: Panther MIDI Receive Channels Missing bug!
- Subject: Re: Panther MIDI Receive Channels Missing bug!
- From: Jeremy Sagan <email@hidden>
- Date: Wed, 29 Oct 2003 20:03:17 -0500
On Wednesday, October 29, 2003, at 05:32 PM, Doug Wyatt wrote:
>
On Oct 29, 2003, at 13:52, Jeremy Sagan wrote:
>
> On Wednesday, October 29, 2003, at 04:00 PM, Doug Wyatt wrote:
>
>
>
>> On Oct 27, 2003, at 19:06, Jeremy Sagan wrote:
>
>>> I am writing this message again because I did not seem to get any
>
>>> response the first time and I think this is a very important issue
>
>>> for MIDI applications. In 10.2 it was possible to set up devices
>
>>> like the sound canvas using Audio Midi Setup (AMS) so that a
>
>>> program could detect which channels were in use for input and
>
>>> output. Now, in Panther, it is impossible. This makes absolutely no
>
>>> sense (at least from where I am sitting). If I have a device like a
>
>>> MIDI controller which does not receive any channels (but sends
>
>>> some) and a device like a sound canvas which receives many (32)
>
>>> channels, my application essentially has 2 options both >>>> undesirable.
>
>>>
>
>>> 1. Operate under 10.2 principals where I assume the user can set
>
>>> the MIDI channels for an interface. This results in the sound
>
>>> canvas not being seen at all because, all MIDI interface devices
>
>>> return an error when inquiring about kMIDIPropertyReceiveChannels.
>
>>> This obviously is unacceptable to users.
>
>>>
>
>>> 2. Assume that if an error occurs when inquiring
>
>>> kMIDIPropertyReceiveChannels that it means that the device receive
>
>>> all channels. This has a very undesirable affect of having the MIDI
>
>>> controller keyboard say it is able to receive on all channels.
>
>>
>
>> Why are you seeing the controller as a destination in the first
>
>> place if it's really only a controller?
>
>
>
> The controller has a MIDI port with nothing connected. It is
>
> ridiculous to not allow the user to specify which channels are active
>
> on all ports. Now that you have the ability to specify the ports for
>
> devices, why not allow the channel settings on a port by port basis.
>
> I still think Jaguar handles this situation better than Panther.
>
>
Sorry, I meant to be more specific:
>
>
What does the controller look like? How many entities, sources and
>
destinations? Are you interrogating it as a device or as a destination
>
endpoint? If it's truly only a controller, it will not have a
>
destination endpoint to interrogate. If it's got an external MIDI Out
>
jack, then we're into the thorny multi-entity problem I'll elaborate
>
on in a sec ...
Like I said, the controller has an external MIDI out. I am
interrogating it as a destination by iterating through from 0 to
MIDIGetNumberOfDestinations.
>
>
>>> Can we have a fix for this? Or at least tell me a way to work
>
>>> around this problem!
>
>>
>
>> Well, you're aware that some objects just don't have the
>
>> receive-channels property set on them, and that you'll get an error
>
>> if you ask for it. When this happens, you have to make the least
>
>> harmful assumption, which in this case is to assume that you can
>
>> send to all MIDI channels.
>
> Why? Why can't I just setup AMS so that there are no channels for a
>
> specific device?
>
>
It's confusing and non-sensical to provide a UI for saying that all 8
>
ports of a UM-880 or Unitor 8 etc etc all listen only on channels 2,
>
6, and 10.
I could not disagree more. It is confusing and non-sensical to list to
the user 128 outputs when she only wants to see 8 or 16! It is quite
probably that on one or more of the 8 ports that not all of the
channels are in use!
>
>
>> The change from Jaguar to Panther was made to prevent a confusing
>
>> situation where you'd get all that UI for setting device properties
>
>> in cases where it makes no sense at all, for example, a 4-port MIDI
>
>> interface.
>
> If you allow the receive channels to be set on a port by port basis
>
> that will fix this problem the correct way!
>
>
Agreed, but there never was a UI for port-by-port (that is, entity)
>
configuration, and that's the essence of the problem -- all those
>
properties used to be set on a device level and that's just plain
>
wrong in the case of many multi-entity devices.
This is what needs to be fixed. It is best to have it on an entity
level. It is better to have it on a device level than not at all.
>
>
>> AMS still does allow property editing on driver devices but ONLY if
>
>> they only contain 1 entity and it is not an external MIDI connector.
>
>> If the device has external MIDI connectors, then we have the
>
>> confusing UI problem.
>
>
>
> This makes no sense to me. Let the user specify which connections are
>
> active in AMS then ALL applications can read the receivechannels
>
> property to determine which channels are active. If the device has 4
>
> MIDI ports then each port should have a 16 channel bitmap specifying
>
> which channels are active.
>
>
>
>>
>
>> I'd like to see examples of what devices are causing problems and
>
>> what their entity/endpoint configurations look like, in particular,
>
>> how many entities/sources/destinations there are, and whether the
>
>> entities are internal or external.
>
>>
>
> Well, the Edirol sound canvas SD-20, Evolution MIDI controller, Event
>
> EZBus, Roland SC-8820, etc., Essentially any USB device with built-in
>
> sounds should be reporting its receive channels on a port by port
>
> basis but is not!
>
>
I'm not saying that we think what's there is perfect -- we've probably
>
gone from one extreme to too far in the other.
I agree.
>
>
I don't have access to any of the devices you mention. Can you please
>
answer my specific question about what their entity/endpoint
>
configurations look like?
I am not really sure what you are asking for here. You know pretty much
what is on a sound-canvas. It has a USB port and it shows up as three
ports (in and out): SD-20 part a, part b, and MIDI. The properties are
not editable in AMS. It works in AMS, the way I would like, only if I
connect an imaginary device to the "SD-20 part a" and then set its
channels. So, in effect, you have something that looks absolutely
nothing like your studio. Very counterintuitive for the user. The
Evolution Controller is a device with a single port in and out, again
uneditable. I should at least be able to set the number of MIDI out
ports to 0 if I want. The other devices I do not have access to so I
will not comment on them. I do however also have a UM-880 and I do not
want to see 128 not-in-use ports as part of my output selection. The
user has to be able to select which ports and channels are in use, that
is the whole point of a centralized MIDI setup document.
>
>
> In my app, I build MIDI outputs based on what AMS is telling me and
>
> so if I go with your suggestion to assume that an error means all
>
> channels are available I then end up with a lot of superfluous
>
> outputs that the user has to go and manually delete. It just does
>
> make any sense.
>
>
You're going to get this error on any version of the OS going back to
>
10.0, if the user has not (for whatever reason) set this property, so
>
you have to deal with it sensibly. Yes, that means displaying what may
>
well be superfluous outputs, but that's preferable to failing to
>
display an output the user may wish to use.
I agree, it is preferable to work around this bug by showing
superfluous outputs. The real solution, though, is to fix it.
Jeremy
_______________________________________________
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.