#61

correct.

this makes for really easy s&h scripts, etc. i haven’t even gotten around to exploring this stuff yet.

#62

especially with the remote commands, CV-able preset selection.

would be awesome to also have remote variables, so, say, read current A and B values from ww etc etc. then you could use ww / es / mp as controllers for teletype.

1 Like
#63

Makes sense. Though one could say that making the self incrementing variable (O) is just as easy…
Single character standing for a certain type of consistent behavior is just attractive to me.

In any case: lot’s of possibilities to be sure!

#64

i’m trying to read the whole thread (so apologies if this was covered)

teletype remote controlling earthsea (or WW or MP) sans grid…possible? or is that not even worth trying

#65

Looks that way based on just ammended documentation:

8. remote

II WW.POS 5
sets position to 5 on the white whale.

WW_PRESET
WW_POS
WW_SYNC
WW_START
WW_END
WW_PMODE
WW_PATTERN
WW_QPATTERN WW_MUTE1
WW_MUTE2
WW_MUTE3
WW_MUTE4
WW_MUTEA
WW_MUTEB

MP_PRESET
MP_RESET
MP_SYNC

ES_PRESET
ES_RESET
ES_PATTERN
ES_TRANS
ES_STOP
ES_SH1
ES_SH2
ES_SH3
ES_SH4

#66

oh absolutely.

particularly useful for sync’d recall of presets on MP/WW/ES all at once, where you can only have one grid plugged in (unless you’ve got a pile of grids)

1 Like
#67

yes there’s a fine balance in the design-- too many opaque functions make for a steeper learning curve.

ie, i’m really considering abbreviating RAND to R. but after a bunch of this, suddenly we’re reading a series of single letters and everything is, well, impossible to approach by the newcomer.

#68

I totally agree in terms of this being the “language” used: too cryptic and it becomes disfunctional.
My thoughts were specifically about variables, not so much reducing the whole language to single character alphabet soup :slight_smile:

#69

@tehn - so the remote interfacing - is it one way only (from teletype to remote) or will it also be possible to read from remote as variables?

#70

ok

resistance was futile
i’m sold

#71

I need to sell some modules to make space. Monome skiff here I come!

1 Like
#72

i haven’t implemented this, but have considered it for a v2.0 feature. i’m conscious of overbuilding, and would like to choose features based on perceived need after we get some units out in the wild.

#73

awesome - i was afraid the hardware wasn’t set up for that.

some of it would be possible with the actual physical patching but it would be interesting to have virtual patching between all the modules with the ability to store and recall.

#74

So cool :deadbanana:

#75

@tehn - another question for you: is Q a global buffer or do we get a buffer per input?

#76

I’m in love and I don’t care who knows about it.

1 Like
#77

my thoughts exactly, would be good to have some accurate module depth measurements to start planning :wink:

1 Like
#78

why not allow both options?

1 Like
#79

I believe it’s a global Q - really interesting to have a number of inputs add commands to the queue, then have a ‘quantized’ trigger (or internal METRO) fire them all off. Not sure how per-script Q would work, and using DEL (delay) allows you to defer messages on a per-script level.

#80

Depth is no more than 30mm or perhaps a touch more with the II cable attached. Teletype is more shallow than the ‘trilogy’ modules, so very skiff friendly. MP & WALK & TELETYPE will be a fantastic algorithmic composition & performance environment, and coupled with a few interesting audio modules it will be a pretty flexible little system.