#101

IN and PARAM can be read independently.

ie. `CV 1 N DIV PARAM 1024’

param/in are 14 bit inputs so dividing by 1024 scales the knob to 0-16

also— here’s the keyboard.

46dcc14950904ea3af0485e216d0964bf2c2bfc3.jpg900×600 428 KB

1 Like
#102

not yet discussed really: teletype has an internal “metronome” script so self-triggering is very straightforward.

going into EDIT mode, moving through the scripts (1-8) will eventually get you to M. this is the metro script, which is executed on an interval. default time is 1000ms.

you can change this time directly:

M 500

to 500ms via LIVE mode (or another script.)

the metro can be completely disabled/enabled with

M.ACT 1

where 1 enabled, 0 disables.

consider a script (on an arbitrary trigger input) that modulates the metro:

M ADD M 10

this adds 10ms to the metro time, slowing it down. you could have another script elsewhere setting it back to the original speed.

or

M DIV PARAM RRAND 1 8

this sets the metro time to the param knob, divided by a random number between 1 and 8. with a line or two more, we could have the metro repeat a fixed number of “beats” and then re-calculate its time division.

ok… i should work on the docs.

3 Likes
#103

The doc says “A-D is mapped to 1-4” - not sure what it means? So either notation can be used and the actual output is determined by whether it’s a trigger or CV that is assigned?

The event stack is such a powerful idea. A fun patch would be having several triggers push different events into the stack and then have one trigger execute everything in the stack.

Agree that Pressure Points will make a good buddy for TT, individual gate outs to trigger ins, and common pressure out to CV in. Softwire Octal Switch would also make for a good pairing with 4 latching and 4 momentary switches.

#104

A-D are simply variables whose initialized values are 1,2,3,4. you’re perfectly fine addressing TR with 1-4 instead of A-D. and then use A-D as general purpose variables. apologies for the unfinished docs.

#105

thanks Brian, and thank you for sharing the docs early, it’s all making more sense now that the concepts behind the language are becoming more clear. So this is exciting - means I could use a variable to select the actual trigger?

A RRAND 1 4
TR A

#106

Just want to second the sentiment: really great to have a chance to read through (and discuss) the general scope of the functionality and language involved.
My mind is certainly spinning with ideas.

#107

I realize this is getting ahead of myself… How hard would it be to fashion a 2hp breakout panel allowing the i2c bus to be extended to the aleph?

teletype looks amazing, it brings back fond memories of tinkering with an actual teletype. the command stack opens up a different dimension entirely.

Aleph ii / i2c Dev
#108

“How hard?”, not very. It’s literally a 6pin (2x3) header connected to a stereo audio jack. The hard part is certainly the software side of things, the most pressing of which is determining use cases. Certainly getting ahead of monome, if not yourself…

#109

Those commands work perfectly fine, and perhaps is most interesting having each line triggered on a different script (eg. In1 triggers X RRAND 1 4, while In2 sends a random state to the selected out TR X TOSS). I use ‘X’ in the example as it’s a ‘general purpose’ variable (ie it doesn’t have a predefined state at load, or rather initializes to 0). Variables are just numbers hidden behind a facade.

Note that you can smash the above into a single command:
TR RRAND 1 4 TOSS

Which avoids the need for a variable at all. RRAND 1 4 chooses which trigger to set with the result of a coin TOSS.

1 Like
#110

Good to know - my suspicion was that the software is where 99% of the work lies (now back to tinkering with firmware as my mind wanders).

#111

i actually had i2c working on the aleph at some point, but the code got trashed somewhere.

an ii bees operator should be straightforward, particularly with the code from teletype, which uses nearly an identical avr32 chip.

breakout panel with i2c-- neat idea, though dangerous if using just a stereo mini jack-- throwing 10v accidentally into the i2c would be bad.

#112

this is an interesting other idea, though. if you have scripts also manipulating TR A, and A changes, then the other scripts change “focus” to a different TR out jack.

like how P.N selects which pattern to work with.

ie

P.N 2
P.NEXT
P.N 0
P.NEXT

here we shift to pattern 2, output the next value, then shift to pattern 0, output the next value.

1 Like
#113

this brings up a question - what happens when 2 or more triggers happen at the same time? i imagine scripts are always evaluated starting from #1, so if #1 and #2 happen at the same time #1 gets executed first, and #2 next?

say, if both modify the same variable or use same outputs?

1 Like
#114

this is a purely electrical issue. there is going to be a race condition, if using the same trigger out (from whatever) to two inputs. the result will be undeterminable. (this is speculation based on theory, i should test this.)

1 Like
#115

cant explain how excited i’m getting about walk
(specifically two walks…and the four corresponding pedals) fed into teletype

so many fun rhythmic/mixing games possible

1 Like
#116

interesting! I thought there was one timer based event handler that scanned all trigger inputs in specific order but sounds like they all have individual interrupts. this would be an interesting way to add more randomness.

#117

Duh, transpose not transport. Wishful thinking I guess. Anyway, this ^^^ with this vvvv

seems like an interesting combo to sync instead of sending a clock to one of the TT trigger ins to sync ES. Or could measure the time between two trigger ins to use to set internal metronome to sync ES, so as tempo changed ES would stay synced - or at least the pattern would trigger on the downbeat. If only you could adjust the speed other than by a factor of 2, you could really sync the pattern regardless of length or congruence with time signature.

So really, we can only sync the beginning of the ES pattern, we still can’t actually synchronize the tempo of the ES pattern with the tempo of anything else, which is really what I think a lot of us were hoping to be able to do. Well maybe with carefully placed STOP and…wait, is there not ES_START? So you have to reset the pattern to resume playback? Or is that just an omission? Kinda makes sense that there isn’t a START the way ES works.

I think the only way you could actually sync a pattern this way (besides manually timing it) is if you were able to set the ES buffer length as the time between incoming triggers, and rescale the buffer contents to the new size (like I’m guessing happens when you halve or double the pattern speed - unless you’re varying read through rate and the buffer size is fixed?). Otherwise, the only way to make sure you get your entire pattern in tempo-sync would be to set your master clock by the ES pattern length, which is a little backwards and back where we started.

+1 for a revision allowing you to clock the whole ES pattern; still have to decide what gets clocked: notes or ‘ticks,’ since timing gets preserved when you record a pattern I’d think the latter. Seems like clocking individual notes would lose some of the ES personality (and would be harder to execute I’d think). Clocking the 16 steps across the grid could be an option, or the ability to change whether one clock equals 16, 8, 4, 2, or 1 steps across the pattern would seem to be a winning option. So each sync would really turn into a reset to a different specific place in the buffer, but even factors of the pattern / buffer length. This would also allow you to add a command to set your position in the pattern (approaching WW functionality but over a continuous buffer rather than 16 quantized steps). Combine all this with the above idea of resizing the pattern from incoming clicks and you’d have pretty absolute control over synchronization with ES.

Sorry didn’t mean to get so long winded - my posts are always too long. I’m sure the ES stuff is back-burner with all the other avenues that TT opens up. Really getting excited to play with one - now I only wish there were more outputs in that blank, seemingly unused panel space, cause why not? Unless of course that’s all the I/O manageable. It’s enough, for sure, I’m not trying to be greedy now, that just seems like a lot of space. OK, maybe I’m being greedy.

1 Like
#118

couple more questions:

assuming gates can also be used as triggers (triggering on the positive edge) is there a way to tell if the gate is still high? like doing a loop while the gate is high.

can delays be used within loops?

#119

At present the eight inputs are just for firing off commands, as such they don’t have an accessible state in the system. That being said it might be possible, and seems an interesting feature for doing additional logic over a number of inputs eg: on Script1, if In2 is high then do X. Definitely not until v2.0 if it happens.

Delays & Loops can’t be used together - all of the prefixes (which use a “:” colon) can only be used one at a time. You’d very quickly fill up the delay buffer, and run out of space on the screen!

1 Like
#120

I would support the idea of using note names for entering note data, I realize this system excels at non traditional composition, but really why not have the best of both worlds? Some of us still tune oscillators to work beyond the modular system. Just having a set of 4 Euclidian style sequencers adjustable on the fly through preset changes would be amazing

loving how this looks and am excited by the integration with the existing line of monome modules. Nice work.