Re: Coreaudio-api Digest, Vol 2, Issue 20
Re: Coreaudio-api Digest, Vol 2, Issue 20
- Subject: Re: Coreaudio-api Digest, Vol 2, Issue 20
- From: Bob Lang <email@hidden>
- Date: Wed, 19 Jan 2005 22:24:16 +0000
H'm
This may be completely off the wall, but could these problems be due to
continuously sent messages, like Active Sensing, confusing the driver
somewhere along the way? Perhaps it can't cope with an Active Sensing
in the middle of a Sysex?
Pure speculation and probably wrong!
Bob
--
On 19 Jan 2005, at 20:27, Jeff Schindler wrote:
FWIW, I'm seeing very similar issues with my MidiSport interface. The
first (and sometimes second and third) SysEx transmission disappears
and my app gets no response. The first is a Device Inquiry, the
others are custom SysEx messages. This happens roughly 100% of the
time. I haven't addressed the issue yet, but will likely add a retry
mechanism similar to what you describe. There appears to be a lot
more issues (ie bugs) dealing with SysEx on the mac than there really
should be...
Jeff
----- Original Message ----- From: "David Cornutt" <email@hidden>
To: <email@hidden>
Sent: Wednesday, January 19, 2005 3:01 PM
Subject: Re: Coreaudio-api Digest, Vol 2, Issue 20
First time poster here; please have patience...
I saw the discussion a couple of weeks ago about the
(I think it was) M-Audio interface that was losing data at the
first MIDI transmission by the app after initialization. I think
I'm seeing a similar problem, but it's with an MOTU MIDI Express
XT USB. When my app starts up, the first thing it does, after
setting up its ports and doing a connect, is send a Device
Query sysex. What I have found is that there is a high
probability (more than 1/2) that the first sysex transmission
either gets corrupted (generally two or three bytes of zeroes
followed by the F7), or just disappears altogether. I verified
this by connecting a MIDI monitor to the Thru port of the
target synth.
I added some code to my app to have it send the sysex,
wait 1/2-second, and try again. More often than not, it
doesn't get anything back the on the first try. However,
if it doesn't work on the first try, it always works on the
second try; I've never seen it have to retry more than once.
I've tried putting in delays in various places before and
after the port setup and connection and none of that
seems to make any difference, so I don't think it's timing-
related.
I have also corresponded with another developer who is
working with some sample code. His sample code connects
and then sends out a blast of note-on and note-off messages.
He says that most of the time, when he runs it using his
MOTU interface, the target synth receives nothing. He says
the same code always works with the M-Audio and Evolution
interfaces he's tried (I don't know which ones).
I've solved the problem with my own app by putting in the
retry code. But this has got me curious. Any thoughts:
(BTW: OS is 10.3.2 in my case; my correspondant is at 10.3.6.)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden