Cool. Unfortunately that code means nothing to me cuz I don’t fuck with grid ops OR the 301, BUT I’d say 1) try to avoid relying on the faderbank as a source of continuous values. It’s less processor-intensive to poll it infrequently and set up a slew than it is to have it check it every 25 ms (this will begin to blossom issues when you are running more ambitious scenes with more going on, so try not to patch in a way that relies on these hyper-speed metro times). The I2C ecosystem really isn’t optimized for this kind of continuous control, and it’s probably better to just use the actual CV outs of the faderbank for that sort of scenario.

With that in mind, I’d recommend setting FB values as they become relevant, so the script that calls an action from the ER-301 also includes an update for the FB value. If the ER-301 event is currently triggered by a trigger into the ER-301, then just put it into a teletype scene and run something like:

tr.p 4
[send 301 that fb data]

and plug that trigger into the 301 (which just sidesteps needing a mult).

If you’re looking for true continuous control of the 301 I think you want something like:

8
DEL 25: $ 8
[send fb data to 301]

but this second thing will almost certainly create a buggy mess for you eventually if it becomes a habit.

Again: No 301 or GRIDOPS experience, but LOTS of time asking my faderbank nicely to send continuous values over I2C (and lots of completely system-breaking bug experiences!).

1 Like

Is it possible to control 2 Just Friends modules with a single Teletype using Just Type?

1 Like

Not yet. The infrastructure supports it but the ops are being hammered out. Crow can do it (although I have not tested).

My day job is utterly consuming my life (launching a medical device into production since June…) but JF4.0 OPs are at the top of my list once I break free :bowing_man: I would not be offended at all if someone else wanted to grab those reins! I can always help test; that’s a nice, mindless evening task after a long day of making burnt offerings to the FDA…

in general, if you need to use the metro script for multiple tasks where each task needs to run at a different rate, you can run it at the fastest rate and then use ops like EVERY #: for things that need lower rates. let’s say you set metro rate to 25ms and this is your metro:

#M
TR.P 1
EVERY 2: TR.P 2
EVERY 5: TR.P 3

trigger 1 will fire on every metro execution, so every 25ms. trigger 2 will fire on each 2nd metro execution, so it will use 25 * 2 = 50ms rate, and trigger 3 will use 5 * 25 = 125ms rate.


for your specific scenario you don’t need that, however. you have several options - leave metro to deal with polling the faderbank and sending values to er-301, and then assign all your grid buttons to the same script and modify it like this:

I G.BTNI
G.BTN.L I 15
DEL 50: G.BTN.L I 0
SC.TR.TOG I

btw, in your implementation it will trigger on both press and release - is that what you want?

alternatively, if you also want to do different things in scripts 1-8, assign the grid buttons to the init script and change it like this:

#I
IF G.GBTN.C 0: $ G.GBTI; BREAK
G.BTX 1 0 0 4 4 0 0 10 4 2
M.ACT 1

when the scene is loaded, there are no pressed buttons, so it will do the initialization portion, otherwise it will serve as your script selector for button presses.

2 Likes

Is there a way to avoid the six line per script limitation? I’m finishing a complete scene and I have the eight scripts plus metronome script and init script full. I just need two or three lines more of code in 4 scripts…

As I understand it, there is no way around this limitation. Perhaps you can share your script so that the community can help condense it!

Yeah, sharing the code has been my intention since I started write it, but I would like to share something that works.
Could I load another scene with SCENE op in order to get more lines of code available? If so, is it efficient?

I initially switched scenes (from code) to have more parts available, works fine.

I later found more efficient ways to accomplish what I want, so went back to one scene pr track/project. I did however hack the firmware to have 8 additional scripts (loosing 8 scenes to make space), which is more than enough space for me.

I hope you share some examples, lots of clever people hang out here, they will most certainly enjoy helping you out!

NB:
My teletype code is here:

My +8 script patch (implemented from a textual description discussed I-forgot-where on lines) is here:

1 Like

Ok, this afternoon I’ll share what I’ve done. Hope somebody can help to figure out how to rewrite the code with less lines, because it’s incomplete.
Anyway, I’m pretty interested in know how to hack the firmware to have 8 additional scripts. Loosing scenes wouldn’t be a problem right now. Could you explain that? I’m a newbie in the awesome Teletype’s world!

You have to be able to compile your own firmware…

  1. download the teletype firmware from https://github.com/monome/teletype
  2. download and apply my patch https://raw.githubusercontent.com/attejensen/eurorack_firmware_patches/master/teletype_16_scripts_24_scenes.diff
  3. install the patched firmware on your teletype
3 Likes

Id be up for this. I know having fewer scripts sprouts creativity but also fustration some times.
What do you mean by apply my patch? How do i do that?
I have a few teletypes and i have one thats is normally used for sequencing and another for sound generation \ lfo …i always run out of space when scaling params or faders from txi or faderbank.
Cheers and thanks for sharing!

This is under linux, if you run mac or windows you’ll have to figure out how to do similar things, others here might be able to help:

git clone --recursive --config core.autocrlf=input https://github.com/monome/teletype
git clone https://github.com/attejensen/eurorack_firmware_patches.git
cd teletype/
patch -p0 < ../eurorack_firmware_patches/teletype_16_scripts_24_scenes.diff 
docker run --rm -it -v/home/atte/downloads/test/teletype:/target dewb/monome-build bash

At this point type make (+return), after the build finishes type exit (+return). Your firmware will be in teletype/module/teletype.hex

Thanks for your repky @a773 :slight_smile:
Would this commands work on mac terminal?
They look like it could , apologies the only make compiling i have done has been under mutable instruments vagrant.
Ill give it a go :slight_smile:
Thanks!

visually at least it looks like everything should run in a Mac terminal assuming you have docker.

1 Like

Thanks for the head ups @alanza , nope never used docker before. But i guess its time to learn, cheers!

Edited: spoke too soon, seems to only work on mojave or catalina :frowning:

Linking an issue here @MeguAzu is having. I tested this on my Teletype and got the same issue. The values seem to fluctuate with from the 4MS SMR only through the Teletype. Anyone have ay ideas?

I’m losing my mind over here trying to figure out whether my Teletype’s BPM calculations are off, or if it’s my OP-Z to blame. Either way, when I set both to, say, 80 BPM, they fairly quickly drift out of sync.

Am I missing something here about how the Teletype calculates BPM? I there a “resolution” of this calculation that I need to configure? Help!

Teletype doesn’t do decimal numbers (in my understanding). BPM just did this:

60,000 / [BPM]

Depending on the value, you could get a decimal value. TT will ignore the decimal. Example:

87 BPM = 689.65517....

TT will just set at 689 ms. (I could be wrong and maybe it rounds instead of just dropping the remainder for BPM, although I’m certain the standard division just drops the remainder – not at the synth rn)

TT is a great leading clock, but I’d advise using a dedicated clock module (or setting temp at TT first and syncing your other gear to it manually), due to the ms limitation. It’s not really a resolution issue (ms increments are actually “higher resolution” than BPM), but more of a ‘unit conversion’ issue.

4 Likes

Thank you, this is incredibly helpful! And it explains why I can get my TT and OP-Z to sync at 120 BPM (500 ms) but not at 90 bpm (666.666… ms). I was, I kid you not, sitting there switching from M 333 and M 334, trying desperately to imagine everything staying on time.

Until I can justify shelling out for the OP-Z expander, I guess I’ll just compose music in whole-number millisecond BPMs. It’s kind of a novel constraint, actually.

Thank you again!