RE: Re: Strange sysex problems
RE: Re: Strange sysex problems
- Subject: RE: Re: Strange sysex problems
- From: "Peter Karlsson" <email@hidden>
- Date: Sun, 9 Jan 2005 16:25:21 +0100
If you mean the buffer in my app I can say no, 100%. Because this is
happening with MIDI Echo and MIDI Monitor as well. Not 100% sure about
CoreMIDI. But I think the problem is the MIDISport.
Peter
Ursprungligt meddelande
> Based on absolutely nothing but a hunch, I wonder if there's an buffer
> overflow happening?
>
> The point about the numbers 3990 and 4256 is that 4096 occurs between
> them, and 4096 is a nice convenient size for a buffer.
> As it's the first message that's disappearing, perhaps the buffer is
> circular and the last message is overwriting the first?
>
> Pure speculation, of course, and no help at all in fixing the problem.
>
> Bob
> --
> On 9 Jan 2005, at 11:33, Peter Karlsson wrote:
>
> > I have made some experiments and can now tell what the problem is.
> > It's a
> > MIDISport 4x4 USB data toggle problem again... Sorry Pete to tell
> > this, but
> > I'm so tired of this interface. I'm already looking into a Edirol
> > UM-880.
> >
> > It does not matter if I use my own app, Kurt Revis MIDI Monitor or Doug
> > Wyatt's midi echo app. I can replicate this error everywhere. So
> > nothing is
> > wrong with my app. This is why it happens:
> >
> > A Roland MKS-50 tone dump is 4256 bytes, divided into 16 separate sysex
> > messages with a size of 266 bytes from F0 to F7. Like this:
> >
> > F0 xx xx xx --> xx xx F7 = 266 bytes, this repeats 16 times for a
> > total of
> > 4256 bytes.
> >
> > When I get the error I always receive 3990 bytes, this is exactly 15
> > sysex
> > messages. 266 * 15 = 3990 bytes. So one message is lost. What message
> > of
> > these 16 is lost, last one, first one or some in the middle? It's the
> > first! How can I tell, easy.
> >
> > That's because the 9'th byte in the message tells me what tone number
> > it
> > is. And the first tone number is always 4 when the error happens.
> > Tones 0 -
> > 3 is lost. And if I look at the sysex specification for this device I
> > can
> > see that every one of these 16 sysex messages have 4 tones each.
> >
> > After the first sysex message has dissapear (somewhere in the
> > MIDISport)
> > the MKS-50 sends the second sysex messahe, third sysex message and so
> > on,
> > so I receive only 3990 bytes, and this is why my app is not working.
> >
> > And as usual, this error only seems to happen the very first sysex dump
> > after the app is started, that makes me think it's a MIDISport USB data
> > toggle problem.
> >
> > To make another workaround to fix this is just too much trouble, if
> > it's
> > possible at all. I will not do it.
> >
> > Peter
> >
> > Ursprungligt meddelande
> >
> >> No that's not the problem. Because the MKS-50 can't respond to sysex
> >> requests. The dump is done by pressing some buttons on the MKS-50
> >> panel.
> >>
> >> Peter
> >>
> >> Ursprungligt meddelande
> >>
> >>> Are you sure it's the last packet that's missing and not the first ?
> >>> It
> >
> >>> should be some packet count in the sysex format. And if you invoke
> >>> the
> >>> dump by a sysex request and start the listening shortly after, maybe
> >>> you miss the first packet. That may explain the different behaviour
> >>> with the Midi Monitor.
> >>>
> >>> Fredrik
> >>>
> >>> 2005-01-08 kl. 20.17 skrev Peter Karlsson:
> >>>
> >>>> Just for the record. When the app does not continue, I always get
> >>>> 3990
> >>>> bytes and that is exactly 15 of 16 packages (15 * 266 = 3990). Where
> >>>> did
> >>>> the last 266 bytes go?
> >>>>
> >>>> Peter
> >>>>
> >>>> Ursprungligt meddelande
> >>>>
> >>>>> Dear list!
> >>>>>
> >>>>> My app waits for a Roland MKS-50 sysex tone dump (4256 bytes in 16
> >>>>> sysex
> >>>>> packages). I use this code to recieve the dump:
> >>>>>
> >>>>> static void MyReadProc(const MIDIPacketList *pktlist, void *refCon,
> >>>>> void
> >>>>> *connRefCon)
> >>>>> {
> >>>>> [myLock lock];
> >>>>> int i, j;
> >>>>> MIDIPacket *packet = (MIDIPacket *)pktlist->packet;
> >>>>> for (j=0 ; j < pktlist->numPackets; ++j)
> >>>>> {
> >>>>> for (i = 0; i < packet->length; ++i)
> >>>>> {
> >>>>> *sysex_ptr = packet->data[i];
> >>>>> sysex_ptr+=1;
> >>>>> sysexcounter+=1;
> >>>>> }
> >>>>> packet = MIDIPacketNext(packet);
> >>>>> }
> >>>>> [myLock unlockWithCondition:(sysexcounter < dumpSize ?
> >>>>> STILL_TRANSFERRING
> >>>> :
> >>>>> TRANSFER_DONE)];
> >>>>> }
> >>>>>
> >>>>> I wait for the dump to finish in a second thread like this:
> >>>>>
> >>>>> [myLock lockWhenCondition:TRANSFER_DONE]; // This waits for the
> >>>>> dump
> >
> >>>>> to
> >>>>> finish
> >>>>>
> >>>>> [myLock unlockWithCondition:TRANSFER_DONE];
> >>>>>
> >>>>> I tested this 20 times and sometimes I get the whole dump and the
> >>>>> second
> >>>>> thread continues, sometimes I don't get the whole dump and the
> >>>>> second
> >>>>> thread does not continue. About 50/50. When the app does not
> > continue
> >>>>> it
> >>>>> will if I send some more bytes from my Roland MKS-50 so it seems
> > that
> >>>>> some
> >>>>> bytes is lost somewhere.
> >>>>>
> >>>>> Now for the funny part. I started Kurt Revis MIDI Monitor and made
> > the
> >>>> same
> >>>>> 20 tests. My app now recieves the whole dump every time, 20 times
> >>>>> without
> >>>>> any problems at all.
> >>>>>
> >>>>> Just to be sure I stopped MIDI Monitor and my app did the wrong
> >>>>> thing
> >>>> again.
> >>>>>
> >>>>> Can someone please explain this behavior?
> >>>>>
> >>>>> Best regards Peter
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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:
> > 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