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