Teletype v2 proposals

well, long highway stretches are a good environment for systems design i seems.

here are a few feature additions i’d like to add to teletype for a version 2 marker. rather than hide away and spring the finished product on you all, i think it’d be good to propose the changes and get some feedback, given there’s a community of users that “get it” now. please make suggestions and recommendations!

1. TIMELINE (TL)

a linear script system, sortof like csound scores. which i admit, i have no experience with, so please chime in with use cases that have already been addressed and solved that i’m overlooking.

this functionality would add a linear “score” of commands, that can be non-linearly executed with other teletype commands.

this would entail making another editor screen, like METRO, but may need more interactivity. each line would have an index or time marker. sequential lines can have the same time. ie:

1 TR.PULSE A
1 TR.PULSE B
2 TR.PULSE A
4 TR.PULSE A
10 TR.PULSE A

of course add more interesting commands. i hope this buffer can be very long with many many events.

TL gets/sets the timeline position.
TL.NOW executes the current position.
TL.NEXT adds one to the position and executes.
TL.START sets the start position (for control by TL.NEXT)
TL.END sets the end position

  • there can be unpopulated index positions, ie instances where TL.NOW will do nothing.
  • i like the idea of there not being a hard limit to how many commands can be on one index.
  • the editor should facilitate “insert” commands where later indexes will be incremented and smart “delete” where following indexes are decremented, etc

2. AUTOTRIG

there have been requests for more metro scripts, and i think this is a good idea. however, tracking them and making more screens would clutter the interface. this is one solution.

each trigger input 1-8 would have an additional “autotrigger” functionality.

AT.ACT x y would activate/deactivate autotrig on channel input x (y=1 on, y=0 off)
AT.TIME x y sets the interval time of channel x to y
AT.COUNT x y sets how many repeats (0 = infinite repeat)
AT x would trigger channel x (this seems redundant with SCRIPT)

so. for example, activate autotrig on channel 1. set time to 500 (ms). set count to 0. go AT 1 and suddenly you have another metro that executes script 1 at its own rate.

another use: script echo. set count to 4. remote trigger inputs (via patch cable) will also trigger the AT. retrigger resets count.

external trigger also resets the per-trigger metro counter (as does another AT command).

2b. INPUT.TIME

maybe? automatically measure the interval between incoming trigger inputs and store it. very little overhead and means there will be less scripting, preserving the usefulness of 6 line scripts.

3. MIDI

it’s very easy to get MIDI input via USB. of course, this means not having a keyboard plugged in, so much swapping would be required. (the alternative approach here is an tt-extension where this functionality is over II)

three new “events” (ie metro, trigger, etc): NOTE-ON, NOTE-OFF, and CC

with a note-on event, a pre-determined variable NOTE (or whatever) is set, and then this script does whatever with that information. same with off, and with cc.

basically just associating scripts with incoming midi events. and then TT becomes a crazy flexible midi processor.

4. bi-directional II

ie. normal MP triggers to script inputs, get WW position, etc


i’m not presenting use cases here but there are a ton. please let me know if you see any possible improvements.

12 Likes

Regarding the MIDI… I did have an idea for being able to simultaneously connect multiple USB devices to a module (and get round the USB OTG limitations)… the basic idea would be to use a 3rd party device (e.g. Raspbery PI / Beaglebone Black / etc) to multiplex the devices into a single USB stream.

If you’re interested I could try and go in to a bit more detail about potential implementations, it would be a bit of a big undertaking to get it to work, certainly more time than I have free. I’m also a bit worried about how elegant it would be…

1 Like

well, that would be a hub. i don’t see any way to have different classes of devices transparently ‘merge’ their streams otherwise.

i guess your external box could be running linux and using libusb to do your hub+device management, then, i dunno, convert midi input to some kind of serial protocol and put it in the serial stream. is that what you had in mind? would work but be pretty weird! (kind of fun, though.)

we’ve discussed hub support for TT/aleph a lot in various places, and why it’s theoretically feasible but practically quite tricky. if it were me i would probably have to spend some full-time weeks poring over the USB specs and building it from scratch; it’s not a weekend-friendly project. someone with prior deep knowledge of USB drivers would have an easier time.

would love it if anyone could point me at a working 3rd-party, baremetal library that provides host-side hub support (not device-side.) LUFA and the Atmel Software Framework don’t.

1 Like

I don’t get how the timeline would work,
But the whole AT thing seduces me. It would be so handy. The INPUT.TIME would be awesome for many clock applications. I’d use INPUT.TIME 1-8.
The MIDI input opens a whole new world of controls.

Yeah, I should have mentioned it would be for a finite number of configurations, e.g. grid + arc + midi + keyboard. Sorry!

One of the options was a custom serial protocol, or maybe extending SERIALOSC to include MIDI and keyboard support, possibly encapsulated with a device ID. You’ve then got the option of being able to route those messages (e.g. over ethernet, say trigger a teletype script via OSC, or even have a script send some OSC). If you wanted to go to an even bigger extreme, you could connect all your modules (+Aleph) and devices to the same box and use a matrix to dynamically control what is connected to what (a grid would be perfect for this).

The other option, would be to try and map the endpoints directly. AFAIK the AVR32 USB code only supports one device, but will support multiple endpoints. This option is way outside of my comfort zone. (You’ve also got things like the BeagleBone Black which has a USB device port +gadgetfs kernel mods.)

One of the advantages of going with the custom serial protocol is that it doesn’t involve getting down and dirty with low level USB, which means mediocre programmers like myself can chip in with bug fixes and features, even if it feels kinda daft to add on a full blown general purpose computer + OS to act as a peripheral to your MCU.

The other option is not to bother at all! I’m kind of sympathetic to this, it gets too complex, part of me feels that the sum of it will be less that of the parts. On the other hand it would be cool to be able to edit pattern data with a grid and an arc.

This of any use?
https://developer.mbed.org/handbook/USBHost
https://developer.mbed.org/users/mbed_official/code/USBHost/

2 Likes

The timeline stuff seems really really cool but maybe not just as a timeline…

Would you be able to add direct execution of a time? E.g. TR.EXEC t, because now I can treat it as a function table… maybe something along the lines of:

TIMELINE

0 X ADD X 5
5 X SUB X 3
10 X 0

SCRIPT 1

TR.EXEC RAND 10
CV A N X

As an aside, I’d probably add an OP in a private branch for my own use to treat the time as a probability. Maybe something like TR.EXECF t (execute the first time after t), then in the example above you could guarantee that one of the instructions runs… I’ve been thinking about Markov chains recently…

The other slightly out-there idea, would be to allow code to change the times, e.g. TL.MAP t1 t2 changes all the commands at t1 to t2. Also maybe TL.SWAP t1 t2

1 Like

… mm, ‘mbed’ is not too directly useful, for TT/aleph/monome mods. looks like it is squarely targeted at cortex-m3 and maybe -m4 and built on their own HAL.

what we need is the resources for someone to work full-time for, i dunno, 2-8 weeks, and solve this dumb problem once and for all, for everyone, forever. given that you have the ability to parse USB endpoints (which we do) there’s no reason not to be able to parse hubs + forwarding, except for a (frankly) shitload of testing and careful examination of all the ways it could go sideways. its just not something anyone i know can do in their spare time.

The other option, would be to try and map the endpoints directly. AFAIK the AVR32 USB code only supports one device, but will support multiple endpoints.

yeah, that sounds tricky. i mean it’s what a hub does anyways. i guess if you assume that all the endpoints are the same class it becomes starightforward; but what’s the point really? might as well go back to the idea of converting every possbile I/O to a custom serial representation… this sounds more than a little crazy, but honesty it is IMO the path of least resistance, if all you want is to hook up to a MIID device + monome grid + arc + etc…

Input time, would that store the last interval? The mean interval?

USB is a pain, even if you’ve got the resources. The Raspberry Pi has the same USB OTG + software full stack solution that you’re talking about and they had loads of problems getting it right. It was very buggy at first.

There is also this: https://github.com/Chadderz121/csud (and here)

1 Like

yes yes yes!

huge potential in all of them… for myself though, MIDI IN would be specially appealing,
but: is that planned to be monophonic as I suspect?
being able to read individual notes from a polyphonic midi channel would be a huge tt game changer IMO.

thanks for the links, looks promising. lots to digest. will add to the github issue tracker and stop hijacking this thread.

1 Like

A lot of great ideas here!

Some design thoughts:
-I really like the idea of the Autotrigger functionality. My primary concern is in the amount of syntax required for an AT script vs the number of lines available per script. The operators (ACT TIME COUNT) make sense (although I might change ACT to SET), but it would eat up half of a script to setup Autotrigger functionality for another.

-MIDI over USB is cool, but I agree that there would be a ton of hotswapping (Does this work? Nope, unplug, go back to QWERTY, type again, test again, revise, revise, revise). MIDI over II via expander is especially interesting though. Instant ideas:

  1. The module could have its own basic MIDI output jacks, like GATE, NOTE, CLOCK, and CC. CC could be set in Teletype live mode via an operator. Without TT, it would be set to a sensible default.
  2. It could additionally act as a MIDI over USB output for other trilogy modules. For instance, I would love to use White Whale and Earthsea as MIDI generators. I’m not sure how feasible that is over II, but it would certainly be a great feature.
  3. It could have a barrel power cable input that could daisy chain off of the existing Switch module. That could help reduce power consumption of thirsty external controllers.

-I haven’t taken a look at the technical details of the Teletype hardware, but is it feasible to add a basic smooth LFO or envelope as operators? Currently, I’ve been making heavy use of the 4MS Quad Pingable LFO module as a Teletype partner, as it gives me four synced modulations for Teletype’s four trigger/gate outputs. I suppose that patterns work as a stand-in though, so it isn’t critical. I just imagine cool things like attaching an internal LFO to AT’s TIME parameter to expand and contract internal bursts of a script.

I agree that AT x seems somewhat redundant in light of SCRIPT, so what about the idea of using AT as a single line setter/activator, as in
AT 1 500 0 – enable autotrig on channel 1 with 500ms and infinite repeats?

I can certainly still see using ACT, TIME, and COUNT as individual commands to set or alter a running autotrig, but in any cases where you want less than infinite repeats AT would be a real space-saver. Not only that, but it should theoretically also enable us to combine autotrigger with PREs, no?

I’m imagining something like:
L 1 4 : AT I DIV 500 I 4
or
IF a : AT 1 500 0

1 Like

One feature request…
I know that bi-directional II hasn’t been implemented yet, but if it’s in the works, I would love a command to immediately normal MP’s 8 outputs to TT’s inputs.

A fun idea would be
II MP.NORMAL 1 1 (normal MP 1 output to TT 1 input)
II MP.NORMAL 2 5 (normal MP 2 to TT 5)
II MP.NORMALALL 1 (normal all 8 outs to respective ins, NORMALL is a punny option)
II MP.NORMALALL 0 (turn off normals)
II WW.NORMAL 1 1 (normal WW 1 output to TT 1 input)

etc. etc.

It would save me a ton of patching, since I’m almost always using MP for all of TT. In addition to patching time, it would help stop a cable forest from sprouting up in front of my sequencing block.

One other question… Am I missing an option to sync MP and WW clock inputs to a TT script? I see that ES has a .MODE and .CLOCK option which I’ve been using, but I don’t see something similar for MP and WW.

1 Like

absolutely, first feature once bi-dir II is in. ww/es clocks similarly could be added, though it seems identical to just patching a TR to the clock-in (i realize the advantage of saving a TR output). but easy enough.

one issue is that the address-space for the II commands is quickly getting exhausted-- we should perhaps restructure this to allow many many more messages. @scanner_darkly

2 Likes

i’m really into both of these ideas!

yeah, would be good to expand the address space for the remote commands! i could easily add a bunch more to orca…

a lot of great ideas here - need to find the time to reply with more thoughts!

1 Like

One use case advantage of having MP and WW CLOCK commands is that you can trigger the clock from multiple scripts instead of needing an OR combiner.

While on the issue of cleaning up the address space, a useful address would be II ALL.*, where all receivers on the II bus could receive a message. With the various CLOCK destinations, you could use one line to sync the entire trilogy to Teletype. (i.e. II ALL.CLOCK 1)

2 Likes

good idea, i’d also add II ALL.RESET

3 Likes