Glad to hear it! Have fun 
@Thor_Madsen the server wasn’t even booted when I did those tests, the language has no block size so I don’t think it could affect midi timing …
I’ve had a great day so far.
I’m sorry, just one more question, this one was actually quite expected.
When I send more messages in one cue, the looper can’t cope as it needs to execute one before it can execute another, so it doesn’t have the time. If I divide them in different cues it works.
But I would prefer to have them executed in one cue.
Yes, you guessed it, is there a way to delay the execution of certain actions inside a cue?
Yep,
fork {
//Something
0.1.wait;
//Something else, 1/10 second later
};
(Well there’s some fine print about this but I don’t think you’ll run into it for what you’re doing… for more see help files for Routine and TempoClock)
Yes, again you are absolutely right. it must be the sleep deprivation kicking in after touring in India for the last 3 weeks - its has been great but apparently it has also taken its toll on my brain! Sorry for the noise.
Great Eric, wow, thank you once again!
Tomorrow again fun time 
Hey, no worries, this stuff is confusing and it’s good to test our assumptions, I definitely learned some things! And congrats on the tour
Hi Eric,
I already ran into a small print.
As soon as i load the cuelist, the cue with the fork is being executed, it doesn’t wait for its turn.
Reading the Routine, Conditions and tempo clock didn’t get me further…
I am not sure I understand your problem. Everything you need to be executed should be inside the fork{ } bit. Here is a dummy code with long wait times just to demonstrate:
fork{
\FirstAction.postln;
1.wait;
\SecondAction.postln;
1.wait;
\LastAction.postln;
}
If you problem stems from sending multiple midi commands in rapid succession, you could create a variable to only accept new midi commands once the previous has ended. As before you need to define this variable outside the mididef:
// outside mididef
~ready = true
// inside mididef:
if (~ready)
{
~ready = false;
fork{
\FirstAction.postln;
1.wait;
\SecondAction.postln;
1.wait;
\LastAction.postln;
~ready = true
}
}
Hi Thor,
This is a part of the code:
(
var prevVal = 0;
~n = 0;
~cues = [
// cue 1 - Ready
{ ~m1.control(0, ctlNum: 47, val: 62); // track lock
~m4.control(15, ctlNum: 59, val: 63); //pan looper
"1".postln;
"ready?".postln;
"next: start recording".postln
},
//cue 2 - record A1
{ ~m1.control(0, ctlNum: 40, val: 0);
~m4.control(15, ctlNum: 58, val: 127);//voc off
"2".postln;
"Recording A1".postln;
"next: confirm".postln
},
//cue 3 - Confirm recording
fork { ~m1.control(0, ctlNum: 41, val: 20); //Confirm
"3".postln;
1.wait;
"confirmed track 1 and locked the track".postln;
"next: record the back vocals".postln
},
//cue 4 - Lock track
{ ~m1.control(0, ctlNum: 47, val: 62); // track lock
"4".postln;
"locked the track".postln;
"next: record the back vocals".postln
},
];
I trigger the n with another line of code.
MIDIdef.cc(\most,
{arg val;
if ((val == 1) and: (prevVal == 0)) {
~cues[~n].value;
~n = ~n+1;
};
prevVal = val;
}, 127);
)
So in this small version, I have 4 cues in this list, each triggering their own set of commands, sometimes just one midi and for the rest communicating the status with the postln.
When I “fork” the 3rd cue, it executes the 3rd step as soon as I load the patch, not waiting for the “n” to reach 3.
And then, when the “n” reaches 3, it acts as if nothing hapenned.
From 4 on, it goes on with its life like as if nothing happened.
By the way, how did the tour go?
Which project?
Oh, I didn’t see the solution part of your message.
I think the problem implementing the solution is that I am not actually using the MIDIDef to trigger the cues, only to increase the value of “n”.
I was hoping I would get away with it easily 
You need cue3 to be a function you can execute with a fork inside the function, so wrap the code inside { }
//cue 3 - Confirm recording
{
fork { ~m1.control(0, ctlNum: 41, val: 20); //Confirm
"3".postln;
1.wait;
"confirmed track 1 and locked the track".postln;
"next: record the back vocals".postln
}
}
Tour is going well:)
YEEEEEEEEES
That is working !!!
1 Like
Guys,
I know you won’t be willing to hold my hand forever 
But 
I am having problems executing some actions in the right moment.
Example:
I want to trigger the cue 15 before the end of the bar.
But:
- some actions in the cue should happen when I hit the cue, before the end of the bar and
- some exactly after we entered the next bar (Next part of the song)
It is so that the looper I am using sends the midi message 113, value 0 at every transition between parts, so at the new bar.
Reverse-engineering the solutions you kindly shared, I made a MIDIdef that receives that message and sends 1 to a new bus ( ~t = 1 ).
After 1 second it sends ~t back to zero.
MIDIdef.cc(\partchange,
{ arg val,
if(val == 0)
{
fork {
~t = 1;
1.wait;
~t = 0;
}}
},113);
With the idea to use ~t to allow certain actions in the certain cue to be triggered when ~n is right and ~t is 1.
And then reset ~t to zero so I can use it again next time I need it down the lane.
But this is a brick wall again. I have no idea how to implemment that in the following cue:
{ fork
{ "15".postln;
~m4.control(15, ctlNum: 57, val: 127); //Mute guitar
~m4.control(15, ctlNum: 58, val: 127); //Mute voice
~m1.control(0, ctlNum: 113, val: 102); // Part B switch
// THIS IS WHERE I NEED TO WAIT FOR THE NEXT PART BEFORE I ENTER EXECUTING THE FOLLOWING MESSAGES. THE 1.wait; IS ONLY WORKING SOMETIMES WHEN I TRIGGER THE CUE AT THE RIGHT TIME BUT IN PLAYING THE SONG I DON'T HAVE THE FOCUS TO DO IT RIGHT EVERY TIME.
1.wait;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
0.2.wait;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
0.2.wait;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
0.2.wait;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
0.2.wait;
~m1.control(0, ctlNum: 41, val: 100);// Record/play/overdub
"next: GOTO A".postln
}
},
I assume the implementation of this lies in an element holding down the further execution of the fork until it hears ~t = 1.
But which and how?
Beats me.
By the way, right now, I am trying to control the looper on the most difficult piece I want to work on.
When this is done, with all the solutions you already were kind to help me with, the ride should become signifficantly less bumpy.
I think I found solution, copy/paste from the help files.
I used Routine to introduce the hang and then unhanged it with MIDIDef.
Until now, no fine print yet. If you see some, please let me know.
C=Condition.new;
MIDIdef.cc(\partchange4,
{ arg val, num, chan;
if(val == 0)
{
fork
{
c.unhang;
1.wait;
c.hang;
}}
},113);
And then, that same cue:
{
Routine { "15".postln;
~m4.control(15, ctlNum: 57, val: 127); //Mute guitar
~m4.control(15, ctlNum: 58, val: 127); //Mute voice
~m1.control(0, ctlNum: 113, val: 102); // B2 switch
c.hang;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
0.2.wait;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
0.2.wait;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
0.2.wait;
~m1.control(0, ctlNum: 41, val: 104);// Select prev track
"15".postln;
"PLAY B2, record extra vocals".postln;
2.wait;
~m1.control(0, ctlNum: 41, val: 100);// Record/play/overdub
"next: GOTO A".postln
}.play
},
The script is growing …