Stopping by to inquire about the ol’ MLR script–think you might revisit that at some point?
I’ve been working on a slight edit of it for the STS that I shared here, but it’s still super preliminary. Works by sending a slewed signal upwards that resets on each button press/whenever the sequence moves forwards, which is passed into the start position input on the STS to create a fine granular scrub, and the speed of the slew affects the speed of playback. It doesn’t sound perfect but it sounds and feels really cool, and I think a lot of the kinks can be worked out… one question mark I’ve run into is how to get the tracks running independently from each other, so I can adjust the playback speed of individual channels? Been messing with the DEL ops but haven’t figured out a nifty way of getting that to function yet. Definitely keeping this project going, and hopefully convince a few other people to try out the STS as that is a very powerful sampler!
Stopping by to inquire about the ol’ MLR script–think you might revisit that at some point?
afraid it would be quite some time before i would get a chance to work on the MLR script again - just too many projects waiting, including more teletype grid studies…
looking at the old MLR script i posted here it should be pretty straightforward to modify it to have independent clock for each track if you are willing to clock it externally. metro script just triggers script 1, which then loops through advancing each track:
#1 L 0 3: A I; SCRIPT 3
and looks like scripts 5, 6, 7 are not used (if i’m looking at the right version). so what you could do instead is use external triggers into inputs 1, 5, 6, 7 and modify the scripts as follows:
#1 A 0; SCRIPT 3 #5 A 1; SCRIPT 3 #6 A 2; SCRIPT 3 #7 A 3; SCRIPT 3
you could also refactor it so you can use trigger inputs 1-4, you’ll have to move scripts 2-4 to 5-7 and update all the script references.
could also probably refactor it to still use the internal clock. and if you just want independent divisions of the main clock do something like:
#1 EVERY 1: A 0; SCRIPT 3 EVERY 4: A 1; SCRIPT 3 EVERY 7: A 2; SCRIPT 3 EVERY 13: A 3; SCRIPT 3
This is invaluable! I’ll keep posted as this continues, think I might make use of crow for the next step—thanks for the input
Question for grip ops users:
I am trying to make a grip ops sequencer using my 64 grid where the sequence advances along the X axis on every metro and along the Y axis latched grid buttons will indicate what scripts to trigger, from 1-7. For example coordinates (0,1) will trigger script 1 on the first beat, and (4,7) will trigger script 7 on the fifth beat. Simply put, using the grid to create an internal gate sequencer to sequence the triggering of scripts.
Here’s where I’m at:
M BPM PARAM
G.LED P.I 0 0
P.NEXT; G.LED P.I 0 15
PARAM.SCALE 40 240
G.BTX 1 0 1 1 1 1 0 0 8 7
(PARAM knob is my tempo knob, a blinky light goes across row 0 with the metro when it’s running, and all other 56 buttons are enabled for latching. I have P 0 going between 0 and 7)
I’m trying to find a way to get teletype to read (every metro) which LEDs are lit at P.I and use the y coordinate value to trigger all of the scripts which have the buttons lit. I was thinking this would be the easiest way but now I’m a bit stuck, so perhaps I’m going about it wrong. Is there a way to be like at “at x coordinate P.I, trigger $ y coordinate” Even if this is possible will I be running into a problem getting it to trigger multiple scripts on the same beat? Perhaps I have to do some sort of L function…?
Thank you in advance if anyone has tips, I tried looking at Scanner Darkly’s rain scene but it’s not quite doing what I’m looking for and I couldn’t quite figure how to make it apply…
Yep, a loop is your ticket. Sadly, you also need an
IF, at least from what I can figure, and you can’t mix prefixes. Happily, you won’t be using script 8 for anything else, so you can use it for a little subroutine. I’d interject into
M at line 3:
L 1 7: $ 8 and then do the following…
#8 IF G.LED P.I I: $ I
Does that make sense? (Also does it work, I’m not at my modular to test) This is a simple and cool idea BTW!
so you have a block of 7 rows of 8 buttons each.
P.I indicates the current column. on each step you want to trigger the scripts that have the corresponding buttons latched. this does require a loop, because on each step you need to check each of the 7 rows. since there are 7 scripts we can trigger, this leaves one script that can be used for this task.
add this line to the metro script before you advance to the next step:
L 1 7: SCRIPT 8
in script 8 we now need to do this: check the button located in the row specified by variable
I (which gets passed from the calling loop) and the column specified by
P.I and fire a corresponding script if it’s latched. to check a button state we can use
G.BTN.V index op, where index is the button index. when you use
G.BTX to create a block of buttons, the first parameter is the starting index, and buttons are given consecutive numbers, arranged left to right first, then top to bottom. so in case of your block the indexes are:
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 ... and so on
to get the index of the button we want we can use this formula:
J - + P.I * I 8 7
since there are 8 buttons in each row, we multiple the row number (
I) by 8 and add the current horizontal position (
P.I). we then need to shift it by 7 so that the leftmost button in row 1 gives us index 1, which is the starting index in your button block definition (you can change it to start with 8 instead of 1, then you don’t need to subtract 7 here).
with the button index now determined it’s easy to do the rest:
IF G.BTN.V J: SCRIPT I
another suggestion - instead of using
G.LED and a separate row to indicate the current step you can do this:
G.CLR G.REC P.I 1 1 7 -2 -2
G.CLR removes all previously drawn LEDs - but this doesn’t affect buttons and faders. then we draw a 1 column wide rectangle using the special brightness level of
-2 - it makes everything underneath it a little brighter. this way you can see the current step in the sequencer itself.
now, could we expand this to all 8 scripts and 8 rows? yes! define the button block like this:
G.BTX 8 0 0 1 1 1 0 0 8 8
and change metro to this:
G.CLR G.REC P.I 0 1 8 -2 -2 J P.I L 1 8: $ * I G.BTN.V + J * I 8 P.NEXT
here is what happens here: we use a similar formula to calculate the button index and we get that button’s state. it can only be 1 (if it’s pressed/latched) or 0. so when we multiply it by
I we either get the script number (since we just multiple by 1) or 0.
SCRIPT 0 does nothing, since there is no script 9 which is exactly the effect we want and allows us to combine this all in one loop without using
this line has the max number of characters, so if you want to use this with grid 128 this won’t fit:
L 1 8: $ * I G.BTN.V + T * I 16
instead, store 16 in a variable:
Z 16 and use it instead:
L 1 8: $ * I G.BTN.V + T * I Z
G.LED not get the lit state of buttons? My bad
it returns the current brightness for the specified LED drawn with
G.RCT ops, it will ignore LEDs set by buttons/faders. it’s 2 layers essentially, one layer is buttons / faders, then the layer on top is canvas you can draw on.
Wow thank you so much i know you probably hear this all the time but I’m so grateful for everything you do, and this is simply too much! <3
The script as I had it planned is 100% working with your notes. The one without using script 8 is not working exactly as expected. I chanced
J P.I to
T P.I (which I think is what you meant because I don’t see J doing anything here), and it works for scripts 1-7 but not 8. I think it’s because row 0 is “0”, rows 1-7 call scripts 1-7 but there is no way to call 8 because there is not an “8th” row. I tried substituting an I for a variable like
A + I 1 but that didn’t quite do it, I think it throws off the multiplying down to 0 trick too…
Also the 128 grid version would just be a longer sequence, 16 steps long, you wouldn’t need to have do
L 1 16 would you?
In anycase thank you both for your help (shout out @misuba too, coming through )
(secret test @scanner_darkly )
thank you, yeah for 128 version it should be
L 1 8: - good catch!
and i fixed the 8 row 64 grid version, there were a couple of variables incorrectly used, give it a try! (the reason i use
J is because otherwise the next line doesn’t fit). make sure to update your
I script too since the 8 row version requires a different index and number of rows. i also changed your
G.BTX - it was assigning script 1 to all button presses which is probably not the desired effect.
I’m finding some odd behaviour in G.FDR switching between type 4 and type 6. 4 (fine, horizontal bar) works as expected as one fader but 6 (fine, horizontal dot) breaks the fader into two where the light gets dimmer to the middle then bright again at the 9th button and subsequently dimmer until the end of the row. Is this normal or am I missing something elsewhere?
The line in question is:
G.FDR 0 0 4 16 1 6 16 7
yeah, looks like there is a bug. i’ll take a look!
I noticed the behaviour on firmware 3.0 and 3.2 if that’s any help — thanks as always! Let me know if there’s any testing I can do to help.
Hi. Long time lurker… really enjoying the community here: First post!
I’m running v3.2.0 teletype but have now added a new Grid (1st June Batch) to my setup. Grid works fine with Ansible (which needed the update 3.1.1) but doesn’t appear to work with Teletype. I presume this is because my Teletype (newer black-back version) is not New Grid ready? Should I move to the new Teletype 4.0 beta or wait?
(Incidentally I can’t see any mention of the new Grid in the 4.0 thread but I presume that support is assumed.)
Just as caution…you haven’t plugged the grid directly into TT, right?
That shouldn be a problem though…
yes yes! 4.0 has the new grid support
it seems like the beta’s been going super well, so likely a release is imminent but you should give it a spin if you haven’t!
this one is fine to host grids directly via usb, whereas you should (and often need to) power the grid externally with the green board model
woah i totally missed that!
i might try to hunt down a newer version
just make sure your case has sufficient power left for the grid if you plug it directly into teletype.
Many thanks! Yes… all working hunky dory with power. Intellijel 7 U running some power hungry modules including Brenso and ER 301 and it all seems very happy. I’ve added a bcp txb to help with power duties on the i2c bus and all tested fine. My only final question was wondering why the New Grid was unresponsive to my Grid operators. It seems I should wait for the exciting 4.0!