[chuck-users] confused about time/control

[Peter Lutek]

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