Yay, adapted the teletype script at http://samdoshi.com/post/2016/03/teletype-euclidean/ to also send SC.TR pulses on channels 1-4 by adding to the last line on script 3:
; SC.TR.P 1
and likewise for script 4:
; SC.TR.P 2
and so on, and so forth
Next step is configuring TXi knobs + some external knobs to modify spaces and pulses. This is going to be fun!!!
I have a very similar scene! I use the TT knob to control the Length for all tracks, then Txi knobs 1-4 control Fill for tracks 1-4. I had to make sure that Fill was sort of “capped” at Length, otherwise Fill exceeding Length had the affect of muting that track.
I feel like I’m going to need more Txi’s now Hopefully some more kits will come available soon!
One fun thing to try is to mix the euclidean gates with, say, a Planar, and then quantize the output - steerable arps that are correlated to the various ERs, especially fun if each ER is different lengths!
This is posted on lines, but I’ll post here as well for those not following that thread because it is ER-301 specific - it uses i2c to control the 301.
I’m calling this one Pillar. It’s 2 Euclidean trigger sequencers and one turtle-based note/gate sequencer. You’ll need a grid, teletype, ER-301 to make use of it. It has only been tested on teletype firmware 2.3 RC 3, and ER-301 0.3.25 stable firmware. This was basically my one day, self-guided crash course in the new grid ops. which are super sweet.
Zip file contains the teletype scene and a pdf manual. Would appreciate any suggestions. I’m not sure any features can be added unless the code can be refactored somehow - the scripts are pretty full.
Pillar.zip (843.7 KB)
Quick idea without testing – could you put the script runs (’$ 4’) on the same line as some other stuff? using a semicolon.
Thanks! That’s a great idea, @josker! That would free up several (much needed) lines. I think the current script continues to execute even if you call another, right? If so the only thing I’d have to watch out for is order of operations. A lot of the lines are procedural in nature. And the other question is if the lines get freed up in the right scripts to be useful. I will look into it!
A couple of things I was desperately searching for extra code lines for were A) having the 2 Euclidean trigger buttons flash when they send a trigger so that you could visualize the rhythm, and B) currently if you press a button in the turtle sequencer, the faders for the trigger sequencer display arbitrary values (though it doesn’t actually change their setting).
Great to see you getting stuck into Grid TT - haven’t fully read the script yet, but looks interesting - thanks for sharing
Flashing LED, I am no expert, but use G.LED x y level to get something like:
G.LED 8 7 15; DEL 100; G.LED 8 7 4
In the script that sends the trigger should work fine, there may be a better way to do it of course.
…not sure about the faders!
Yep. The problem with flashing the trigger buttons is actually not having enough code lines left in the right scripts.
Maybe after a day or so away from it, I’ll be able to refactor something.
There are a few aliases you could use to shorten some lines. (Eg. + and - for ADD and SUB).
Another good idea. I’ve looked at some of those and can def give it another pass for anything I missed. There are quite a few script lines in here where you’ll see a pattern akin to:
X = something,
and then on the next line setting
something else = X.
And it’s so damn close to being able to being able to to it in one elegant line without setting an intermediate variable like X. But it ends up being like 1 or 2 characters too long even trying to use the aliases.
I also think I’m using every single variable here including Q as a 1 length, plus a lot of the pattern storage. And maybe robbing Peter to pay Paul with a couple of them…
Hmm, looks like I forgot to put a
G.RST in here too. That can definitely fit in
#I so I’ll include that when I do an update.
teletype is not “multi threaded”, there is always only one script executing at any moment. scripts are executed in the order they are triggered. when a script is triggered while another is executing, the currently executing script will finish first.
the only exception to this is when a script is called from another script using the
SCRIPT op. in this case the current script will pause, the called script will get executed, and then the current script will resume.
you don’t really need it in the init script - whenever a new scene is loaded it will do a grid reset. the op is mostly useful when you’re experimenting in the live screen and want to get back to the initial state.
this is super impressive for a first day with grid integration!
This is good to know, as I had assumed they could run concurrently. This might explain one of the things I included in the PDF as a known issue.
I don’t think I had fully appreciated this either, the thing is so damn fast it’s not obvious!
Silly questions, what happens if you send the same trigger ‘multed’ to all trigger inputs? I’m not sure why you would want to do this, but just out of interest
my reply above wasn’t correct, i’ve edited it.
there is an event queue. everything (almost) gets processed by the main event loop. whenever an external trigger is received, or a grid or keyboard button is pressed it will place an event into the queue. so if there is a script executing when a trigger is received the script will NOT get interrupted. it’ll finish that and go to the next event, and once it gets to the trigger event it will execute the corresponding script.
but: if a script is called from another script it will interrupt the caller script, just as a synchronous function call normally would. hope this clarifies things!
it will execute all the scripts triggered by those inputs, but the order is probably nondeterministic.
Right, that sits much easier with my previous understanding of how it worked and makes sense - thank you for taking the time to explain so clearly
The zip file above (and on lines) contains a teletype scene and a PDF file. The PDF is a written manual for Pillar.
ah, cool, i’ll check it out!