Re: MIDIPacketList behaviour problem
Re: MIDIPacketList behaviour problem
- Subject: Re: MIDIPacketList behaviour problem
- From: Pete Gontier <email@hidden>
- Date: Tue, 20 Jan 2004 16:03:56 -0800
circa 1/20/04 15:41, Michael Harbour <email@hidden>
wrote:
>
> I do the MIDISPORT driver,
>
>
ahhhhh. great stuff. is there much left to do to it development wise
>
now or is it just maintainence when layers above and below change?
Generally, it's just maintenance. The USB MIDI driver supports a zillion
devices, give or take a few hundred thou, and when a new one appears I add a
table entry and recompile. If I have to do more than that, I file a bug
report against the device, because my driver defines correct behavior at
this point. :-)
>
> and a loopback cable works just fine. In fact, I use that as one of the first
>
> quick tests of a new driver revision. If I can send a message around the
>
> loop, I know I haven't broken anything big and I move on to see if I've
>
> broken anything small. Sending one message definitely doesn't result in
>
> receiving 127, so there must be something wrong above the driver level.
>
>
righto. so that would suggest the behaviour is in the coreaudio code?
Dunno. Could be in the MIDI server, could be in the CoreMIDI client library,
could be in the Java glue, could be in your app... There are probably layers
I don't even know about as well.
>
> You might want to use some other application to do the sending.
>
>
I've seen the same behaviour just now when I squirt a midi message into
>
the MIDISport from my Kenton Control Freak at the same time I'm sending
>
out messages to it - the incoming message arrives 127 times when
>
something is going out, but only once when output is quiet.
OK, that's good to know. Suggests a busy connection is the problem.
>
> I think there is a simple PlayNotes sample app rattling around
>
> somewhere. It's written in C.
>
>
Oh, I'm reluctant to compile and run code i dont...etc :-)
Heh. I assumed a Java programmer knows C. I guess that makes me a bigot. :-)
>
> And by the way, the hardware worries about baud. You might want to throttle
>
> your output to avoid choking the receiver,
>
Sorry, you've lost me there, could you expand on this - it sounds like
>
it's relevant. If this means something like threading...
Nah. I just mean some MIDI devices can't swallow data at full MIDI speed in
a sustained burst. They'll drop bytes or go into a coma. But we're talking
very large message sizes. I've tested my driver with messages of hundreds of
KB on a loopback cable, talking to other machines running the same driver,
etc. Out around a few tens of KB, some external devices start to choke. Most
people send these big sysex messages from sequencer apps, so they get
throttled at the app level and nobody notices, but if you're building a
librarian, you may have to compile a list of devices and the speeds they'll
accept reliably. (I don't have such a list.) You may end up throttling at
the app level depending on what device you're talking to. Or you may just
throttle back to a speed you know pretty much always works even if you might
be talking to a device which could have handled full speed forever.
--
Pete Gontier
http://www.m-audio.com/
_______________________________________________
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.