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

Re: [sc-dev] SysEx bug proposition



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