Re: G5's Stealth Port/ Logic Audio / Panther's midi assignation of ports / Enclosure Problem Id 3160466
Re: G5's Stealth Port/ Logic Audio / Panther's midi assignation of ports / Enclosure Problem Id 3160466
- Subject: Re: G5's Stealth Port/ Logic Audio / Panther's midi assignation of ports / Enclosure Problem Id 3160466
- From: Cyril Blanc <email@hidden>
- Date: Fri, 05 Dec 2003 10:23:08 +0100
Hello Herbie,
Thank you for this information.
Another way is to take the interface in the same order that they are defined
in the Audio Midi Setup (from left to right)
Because it is strange that when you boot with the serial midi and without
the USB midi, your setup is good.
If you power on after the USB midi, it comes before the serial midi and your
midi setup I not good anymore.
Suppose that I add another USB midi interface, it is going to be a mess !
;o(
Another solution is that the Emagic Apple does the same thing that they did
in OS9 where you could define in the Midi setup : in 1st I have a serial
midi interface, in second a USB Midi interface in 3rd a USB Midi Interface
Thank to all of you
Best
Cyril
On 12/5/03 9:35 AM, "Herbie Robinson" <email@hidden> wrote:
>
> Hello
>
>
>
> I am beta testing for Geethree the Stealth for the G5 under Panther on a 2 x
>
> 2 Ghz G5.
>
> The problem I have report end of January 2003 "Enclosure Problem Id 3160466"
>
> is still there
>
>
>
> The problem is :
>
> When you take a Logic song from OS 9 to OS X all your midi setup has to be
>
> redone as the USB interface comes first in the list of available ports.
>
> I have also try to freak out the midi setup : ;o)
>
> * I switch off the USB midi interface
>
> * I open the OS 9 song
>
> * I get a message to translate to the new format
>
> * I save the song as (at this point the Midi settings are ok).
>
> * I Close the song.
>
> * I Power up USB midi interface
>
> * I Open the new created 'Os X song'
>
> All your midi setup is wrong !
>
>
>
> Can you work all together to find a solution ; that will be so nice ;o)
>
>
My first thought was this: If the machine only has one device of a
>
particular make or model on it, the driver should always recognize it
>
(no matter what the properties kSerialNumberProperty or
>
kUSBLocationProperty currently have in them). This would be a simple
>
modification of the loop in
>
USBMIDIDeviceManager::UseDeviceAndInterface. Unfortunately, it won't
>
work, because USB devices can be hot plugged at any time and may come
>
and go at the system's whim; so, you can never be sure you only have
>
one device of a given type.
>
>
There is already code in the latest version of the sample USB driver
>
to handle matching. If there is a serial number available from the
>
device, it uses the serial number to match up hardware with logical
>
devices.
>
>
If there is no serial number available, then the USB location
>
obtained from the GetLocationID method is the only thing left and the
>
sample driver code tries to deal with that as best it can.
>
Unfortunately, this numbering is likely to change any time you breath
>
on your USB cables (and might also change if the OS decides to
>
enumerate the devices differently -- it sounds like that's what
>
Panther did).
>
>
The only way around this that I can think of would be to have a way
>
to edit the location IDs from Audio MIDI Setup. That way you could
>
fix it quickly when it got screwed up. Another UI for this would be
>
to allow the user to swap any two interfaces: It would do that by
>
swapping the kSerialNumberProperty and/or kUSBLocationProperty
>
properties on the two devices, shutting down the Core MIDI server,
>
and bringing it up again. That seems a little more intuitive than
>
editing location IDs. The reason for swapping serial numbers, is to
>
allow for replacing broken hardware with a new unit.
>
>
Obviously, any device that has an EEPROM should be given a serial
>
number. If it doesn't, the driver should get a UUID and write that
>
into the device's EEPROM to function as the serial number.
>
>
One should obviously avoid getting more than one of any kind of USB
>
device that requires any sort of configuration unless said devices
>
have an EEPROM or some other facility for returning serail numbers.
>
>
BTW, I think there is a bug in the algorithm in
>
USBMIDIDeviceManager::UseDeviceAndInterface. Consider the following
>
example. We start up with two logical MIDI devices that have 123 and
>
124 for kUSBLocationProperty, but the devices plugged in have 122 and
>
123 for location IDs. If the hardware presents with 122 first and
>
123 second, the logical MIDI device 123 will be connected to both
>
pieces of hardware (i don't know how far that will get before it
>
crashes). Also, the location IDs will never get updated from the
>
configuration that existed when the devices were created. It looks
>
like the "case 3" in the loop should update kUSBLocationProperty when
>
it gets a match.
>
>
> 2 Serial MTP interfaces are networked, they connect all my synth. On the USB
>
> AMT8 I have one Logic control and 4 Logic Control XT (USB port 1 to 5).
>
>
>
> If you need more details do not hesitate to contact me at :
>
> email@hidden
>
>
>
> Thanks in advance.
>
>
>
> Best regards
>
>
>
> Cyril Blanc
>
> France
_______________________________________________
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.