#387

I’ve been thinking of TT integration with Crow. Those that are far more technical, what do you guys think? Do you think the following might eventually be possible?

  1. in Crow file.lua: Create a set of arbitrary functions (e.g. function retrograde () to reverse cv sequence already playing on crow)
    – Maybe decorate these functions in .lua that are specifically designed for TT triggering?
    – Not sure how to balance function names with TT code line length
    – If function names are too problematic (too long, etc.) maybe set aside an arbitrary number of function placeholders on TT side? (crow.func1, crow.func2 ?)
    – not sure how to handle arguments, but i’m assuming since you defined them yourself, you just have to keep consistent with yourself?
  2. on TT INIT: crow.import to load functions into TT namespace (that you defined in step 1.)
  3. on TT script 1: crow.retrograde which will reverse the cv sequence on crow on every trigger of script 1.

The idea is to keep TT event based but move the potential complexity to crow. The issue I see is with sharing TT scripts if this is implemented, with a bunch of customs functions, it might not be possible to share as seamlessly as before. Maybe this is an argument to keep function names as descriptive as possible so people can understand in context. Or since crow has a .lua single file limit, just attach the .lua file with your TT script.

4 Likes
#388

did a quick search for desktop emulator support for the teletype and could not find a canonical thread (perhap one of you can point there).

I’m guessing the usb implementation make it having teletype act as a device for an external host untenable, difficult or ergonomically annoying.

My question is could Crow act as the device communicating with an external host and thereby act as a bidirectional conduit between the host and TT.

Being able to edit and run scripts and commands from a computer is the application that prompted this post.

That said I could imagine this forming a bridge to a variety of external communication mediated through external computing devices: more exotic like talking to m4l, other scripting languages, etc and more utilitarian ones like easy backup and scene loading, easily managing your crow and TT code in the same source repo, etc.

#389

The main repo has some simulator code that gives you a simple REPL for testing ops and stuff, stubbing out all the hardware behavior with printf messages. I haven’t really used this and I think it basically is sort of a “live mode” simulation, so it may not be quite what you want for scripting.

The awesome VCV Rack ports of the Trilogy modules are based on swapping out IO code from libavr32, so it should be possible to do such an emulation of Teletype, but there’s definitely quite a bit of work to do there to emulate the screen and keyboard support.

To some extent you probably could do this, yeah. You would need some way to put TT in I2C follower mode for receiving text input, and I don’t yet understand how crow’s I2C packet construction works well enough to tell you what kind of modifications this might need on the crow side. Sending a ton of data over the I2C bus may also interfere with other stuff on the bus. Some interesting stuff to figure out here, and seems fairly similar to having an I2C leader supply a whole preset to some follower module, an interesting possibility.

Another thing you could probably do is use the UART header on the back of TT to establish a full-fledged terminal session with TT. Note that I have no idea if such a thing is possible with TT’s board design without a hardware mod. Currently the UART is only used for printing debug information (TT transmitting to host) but it should be possible with some firmware changes for it to also receive input, which could be wired up to evaluate TTscript like in live mode. You would still need to figure out what to do about editing scripts / patterns / etc but this seems like a pretty attractive option to me.

2 Likes
#390

I have a branch that emulates the screen, but I haven’t done the keyboard yet. And it feels out of order to get teletype working before the trilogy modules are perfectly bug-free. (EDIT: but it’s super tempting!)

5 Likes
#391

Is this what I think it is: more than 8 scripts in the teletype? If so I’m extremely excited! Is there a hex or a diff for this available?

1 Like
#392

Yes, I increased mine to 12 scripts (they show up as A, B, C, D).

The notes I posted are your best bet, my local sources are … unique. :smiley:

1 Like
Teletype 3.2+ feature requests and discussions
#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!