[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] SysEx bug proposition



thanks Dan

I will repost it in a week or more to remind it to the dev-list... if i remind it myself, i do not use MIDI so much...(except for special cases like the one that pointed me this).

best
thelych


Le 5 févr. 08 à 17:29, Dan Stowell a écrit :

Hi -

I think it's better to leave this until after 3.2 is released, since
it's nontrivial and there isn't much time available for testing.

Thanks for proposing it though - please make sure we don't forget it.
Post again in a week or so (which is when 3.2 will be out!) if we all
seem to have forgotten it. However, I don't use MIDI at all myself and
I have no idea if there's anyone else around who'll be in a position
to look at this.

Dan


2008/2/5, thelych <thelych@xxxxxxxxx>:
Hi All,

I posted yesterday an issue concerning the strange reception of sysex
messages by SuperCollider.
I know most people don't use SysEx but it was my only way to control
my old Waldork synth so i decided to look for the bug in the SC Code.
i have found two problems that were getting the sysex message to be
received improperly by SC (and to have some bytes duplicated for no
reason) so i wanted
to ask for confirmation.

The issue concern Mac OS X CoreMidi, as i do not have Linux i cannot
tell about SysEx for this platform.

In File SC_CoreMIDI.cpp
-------------------------------------

In Function midiProcessPacket (near line 180)
-------------------------------------------------------

case 0xF0 :
midiProcessSystemPacket(pkt, chan);
//i += 1;
i += pkt->length; // PROPOSITION: in usual case data should contain
only the sysex message so it is better to stop iteration (instead of i
+=1) and avoid data duplication in the PyrArray
break;

default :       // data byte => continuing sysex message
chan = 0;
midiProcessSystemPacket(pkt, chan);
//i += 1;
i += pkt->length; // PROPOSITION: same issue if we leave (i += 1)
break;


In Function midiProcessSystemPacket (near line 75)
-------------------------------------------------------

switch (chan) {
case 7: // PROPOSITION: 0xF7 Sysex EOX must be taken into account if
first on data otherwise it is missed by SC on the doSysexAction
case 0:
         sysexArray = newPyrInt8Array(g->gc, pkt->length, 0, true);
         memcpy(sysexArray->b, pkt->data, pkt->length);
         sysexArray->size = pkt->length;
SetObject(g->sp, (PyrObject*) sysexArray); // chan
argument unneeded as there
runInterpreter(g, s_midiSysexAction, 3 ); // special sysex
action in the lang
  break;


May be midiProcessSystemPacket should return the number of packets
processed in data in order to be compliant with other MIDI Message
wich increments the index.
And the other System Common message do not return the number of
packets processed wich can lead to a disfunction too (if we imagine a
single packet data can contain multiple Midi Messages... but i've
never seen this case)
(
example in midiProcessPacket:
case 0xF0 :
i += midiProcessSystemPacket(pkt, chan);
break;
...ect...
)


thanks for your response and any comment back on this.
I just want to help. I know most of you are busy.

best regards
thelych
_______________________________________________
sc-dev mailing list
sc-dev@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-dev



--
http://www.mcld.co.uk
_______________________________________________
sc-dev mailing list
sc-dev@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-dev