#383

I haven’t seen much chatter about teletype communicating with crow yet—then again I am a novice in the ways of ctrl+f. It doesnt seem like Druid has any set of instructions for communicating i2c with teletype yet.
Anyone messed with making OPs for crow yet? I’m tempted to open the hood but I am still grokking TT’s language and know it’s going to be a different world once I start messing with libavr :hammer_and_wrench: still going down the rabbit hole anyhow

#384

There is an issue with some info on proposed ways for TT to talk to Crow, e.g. changing outputs, or even ops to call some arbitrary bit of Lua code. Should be a lot of fun if you’re up for firmware development! I was gonna work on this but got a bit sidetracked with some Druid ideas. Personally I use this Dockerfile to manage the build environment.

6 Likes
#386

So I noticed something odd while having my faderbank, just friends and teletype all on the same powered i2c bus. My TT would freeze consistently while trying to use commands for JF. I could not figure out what was going on because it was all working flawless until this evening.

So, re-flashed the beta firmware on TT. Re-flashed the current firmware on JF, removed everything from the i2c bus and tested it out again. Still freezing. I would test by changing between JF.MODE 1 and JF.MODE 0. Changing from one to another would work, but it would freeze every time I would try and change it back.

I thought I had everything disconnected from the i2c bus, BUT, my faderbank stereo jack was still connected (from the jack on the faderbank to the stereo jack on the back of my case then from that jack to the I2c bus with an I2c cable). I disconnected it from the i2c board and everything was working as expected again.

I plugged it back in to see if that was the issue by re-attached the 3pin female headers to the i2c board. Sure enough it was freezing again. What struck my as odd was this only happened when no power was going to the faderbank. If I had it powered up, it would not cause the freezing issues I was having earlier. If I left it unpowered, TT would continually freeze if connected to the i2c bus.

My faderbank is in follower mode with the 1.33 firmware (1.34 is current, but it only seemed to include an update for running in leader mode IIRC?)

Any thoughts on whats going on here? Should I just make sure I have my faderbank powered, or not connected at all with i2c if I am not using it? Is this even a teletype issue?

#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…