#372

Yeah, aliases all run the same code as the longer op names.

1 Like
#373

Thank you for the update!

Adding a search to help mode makes it much more useful!

I was just able to get it to crash with the following steps though:

  1. press alt-h to go into help mode
  2. ctrl-f and search for ā€˜patternā€™
  3. hit enter 4 times
  4. see ā€˜pattern: not foundā€™
  5. ctrl-r
  6. hit enter 4 times
1 Like
#374

Thanks for catching this - edited the post with a fix (6ddf2c7).

1 Like
#375

A couple of lines in the help file (I donā€™t recall where, just scroll down through them on Teletype and you will see it) are too long and wrap over, corrupting the text and (I think) causing some crashes for me a while back. I fixed this, added four more scripts per scene, and four more patterns in my own local branch.

1 Like
#376

Just confirming that the checksum for your firmware update is: BE59343-DIRTY

Is this correct?

#377

Yeah, thatā€™s what mine shows too. Odd because thatā€™s a couple commits ago. This is the right firmware though - search bug reported above is fixed. Must still be something mucked up with my build process.

2 Likes
#378

Care to share your branch? :upside_down_face:

1 Like
#379

My local files are a little messy since Iā€™ve been deleting stuff I donā€™t use in a wholesale way!

But these are my notes and should get you there for the four extra scripts, have fun!

To update number of scripts

/src/state.h line 25
#define SCRIPT_COUNT XXX

/src/turtle.h line 33 and following
--> insert script(s) into the enum, they must come before metro and init

/module/edit_mode.c line 403 and following
--> insert prefix letter into exception list

/src/ops/controlflow.c line 245
    if (a > <last callable script number from turtle.h enum> || a < TT_SCRIPT_1) {

/src/ops/controlflow.c line 245
    if (a > <last callable script number from turtle.h enum> || a < TT_SCRIPT_1) {

/src/ops/controlflow.c line 274
        if (s >= TT_SCRIPT_1 && s <= <last callable script number from turtle.h enum>) {

/module/usb_disk_mode.c line 128
--> add else if case for new script and increment succeeding numbers for e.g. pattern and grid

/module/usb_disk_mode.c line 268
--> add else if case for new script and increment succeeding numbers for e.g. pattern and grid

/module/usb_disk_mode.c  about line 268
                        // SCRIPTS
                        else if (s >= 0 && s <= 13) {
--> adjust to match script count

/module/usb_disk_mode.c  about line 361
                        // PATTERNS
                        // tele_patterns[]. l wrap start end v[64]
                        else if (s == 14) {
--> adjust to agree with number of scripts plus one

/module/usb_disk_mode.c  about line 411
                        // GRID
                        else if (s == 15) {
--> adjust to be one more than the patterns index
2 Likes
#380

This is awesome and totally in line with my plan to finally delve into some firmware hacking. Probably not a good place to start, but with this guidanceā€¦

Thank you very much!

Ah one question: was 4 dictated by available ram?
(sorry for asking without knowing any numbers, was just immediately curiousā€¦ I believe additional 4 is a perfect number for my usage anyways)

1 Like
#381

You might be able to add one more script. The compiler will complain if you run out of space.

I was able to add four more patterns too, but I havenā€™t tested it on the module (i.e. it compiled OK and thatā€™s it) and I donā€™t have a UI to scroll sideways. I probably wonā€™t address the UI since it suits my purposes to have some extra 64 element arrays with helper functions.

1 Like
#382

I loaded 6ddf2c7. The new search feature is ace! The only thing I noticed around lingering display issues on the help screens is on page 3, second line from the bottom, SCENE.G has some extra pixels lit in front of it which I assume is the closing parenthesis wrapping around? Doesnā€™t make it unreadable or anything but in case youā€™re nit-picking it.

Also tested calling SCRIPT 9 and SCRIPT 10 and they seem to work exactly as expected, even with metro running. SCRIPT 9 just seems to call it an extra time without interrupting metroā€™s regular calls. I assume the intention here is for grid intensive projects? Do all of your grid setup in one scene, call another with SCENE.G, and have an extra 1-2 scripts for code?

Thanks for the new goodies!

2 Likes
#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