#121

thanks, good to know #1 is doable. definitely would make for more interesting conditions and combinations.

re: #2 - was mostly curious what would happen if two scripts had loops with different delays in them… and what happens if a trigger arrives when the script is delayed?

edit: maybe the right question to ask is - when a command is delayed, does it delay the whole script or just the command?

#122

using interrupts provides much tighter execution timing (currently implemented) though i may move over to something closer to what you’re suggesting if the system feels too unruly.

#123

there are certainly design decisions to be made about ES sync. a hard reset, in my opinion, is a pretty big start.

anything more requires a sort of modality that may make using earthsea more confusing. ie, a message ES.SYNCEXT to switch ES between internal and “external” and then an ES.SYNC message to advance the pattern. i could add this easily for v1, but i need to think over the best solution.

i might be able to add this for v1.

just the single line is delayed. hence you can do:

DEL 500 : TR.PULSE A
DEL 600 : TR.PULSE B
DEL 700 : TR.PULSE C

in a single script, for a strum

2 Likes
#124

if i were running 3 triggers outs with one pulse, is there a way to control muting of the outs to create different patterns?

it seems pretty clear that delays/shifts are doable
not sure about mutes (outside of WW) based on the docs

#125

you could implement “mutes” with an IF

IF X : TR.PULSE 1

here TR.PULSE would only execute if X is not zero. so elsewhere you can set X as the “mute”

1 Like
#126

module depth for both Teletype and Walk:

26mm

2 Likes
#127

If a deeper SYNC for ES can be added, as you say “simply” to v.1 I would definitely encourage that!

There was a thread in the old forum where we discussed a variety of approaches to sync in ES. I linked and provided a brief outline in this thread:

Bottom line is that given the various “modes” that Es operates in, the clock implementation might vary. Being able to sync start of the pattern seems easiets. But I would also suggest that the “linearized” mode is the most obvious ES function that could be hugely affected by external clock. Not only in terms of much tighter integration with other clocked events innthe system, but maybe especially in terms of the user ability to actually control the tempo of playback. As it is now, we can only double or half the speed, which is very limiting.

#128

now I’m thinking:

IF X : TR.PULSE 1
IF Y : TR.PULSE 2
IF Z : TR.PULSE 3
1 TR.PULSE 1 Y Z 0
2 TR.PULSE 2 X Z 0
3 TR.PULSE 3 X Y 0

would that script allow me to feed 3 triggers to teletype and output 3 that mute each other when firing? I might have the concept or syntax wrong for this…

#129

syntax isn’t quite right, but i think i understand what you’re trying to do. just keep in mind, when do the mutes turn off (by setting x,y,z back to 1).

we’re very quickly going to have to figure a nomenclature for documenting multi-input, multi-line scripts.

1
IF X : TR.PULSE A
Y EZ Y

2
IF Y : TR.PULSE B
X EZ X

EZ is equals zero. so X EZ X toggles x between 0 and 1. (if x is 0, then it becomes one, and vice versa, each time this is called).

so the two scripts above, together, have a toggling mute effect on eachother. with a polyrhythm input to each, this could/would sound interesting for sure.

#130

i’ve got to say, i know you said the main purpose of TT is not replicating something that is better done elsewhere in the modular, but i think one of TT’s main benefits is being able to quickly and easily add something required in a patch.

there are reprogrammable modules already but TT fills the niche where you have something that can play many roles but can be configured easily while in the middle of a patch without having to flash the firmware. so it’ll be a great module for smaller systems too.

can easily turn it into logic, flip flop, trigger delay, comparator, sample and hold, shift register, envelop, random, slewed random etc etc with one or two lines.

assuming all of the inputs and outputs are not busy doing something more interesting which will likely be the case! :smile:

2 Likes
#131

precisely. i haven’t been pushing this too hard, because i know how few people actually firmware-flip their gear (like you have been!)

1 Like
#132

good point

I was thinking about this…how do you think a shift register could be implemented within this language?

#133

it’s funny how fast it becomes when you do it all the time - sometimes i do it just to test something quickly, the whole procedure takes me 30 seconds now.

does make me wish for another version of Switch which would also have a separate power button for WW itself :smile:

#134

something like this?

Z Y
Y X
X IN

CV 1 X
CV 2 Y
CV 3 Z
1 Like
#135

sorry I missed EZ among the logic commands

that makes perfect sense . thanks for the tips

#136

You could ASR (shift register) the Input CV when triggered by a sequencer, ie. from a sequencer that sends a gate/trigger at the same time as a new note:

CV 1 X
CV 2 Y
CV 3 Z
X Y
Y Z
Z IN

This outputs the 3 previously sampled CV values to the first 3 CV outputs, and then shifts everything one place in the register, finally grabbing the new Input value and putting it into the register.

3 Likes
> teletype : code exchange
#137

kind of nuts how simple that is

thank you ( @Galapagoose too)

1 Like
#138

indeed! (sorry - should’ve provided explanation together with the code!)

#139

I was writing up how the pattern system is so flexible for a post elsewhere and made me realize you can do many more interesting shift-register effects using the pattern system. This would allow you up to 64 steps of ASR with 4 indepedent ‘taps’ throughout the buffer. You probably won’t ever want to use more than a handful, but I imagine some interesting patterns would be revealed with an ASR that accessed non-sequential positions in the ASR – I remember doing some things like this on the Aleph with the HISTORY op, but never got beyond a proof-of-concept.

Of course the nice thing here is the ‘index’ at which you were grabbing data from the register could change as the result of events, and the output need not be linked to the input so you could output the value asynchronously to the sampling of new values.

Anddddddd, to push the idea even further it could make an interesting arpeggiator. WW could provide CV & trigger data to the IN and Trig1 which would sample the new value into the Pattern. Applying a second trigger input that is faster than the input could then step through the pattern each tick, being restarted at the newest material whenever a new Trig1 occurs. Thus you would build arpeggiators out of the most recently sampled notes, which of course need not be sequential either.

Perhaps this post shows you how difficult it is to express just how capable this device is without falling down the rabbit hole of ‘how far can we push this’…

5 Likes
#140

this makes me think teletype would make a great tool for learning/teaching synth techniques

somehow this 6 lines with variable shorthand was easier to grasp than pages I’d read about ASRs (eg. snazzy fx telephone game)