#393

Wait, what? How do I do that to my Teletypes?
12 scripts! Jezus, I have been waiting for some way of extending the script count for years!

2 Likes
#394

Maybe someone can apply my notes, probably with improvements, and make a publicly available version. I definitely do not want to be on the hook for support, nor do I want to put half-baked firmware in users’ hands.

2 Likes
#395

Ah.
Understood.
I got too excited there for a sec.
Thank you for the input!

#396

I tried applying your notes against current git, and something’s off or I’m missing something:

  1. I can edit the regular scripts 1-8 with ALT-F1-8, ALT-F9 edits A, ALT-F10 edits B, how do I edit C, D, METRO and INIT?

  2. same with executing C, D, METRO and INIT, pressing F9 and F10 executes A and B, can’t execute C,D, METRO and INIT

  3. When saving a scene to USB the content of B is written into #I, didn’t try but assume A is written into #M, no mention of #A, #B, #C and #D in the scene save .txt

Would be grateful if you could chime in here! For starters it seems your changes is done before the newly added ability to call M and I, is that correct? If so, which version did you apply these changes to? Also, if you have any ideas what might needs change, I’d be truly grateful!

NB: I packed my changes in a .diff, I could PM you, if you would like to take a look at it, maybe I just messed something up while applying your notes…

#397

This is what I mean about half-baked. :smiley: I never tested for hotkey script access since I always scroll through the scripts sequentially. I assume there is a missing bit one needs to update to map the ALT-F* keys to script numbers. Given the fact that there are only 12 function keys, I’d suggest mapping 9 and 10 back to the metro and init scripts. My own view of scripts A-D is that they are reserved for spillover init and subroutine use (via $); they lack input triggers, so they are in a different class than scripts 1-8.

This isn’t correct behavior. The changes required for usb_disk_mode.c are a little confusing. My version is attached.

usb_disk_mode.c (16.5 KB)

1 Like
#398

@a773 @jnoble
No pressure or anything, but just want to tell you that I am super enthused seeing this conversation happening… this is the first time I am seeing actual development-like exchange that takes the discussion of additional TT scripts out of conceptual exercise sphere and bringing it ever so closer to reality!
Thank you both!
:clap::heart:

1 Like
#399

Great, thanks!

Could you elaborate on this line (from usb_disk_mode.c):
if (l > PATTERN_LENGTH + 4) s = -1;

Why +4? I don’t understand why adding 4 scripts should add 4 to patternlength (but then again, I’m not too smart). Could this be part of another/separate experiment?

1 Like
#400

Because I screwed up when I blindly posted that file! :man_facepalming:

That’s for the extra four patterns I referred to above and has nothing to do with the additional scripts. I haven’t tested the extra patterns at all and there are obviously other changes required to make that happen. All I’ve gotten so far is a clean compile.

You’ll need to revert that line back to whatever the original code was–sorry about the confusion!

#401

Not so sure about that :thinking: original file from github 2 days ago says 68 hard coded…

I got 12 scripts working (light testing only), only thing is the name “c” of script c is dimmed (like muted scripts), it seems it’s only cosmetic, but it nags me, like it’s a bug waiting to eat me. Did you experience anything like this?

I looked through the source, but can’t find an explanation of why this happens. Should I PM you a diff against current git?

1 Like
#402

The PATTERN_LENGTH constant is something I added so longer patterns could be enabled via the #define in /src/state.h, but when I discovered it probably required a rewrite of the pattern UI, I reverted to the default of 64. I don’t like unexplained magic number in source generally so that’s another reason I changed it. I don’t have an explanation for why it’s 68 vs. 64 in the original.

My original explanation was obviously incorrect: it wasn’t for four extra patterns but rather for increased pattern length.

Yes, mine looks the same, and my “M” is also greyed out no matter the setting for M.ACT. I don’t have an explanation.

If I get some time I’ll dig into it. I took a couple months off from the modular until yesterday’s short live set. Life has been super busy and I’ve been doing less fun things like figuring out how/why Facebook completely borked their sharing function and debugger. :exploding_head:

#403

Since mine is not, it should be possible to compare sources and get a hint at what might be causing this…

#404

holy crap it’s been 2 months since that post where we got jnobles notes :dizzy_face:

I’ve tried the mod back then (rather quickly that is), failed due to said different base and never got to look into it again due to some (non-)exciting work circumstances. my tt is even still in a broken state :see_no_evil:

@a773 thanks for picking this up! do you have a fork on github?

sounds like a weird bug… buffer overflow somewhere? this coming from someone still standing on the sideline, with non-existent C experience besides some IPC hello world. but I’d love to learn from it.

1 Like
#405

Putting it out in the hope others will look at it and chime in and hopefully improve. So any feedback welcome!

I’m not gonna maintain source or hex-files, so you need to be able to compile your own firmware + apply a patch…

2 Likes
#406

Very nice thank you very much!!
Never diff’d to a file. Crazy helpful in this situation!

#407

Has there been any discussion of having arc drive teletype directly?

For example something like Cycles running which correlates the 4 triggers to tr inputs 1-4, and the 4 cv values to variables A-D…

2 Likes
#408

This gets drawn here. ss_get_mute(ss, idx) returns ss->variables.mutes[idx], but mutes only has a length of TRIGGER_INPUTS, which is 8. So for script index >= 8, this is an out of bounds array access, and will return whatever’s in nearby memory. I’m guessing this is maybe working by accident in the official firmware because struct padding means the next bytes are always 0, but this is a bug waiting to happen if more members get added to the scene_variables_t. Currently I think this has no effect, but should get fixed. (edit: PR)

From your diff, this line should keep the bounds check as s <= TT_SCRIPT_8 because script polarity only makes sense for the scripts with associated input triggers, and this potentially could also try to do an out of bound array access.

3 Likes
#409

Is there any work or thoughts on creating a method for the TT to send Crow asl info? It would be great to hijack the crow’s ability to create smooth sine LFO’s with the TT’s flexibility of live programming…

4 Likes
#410

An OP to control crow LFOs would be really awesome! It sounds like a fun project for learning about firmware hacking, but I imagine there would have to be some editing in both crow and teletype libraries? This was definitely the main reason I got a crow; hope we can make it happen soon!

1 Like
#411

If I want to know the parity (even/odd) of the value y I use % y 2 , is there any other ways to do the same?

Thanks.

#412

& y 1

or

BGET y 0

2 Likes