confused about time/control
greetings! a little help for a newbie?.... when i run this bit of code, i would have expected the while loop to run for only 5 seconds, printing out a new value for "beat" whenever new data comes in from MIDI. then, it should print "done". instead, it just keeps printing the new "beat" values for as long as i let it run, never getting to the "done" line. i don't understand why the "while( now < later )" doesn't kill the loop after 5 seconds. also, xruns go through the roof and i have to kill it externally. i'm on linux, using jack. (all the setup of MIDI ports and variables happens before this, and i know it's functioning fine...) //////////// dur beat; now + 5::second => time later; while( now < later ){ while( min.recv(msgin) ){ ( msgin.data3 + 10 ) * 50::ms => beat; <<<beat>>>; } } <<<"done">>>; /////////// thanks much, in advance... cheers! .pltk. -- Peter Lutek improvising musician in Toronto, Canada http://peterlutek.com
In order to advance 'now' and make it eventually equal or higher than
'later' you should put inside your loop something like:
now + 5::second => time later;
while(now < later) {
...
1::second => now;
}
2014-10-22 11:50 GMT-05:00 Peter Lutek
greetings! a little help for a newbie?....
when i run this bit of code, i would have expected the while loop to run for only 5 seconds, printing out a new value for "beat" whenever new data comes in from MIDI. then, it should print "done". instead, it just keeps printing the new "beat" values for as long as i let it run, never getting to the "done" line. i don't understand why the "while( now < later )" doesn't kill the loop after 5 seconds.
also, xruns go through the roof and i have to kill it externally. i'm on linux, using jack. (all the setup of MIDI ports and variables happens before this, and i know it's functioning fine...)
////////////
dur beat;
now + 5::second => time later; while( now < later ){ while( min.recv(msgin) ){ ( msgin.data3 + 10 ) * 50::ms => beat; <<<beat>>>; } } <<<"done">>>;
///////////
thanks much, in advance... cheers! .pltk.
-- Peter Lutek improvising musician in Toronto, Canada http://peterlutek.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- -Moisés
On 2014-10-22 13:12, Moisés Gabriel Cachay Tello wrote:
In order to advance 'now' and make it eventually equal or higher than 'later' you should put inside your loop something like:
now + 5::second => time later; while(now < later) { ... 1::second => now; }
d'oh..... silly me! thanks a lot, Moisés! cheers! .pltk. -- Peter Lutek improvising musician in Toronto, Canada http://peterlutek.com
On 2014-10-22 13:12, Moisés Gabriel Cachay Tello wrote:
In order to advance 'now' and make it eventually equal or higher than 'later' you should put inside your loop something like:
now + 5::second => time later; while(now < later) { ... 1::second => now; }
ok, so now it works sometimes, but other times ChucK crashes, with this error: chuck: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. any clues? here's the code, as it stands: ///////// // set up MIDI MidiIn min; MidiOut mout; MidiMsg msgin; MidiMsg msgout; // connect to port 1 and print result <<<"","">>>; <<<"MIDI-in then MIDI-out:","">>>; <<< min.open(1),"" >>>; <<< mout.open(1),"" >>>; <<<"","">>>; dur beat; now + 30::second => time later; while( now < later ){ if( min.recv(msgin) ){ ( msgin.data3 + 10 ) * 50::ms => beat; <<<beat>>>; } 50::ms => now; } <<<"done">>>; ////////// thanks for any help... cheers! .pltk. -- Peter Lutek improvising musician in Toronto, Canada http://peterlutek.com
I think it's customary to wait on a midi event instead of regular pauses,
like:
min => now;
while( min.recv( msg ) )
(...)
Check out the midi section in the docs:
http://chuck.cs.princeton.edu/doc/language/event.html#midi
On Thu, Oct 23, 2014 at 3:59 AM, Peter Lutek
On 2014-10-22 13:12, Moisés Gabriel Cachay Tello wrote:
In order to advance 'now' and make it eventually equal or higher than 'later' you should put inside your loop something like:
now + 5::second => time later; while(now < later) { ... 1::second => now; }
ok, so now it works sometimes, but other times ChucK crashes, with this error: chuck: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
any clues?
here's the code, as it stands:
/////////
// set up MIDI MidiIn min; MidiOut mout; MidiMsg msgin; MidiMsg msgout;
// connect to port 1 and print result <<<"","">>>; <<<"MIDI-in then MIDI-out:","">>>; <<< min.open(1),"" >>>; <<< mout.open(1),"" >>>; <<<"","">>>;
dur beat;
now + 30::second => time later; while( now < later ){ if( min.recv(msgin) ){ ( msgin.data3 + 10 ) * 50::ms => beat; <<<beat>>>; } 50::ms => now; } <<<"done">>>;
//////////
thanks for any help... cheers!
.pltk.
-- Peter Lutek improvising musician in Toronto, Canada http://peterlutek.com _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Release me, insect, or I will destroy the Cosmos!
Hi Peter, You should try Jack2 instead of Jack. I am not sure it will solve your mutex problem but it is more safe when using ChucK and it will certainly reduce the number of Xrun you have. Cheers, Julien On 23/10/2014 03:59, Peter Lutek wrote:
On 2014-10-22 13:12, Moisés Gabriel Cachay Tello wrote:
In order to advance 'now' and make it eventually equal or higher than 'later' you should put inside your loop something like:
now + 5::second => time later; while(now < later) { ... 1::second => now; }
ok, so now it works sometimes, but other times ChucK crashes, with this error: chuck: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
any clues?
here's the code, as it stands:
/////////
// set up MIDI MidiIn min; MidiOut mout; MidiMsg msgin; MidiMsg msgout;
// connect to port 1 and print result <<<"","">>>; <<<"MIDI-in then MIDI-out:","">>>; <<< min.open(1),"" >>>; <<< mout.open(1),"" >>>; <<<"","">>>;
dur beat;
now + 30::second => time later; while( now < later ){ if( min.recv(msgin) ){ ( msgin.data3 + 10 ) * 50::ms => beat; <<<beat>>>; } 50::ms => now; } <<<"done">>>;
//////////
thanks for any help... cheers! .pltk.
On 2014-10-23 08:21, Julien Saint-Martin wrote:
Hi Peter,
You should try Jack2 instead of Jack. I am not sure it will solve your mutex problem but it is more safe when using ChucK and it will certainly reduce the number of Xrun you have.
thanks a lot julien (and also stefan for reminding me about min => now, which i had gone through in the tutorial, but wasn't sure how to implement it in a loop)! i'm now back on my main system (crunchbang debian-SID (64-bit), jack2, RME multiface on ExpressCard), which is a tested production environment and is generally reliable at 44100/128/2 for live use. i've usually used puredata, but am testing ChucK 1.3.4.0. i've got amended ChucK code, with some new observations.... starting with chuck --loop, if i then add this shred, everything works fine, and xruns are minimal (i see updated values for "beat", calculated from incoming MIDI, and then i see the "done" message after 30s: //// // set up MIDI MidiIn min; MidiOut mout; MidiMsg msgin; MidiMsg msgout; // connect to port 1 and print result <<<"MIDI in: ",min.open(1)>>>; <<<"MIDI out: ",mout.open(1)>>>; dur beat; now + 30::second => time later; while( now < later ){ min => now; while( min.recv(msgin) ){ ( msgin.data3 + 10 ) * 50::ms => beat; <<<beat>>>; } } <<<"done">>>; //// note, however, that when the shred exits the connection from MIDI-in to ChucK persists, while the one to MIDI-out disappears (observed in qjackctl). then, if i add the same shred again, ChucK claims to have made both MIDI connections (i.e. i see "1" for both the min.open(1) and mout.open(1) debug prints), but the connections window in qjackctl remains unchanged, showing only a connection from MIDI-in to ChucK, and showing no MIDI-out port from ChucK at all. also, the shred gets stuck there -- i don't see any updated values of "beat" upon MIDI input, and the shred never reaches "done". the shred just persists forever, without doing anything. if i use a version of the shred with no min.open or mout.open statements (hoping to re-use the MIDI-in connections which seems to persist), the same hung behaviour as above ensues... so, it seems that when the first shred finishes, the MIDI port system is left in some kind of dysfunctional state! am i missing something about how to deal with MIDI connections around stopping and starting shreds? (i see there is no .close event for MidiIn or MidiOut, so we can't explicitly take down our connections on shred exit.) ...or is this some issue related to the ALSA/Jack subsystem or a hardware problem? thanks again for any help anyone can offer... cheers! .pltk. -- Peter Lutek improvising musician in Toronto, Canada http://peterlutek.com
participants (4)
-
Julien Saint-Martin -
Moisés Gabriel Cachay Tello -
Peter Lutek -
Stefan Blixt