#15

And Crow talks MIDI, right? (I’m still playing the same tune)

#16

Hmmm… I wonder if this could be relaxed for SCRIPT calls at the last line of a script? This would essentially allow tail recursion to be treated like a simple loop since presumably context would then not need to be preserved?

#17

What’s the closest thing we have to a “getting started with teletype firmware development for dummies” guide?

3 Likes
#18

Actually, Crow doesn’t EXACTLY talk MIDI, while it’s in there it’s not fully optimized or ready for prime time.

If you look, there’s actually some basic MIDI implementation by the TT at the moment. It’s not in the firmwares, but @scanner_darkly got some cool examples up here somewhere on lines.

The main issue was getting MIDI out to work right. Midi in was getting some cool examples. If I remember, it was dropped because MIDI protocol wasn’t Scanner’s number one comfort zone. I also recall someone briefly mentioning that they’d take a bit of a stab at it.

If anything, this is eventually on its way, maybe not today or tomorrow, but given the recent open source of the TT, SOMEONE will take up the mantle!

Also, @scanner_darkly, if I’m off, please, correct me! I just remember seeing most of this when I was looking through old threads a month or two ago.

#19

Some useful information on how to get set up to build is in the README.md in the repo. Most other stuff I think is just kind of getting familiar with the code structure, though that file does sketch how to add an op. Discussions on lines I think largely tend to be geared towards specific deep-in-the-weeds technical topics or revolve around feature development.

2 Likes
#20

it would still not prevent an infinite loop which is the main reason to only allow limited recursion (originally teletype didn’t allow recursion at all iirc). but in most cases you shouldn’t need recursion (you could just have one main script, like metro, calling others as many times as needed) - is there a particular use case you’re thinking about?

it wasn’t MIDI (which is simple), it’s the USB spec (gory details here). but yeah it was sending MIDI that didn’t work fully. receiving MIDI was fine and i’m planning to revisit it (no promises though, it’s possible it won’t fully work either - needs to be tested with various devices etc). here is the main thread on: Teletype and MIDI

1 Like
#21

yeah as @csboling mentions, take a look at the readme. once you have the toolchain set up and can build firmware, take a look at any pull request that added an op - it should give an idea of what’s involved.

for code structure take a look at this: Teletype firmware discussion

1 Like
#22

Yes, I think in practice this is a good thing to avoid (I’ve been burned a bit by accidentally having a while loop that didn’t terminate properly and made the device very difficult to use temporarily :slight_smile: ). I was mainly thinking about @synthetivv’s original query, but probably not worth the extra headache of finding an alternative way to avoid infinite loops.

1 Like
#23

yeah i think it’s a use case that would be better solved with a dedicated op!

1 Like
#24

TT wouldn’t have to save anything if the call out the script was the last statement, because there is no reason to return to a script that is ending!

#25

If I’ve understood correctly, the reason TT saves the current/prior state when SCRIPT is partly in order to keep track of and limit the number of levels of recursion – the assumption being that if you’ve caused an infinite loop, you probably didn’t mean to, which is probably true most of the time.

Part of me that likes the idea of adding something like the exec builtin in Bash, that would replace the current state (what the TT code seems to refer to as an exec_state) instead of pushing a new state onto the stack, but there’s another part of me that appreciates TT protecting itself when it thinks it might crash.

Also, it looks like a new exec state gets pushed onto the stack any time DEL'd commands are run, so even with something like an EXEC op, the best case scenario would be twice as many recursive delayed executions before TT quit.

2 Likes
#26

there are several reasons for preserving a script context, such as preserving I variable:

i think when @sliderule implemented it, it also allowed to check recursion easily, since we need to push the execution stack and we have to make sure we don’t exceed the max stack size. it also means that avoiding infinite loops is just one reason, the other reason is the limited stack size. we could increase it but we still need to select some max number.

we could add a way to call a script without storing the context - but this feels like it’s becoming a very special use case with some unclear ramifications. if we considered it, i wouldn’t do it based on where you call a script (what if you do want to preserve context even when calling from the last line?) but having a dedicated op. but again, this feels like a pretty special case*, and we would still need to prevent infinite loops somehow.

also looking at the code, i think we also need to preserve J and K variables as part of execution context.

* well, and maybe it isn’t such a special case after all, it could be useful to be able to jump to another script without returning to the calling script, so you wouldn’t need to do something like SCRIPT 5; BREAK to replicate that. the op could be SCRIPT! / $! similar to M! to signify you’re doing something potentially risky.

#27

Is there a to-do list for features which become definitely true in the near future and a list of loose ideas of prio 2?
Would be nice to see this “hack” become officially implemented:

#28

no such list other than the discussion threads (some feature requests are logged as github issues but there are many that weren’t). and it really depends on what the developers choose to work on.

#29

posted a new build 71E469F which includes:

generic i2c ops are intended to allow interacting with i2c enabled devices that don’t have dedicated ops or before dedicated ops are added (like crow).

@eremitalf - could you test it with ADDAC 221? you will need to place IIA 52 in your init script and then you can read values with IIQ port where port is 0…63.

@csboling @discohead and other devs who want to work on teletype - to make it easier to collaborate i think probably makes sense to do pull requests and merge to master, and post builds from that? alternatively, we could perhaps create a separate shared dev branch?

7 Likes
#30

Thanks @scanner_darkly. All seems to work perfectly well between the ADDAC221 and teletype with the new ops. However the signals do not reach the ER301 now. They did with your previous firmware. Any ideas what that might be?

#31

there should be no change to any of the dedicated i2c ops. can you post your script?

#32

Just left the modular but I had the M script doing this:

L 1 8: SC.CV I IIQ I

No signal reached any of the SC.CV ports on the ER301.

I switched back to the previous firmware and the FB op and it worked again. Hope it helps!

#33

Could it be that, like the FB op, the SC.CV unit uses ports 1-64?

#34

no, SC.CV accepts 1…300 (up to 3 units each with 100 ports).

i don’t see anything wrong with the script other than you need to offset port value for IIQ as it’s 0-based unlike FB which is 1-based: L 1 8: SC.CV I IIQ - I 1

does it work if you execute SC.CV manually from live mode using the latest firmware?