SysEx bug proposition

[thelych]

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@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-dev

[Josh Parmenter]

Is there anyone who can test this? I have no way myself.

Josh

On Feb 5, 2008, at 6:11 AM, thelych wrote:

> 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@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-dev

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

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

[Dan Stowell]

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@...>:

> 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@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-dev
>

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

[thelych]

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@...>:
>> 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@...
>> http://lists.create.ucsb.edu/mailman/listinfo/sc-dev
>>
>
>
> --
> http://www.mcld.co.uk
> _______________________________________________
> sc-dev mailing list
> sc-dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-dev

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

[James Harkins-2]

Don't just e-mail again. Open a tracker bug -- e-mails can get lost or
forgotten, but if it's on the tracker, there is more accountability
for it. That's the right way to log issues. (Dan, you knew that :)

http://sourceforge.net/tracker/?group_id=54622&atid=474248

I recall trying sysex once upon a time, and it didn't work for me. It
wasn't important enough for me to follow up on at the time.

hjh

On Feb 5, 2008 12:31 PM, thelych <thelych@...> wrote:

> 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@...>:
> >> 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@...
> >> http://lists.create.ucsb.edu/mailman/listinfo/sc-dev
> >>
> >
> >
> > --
> > http://www.mcld.co.uk
> > _______________________________________________
> > sc-dev mailing list
> > sc-dev@...
> > http://lists.create.ucsb.edu/mailman/listinfo/sc-dev
>
> _______________________________________________
> sc-dev mailing list
> sc-dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-dev
>

--
James Harkins /// dewdrop world
jamshark70@...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman
_______________________________________________
sc-dev mailing list
sc-dev@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-dev

[thelych]

Hi all,

seems i'm the only one playing with CocoaBridge (or Midi  
Sysex :-))... i am not very up-to-date but.. anyway

Jan, 'double's do not pass well to cocoa objects when using invocation

example: (from the doc)

(
var winname = "cocoa test", win, nsname, slider;
nsname = SCNSObject("NSString","initWithCString:length:", [winname,  
winname.size], false);

win = SCNSObject("NSWindow",  
"initWithContentRect:styleMask:backing:defer:",
        [Rect(100,140,400,30), 10, 2, 1]);
win.setDelegate.action_({
        "closing window, releasing objects".postln;
        [winname,nsname,slider,e].do{|it| it.release};
});

slider = SCNSObject("NSSlider", "initWithFrame:", [Rect(0,0,390,20)]);
e = SCNSObject("SCGraphView", "initWithFrame:", [Rect(0,0,400,30)]);

win.invoke("setContentView:", [e], true);
e.invoke("addSubview:", [slider], true);

slider.invoke("setFloatValue:", [0.5]); // OK for FLOATs
slider.invoke("setMaxValue:", [300.0]); // Here Problems for double  
values -> zeroed
slider.invoke("setMinValue:", [10.0]); // Same here....

slider.invoke("maxValue").postln; // Result is 0
slider.invoke("minValue").postln; // Result is 0

win.invoke("makeKeyAndOrderFront:", [nil], true);
win.invoke("setTitle:", [nsname]);

{a = slider.initAction;
a.action_({|v,val| val.postln});}.defer(0.1); // WELL... ZERO...
)


//// in CocoaBridgePrimitives.M:278
if(!(*cType == _C_FLT || *cType == _C_DBL)){post("wrong type at arg: %
i excepted float\n", i); return errWrongType;}
float val;
slotFloatVal(slot, &val);
[anInvocation setArgument: &val atIndex: i+2];  /// <---  if _C_DBL  
we should pass a reference to a double, the reference to a float  do  
not work for this case.


Best,

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

[Jan Trutzschler-2]

Hi,

On Feb 23, 2008, at 12:13 AM, thelych wrote:

> Hi all,
>
> seems i'm the only one playing with CocoaBridge (or Midi
> Sysex :-))... i am not very up-to-date but.. anyway

probably, because since Ryan's excellent CocoaCollider < http://
www.wabdo.com/CocoaCollider/index.html >
there wasn't any further development of the CocoaBridge. Probably it  
should be removed.

Best,
Jan

>
> Jan, 'double's do not pass well to cocoa objects when using invocation
>
> example: (from the doc)
>
> (
> var winname = "cocoa test", win, nsname, slider;
> nsname = SCNSObject("NSString","initWithCString:length:", [winname,
> winname.size], false);
>
> win = SCNSObject("NSWindow",
> "initWithContentRect:styleMask:backing:defer:",
> [Rect(100,140,400,30), 10, 2, 1]);
> win.setDelegate.action_({
> "closing window, releasing objects".postln;
> [winname,nsname,slider,e].do{|it| it.release};
> });
>
> slider = SCNSObject("NSSlider", "initWithFrame:", [Rect(0,0,390,20)]);
> e = SCNSObject("SCGraphView", "initWithFrame:", [Rect(0,0,400,30)]);
>
> win.invoke("setContentView:", [e], true);
> e.invoke("addSubview:", [slider], true);
>
> slider.invoke("setFloatValue:", [0.5]); // OK for FLOATs
> slider.invoke("setMaxValue:", [300.0]); // Here Problems for double
> values -> zeroed
> slider.invoke("setMinValue:", [10.0]); // Same here....
>
> slider.invoke("maxValue").postln; // Result is 0
> slider.invoke("minValue").postln; // Result is 0
>
> win.invoke("makeKeyAndOrderFront:", [nil], true);
> win.invoke("setTitle:", [nsname]);
>
> {a = slider.initAction;
> a.action_({|v,val| val.postln});}.defer(0.1); // WELL... ZERO...
> )
>
>
> //// in CocoaBridgePrimitives.M:278
> if(!(*cType == _C_FLT || *cType == _C_DBL)){post("wrong type at arg: %
> i excepted float\n", i); return errWrongType;}
> float val;
> slotFloatVal(slot, &val);
> [anInvocation setArgument: &val atIndex: i+2];  /// <---  if _C_DBL
> we should pass a reference to a double, the reference to a float  do
> not work for this case.
>
>
> Best,
>
> thelych
> _______________________________________________
> sc-dev mailing list
> sc-dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-dev

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

[thelych]

Hi Jan,

>
> probably, because since Ryan's excellent CocoaCollider < http://
> www.wabdo.com/CocoaCollider/index.html >
> there wasn't any further development of the CocoaBridge.

I know CocoaCollider, it is very nice i agree, but i do not use it.  
Full binding is nice if you use extensively ObjC, but <humble  
opinion> it has also an overhead. I tend to prefer the light approach  
of CocoaBridge for managing small additions to sc using Objc/Cocoa :  
it is effective and the invocation mechanism is the same.


> Probably it
> should be removed.

I understand perfectly from the CocoaCollider point of view. Ryan's  
work is the perfect addition for using a full-option Cocoa with SC.  
But, <still a personal user view>, i don't want to have two  
applications for one purpose. SuperCollider development is constantly  
changing. I prefer to have one application.
For exemple, if i want to draw an NSImage with SuperCollider, i will  
prefer CocoaBridge, i won't use CocoaCollider for a simple addition.  
(or i can choose SwingOSC wich offers also a java alternative for  
GUIs and do not need to have a 'different' sc application). As a  
second exemple, for testing for small projects i modified the  
CocoaBridge, so it can accept Class methods and do simple automatic  
conversions  (along with the doesNotUnderstand method in sc you can  
create nice Proxies) and i still had a light and transparent approach  
that suited my needs...But of course that's my point of view.
I do not know if you fully understand me but i really think  
CocoaBridge is a very nice alternative, wich keeps the transparent/
decoupled aspect of distributed/remote messaging.

Thanks a lot for your response and attention Jan

best
thelych

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