Sysex correction +

[thelych]

Hi All,

I (re)worked the past days on the sysex bug currently occurring for  
mac os x, and i wanted to share my work on that.
globally, i added sysex parsing directly on source, (sysex triggered  
to sclang when parsed as valid), an 'invalid' action -> triggers  
invalid sysex message.
added also running status, so sc can interpret it...ect...

I join you the modified file SC_CoreMidi.cpp + MidiOut.sc (just added  
the invalid action to MIDIIn / sysex action could be changed too,  
although it works without modification)
and midiTestIAC.rtf, wich is a test file presenting most issues using  
IAC driver (so anybody can run all tests and report any possible  
issues without external devices)

personally, i tested it with the hardware i had with me (a Waldorf  
microPulse and an old Yamaha Promix01). I dumped successfully sysex  
messages ranging from 70 to 2322 bytes.

I hope some of you will have the time to test it and report on it.

And if nobody object, the possibility to commit it, if everything is  
ok ?





best,
charles picasso


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

[ronald kuivila]

Hi all,

Any objections to the following?

+MIDIIn {

*connectAll {

if (MIDIClient.initialized.not) {

MIDIClient.list;

MIDIClient.init( MIDIClient.sources.size, MIDIClient.destinations.size);

MIDIClient.sources.size.do({ arg i; 

MIDIIn.connect(i, MIDIClient.sources.at(i));

});

}

}

}

RJK

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

[felix-38]

that's what I just added.

tho slightly different:

*connectAll {

if(MIDIClient.initialized.not,{ MIDIClient.init });

MIDIClient.sources.do({ |src,i|

MIDIIn.connect(i,src);

});

}

because MIDIClient.init now lists, then connects to all of those.

same thing tho

-cx

On Mon, Apr 14, 2008 at 11:10 PM, ronald kuivila <rkuivila@...> wrote:

Hi all,

Any objections to the following?

+MIDIIn {

*connectAll {

if (MIDIClient.initialized.not) {

MIDIClient.list;

MIDIClient.init( MIDIClient.sources.size, MIDIClient.destinations.size);

MIDIClient.sources.size.do({ arg i; 

MIDIIn.connect(i, MIDIClient.sources.at(i));

});

}

}

}

RJK

_______

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

[ronald kuivila]

Hi Felix,

 It is very odd that there was a sudden flurry of MIDI activity, must be Spring...

 BTW: when you resize and SCWindow, it does not take immediately. So

a = SCWindow.new;

a.bounds_(Rect(128, 64, 500, 400));

a.bounds;

yields:

Rect(128, 64, 400, 400)

'refresh' does not fix it.  

Why is that the case and is there any work around? 

RJK

On Apr 14, 2008, at 5:47 PM, felix wrote:

that's what I just added.

tho slightly different:

*connectAll {

if(MIDIClient.initialized.not,{ MIDIClient.init });

MIDIClient.sources.do({ |src,i|

MIDIIn.connect(i,src);

});

}

because MIDIClient.init now lists, then connects to all of those.

same thing tho

-cx

On Mon, Apr 14, 2008 at 11:10 PM, ronald kuivila <rkuivila@...> wrote:

Hi all,

Any objections to the following?

+MIDIIn {

*connectAll {

if (MIDIClient.initialized.not) {

MIDIClient.list;

MIDIClient.init( MIDIClient.sources.size, MIDIClient.destinations.size);

MIDIClient.sources.size.do({ arg i; 

MIDIIn.connect(i, MIDIClient.sources.at(i));

});

}

}

}

RJK

_______

_______________________________________________

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

[felix-38]

you have changed the subject, now marije will be very cross :)

yes, you have to wait for it to front (to actually draw itself).

{ a.bounds }.defer

works

it makes sense actually. in  a way

-cx

On Mon, Apr 14, 2008 at 11:58 PM, ronald kuivila <rkuivila@...> wrote:

 BTW: when you resize and SCWindow, it does not take immediately. So

a = SCWindow.new;

a.bounds_(Rect(128, 64, 500, 400));

a.bounds;

yields:

Rect(128, 64, 400, 400)

'refresh' does not fix it.  

Why is that the case and is there any work around? 

RJK

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

[ronald kuivila]

Hi,

 If it was just defer, I wouldn't complain, but I had to put in a delay of a 1/50 of a second. And that won't

work correctly if things hang initializing MIDI input or something.  It's interesting how often this kind of 

scheduling issue arises.  Do you want the current state or the state intended for your logical time?

RJK

On Apr 14, 2008, at 7:39 PM, felix wrote:

you have changed the subject, now marije will be very cross :)

yes, you have to wait for it to front (to actually draw itself).

{ a.bounds }.defer

works

it makes sense actually. in  a way

-cx

On Mon, Apr 14, 2008 at 11:58 PM, ronald kuivila <rkuivila@...> wrote:

 BTW: when you resize and SCWindow, it does not take immediately. So

a = SCWindow.new;

a.bounds_(Rect(128, 64, 500, 400));

a.bounds;

yields:

Rect(128, 64, 400, 400)

'refresh' does not fix it.  

Why is that the case and is there any work around? 

RJK

_______________________________________________

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

[nescivi]

Hiho,

I have no time to look into it, but if it doesn't change the interface between
the C++-primitive and the lang class it should be fine from a cross platform
point of view.
Otherwise, changes will be needed for windows and linux as well..

sincerely,
Marije

On Monday 14 April 2008 15:33:43 thelych@... wrote:

> Hi All,
>
> I (re)worked the past days on the sysex bug currently occurring for
> mac os x, and i wanted to share my work on that.
> globally, i added sysex parsing directly on source, (sysex triggered
> to sclang when parsed as valid), an 'invalid' action -> triggers
> invalid sysex message.
> added also running status, so sc can interpret it...ect...
>
> I join you the modified file SC_CoreMidi.cpp + MidiOut.sc (just added
> the invalid action to MIDIIn / sysex action could be changed too,
> although it works without modification)
> and midiTestIAC.rtf, wich is a test file presenting most issues using
> IAC driver (so anybody can run all tests and report any possible
> issues without external devices)
>
> personally, i tested it with the hardware i had with me (a Waldorf
> microPulse and an old Yamaha Promix01). I dumped successfully sysex
> messages ranging from 70 to 2322 bytes.
>
> I hope some of you will have the time to test it and report on it.
>
> And if nobody object, the possibility to commit it, if everything is
> ok ?

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

[nescivi]

Hiho,

On Monday 14 April 2008 19:39:09 felix wrote:
> you have changed the subject, now marije will be very cross :)

only when it becomes a habit ;)

sorry, since we have no official moderator, I sort of felt compelled to step
in and remind people of general mailinglist netiquette, only for the poster's
best interests, who supposedly wants their questions to be heard.

sincerely,
Marije

PS, I am by no means volunteering for list moderation.
_______________________________________________
sc-dev mailing list
sc-dev@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-dev

[Dan Stowell]

Really, since we're looking at asynchronous method(s), the best way to
handle this business would be to pass an action to be evaluated once
the job is done...

Dan

2008/4/15, ronald kuivila <rkuivila@...>:

>  Hi,
>
>  If it was just defer, I wouldn't complain, but I had to put in a delay of a
> 1/50 of a second. And that won't
> work correctly if things hang initializing MIDI input or something.  It's
> interesting how often this kind of
> scheduling issue arises.  Do you want the current state or the state
> intended for your logical time?
>
> RJK
>
>
> On Apr 14, 2008, at 7:39 PM, felix wrote:
>
>
> you have changed the subject, now marije will be very cross :)
>
> yes, you have to wait for it to front (to actually draw itself).
> { a.bounds }.defer
> works
>
>
> it makes sense actually. in  a way
>
> -cx
>
> On Mon, Apr 14, 2008 at 11:58 PM, ronald kuivila <rkuivila@...>
> wrote:
>
> >
> >
> >
> >
> >  BTW: when you resize and SCWindow, it does not take immediately. So
> >
> > a = SCWindow.new;
> > a.bounds_(Rect(128, 64, 500, 400));
> > a.bounds;
> >
> >
> > yields:
> > Rect(128, 64, 400, 400)
> >
> >
> > 'refresh' does not fix it.
> > Why is that the case and is there any work around?
> >
> >
> > RJK
> >
> >
>
> _______________________________________________
> 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
>
>

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

[ronald kuivila]

Hi Dan,

Yes, that sounds right to me.

Actually, I find the approach of creating a Routine and blocking the  
most intuitive.
(I use MIDIEvent and made an OSCEvent for that reason.)  Is there  
anything already
floating around to use a callback this way?

RJK
       
       
On Apr 15, 2008, at 8:08 AM, Dan Stowell wrote:

> Really, since we're looking at asynchronous method(s), the best way to
> handle this business would be to pass an action to be evaluated once
> the job is done...
>
> Dan
>
> 2008/4/15, ronald kuivila <rkuivila@...>:
>>  Hi,
>>
>>  If it was just defer, I wouldn't complain, but I had to put in a  
>> delay of a
>> 1/50 of a second. And that won't
>> work correctly if things hang initializing MIDI input or  
>> something.  It's
>> interesting how often this kind of
>> scheduling issue arises.  Do you want the current state or the state
>> intended for your logical time?
>>
>> RJK
>>
>>
>> On Apr 14, 2008, at 7:39 PM, felix wrote:
>>
>>
>> you have changed the subject, now marije will be very cross :)
>>
>> yes, you have to wait for it to front (to actually draw itself).
>> { a.bounds }.defer
>> works
>>
>>
>> it makes sense actually. in  a way
>>
>> -cx
>>
>> On Mon, Apr 14, 2008 at 11:58 PM, ronald kuivila  
>> <rkuivila@...>
>> wrote:
>>
>>>
>>>
>>>
>>>
>>>  BTW: when you resize and SCWindow, it does not take immediately. So
>>>
>>> a = SCWindow.new;
>>> a.bounds_(Rect(128, 64, 500, 400));
>>> a.bounds;
>>>
>>>
>>> yields:
>>> Rect(128, 64, 400, 400)
>>>
>>>
>>> 'refresh' does not fix it.
>>> Why is that the case and is there any work around?
>>>
>>>
>>> RJK
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> 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