#245

One more question if I may, since you just changed the rules of the game for me. XD

#1
IF EQ X 0: A 1; B 2

When this op executes, does B get set to 2 only if X is zero?

Or more generally do all semicolon separated ops after a modifier get affected by the modifier?

#246

correct, a modifier will be applied to all of the semicolon separated ops after :

1 Like
#247

I’m so sorry but my brain is wired in “can we shorten this”-mode from so much time on the teletype, I would write

IF ! X: A 1; B 2

3 Likes
#248

I was thinking about creating something along the lines (no pun intended) of Compass with Teletype and Magneto, and how it would be nice to be able to use the Tracker view with chars/symbols. I personally feel that it’s easier to give meaning to a char or symbol than to a number that would trigger an action. Let’s say for example you’re triggering a sequence of actions from the tracker view. Using “S” or “^” for using a shift CV trigger, or “I” or “∞” for the infinite transport control would be much clearer than a number. To prevent scripting confusion, there could be some kind of a char or ascii op. Any thoughts?

#249

I think it sounds cool but there is no OP which accepts chars or symbols, so there is a lot of fuzziness between the overall concept and the suite of needed OPs to make that concept worthwhile. The only direct use I can think of is accepting the currently-existing variables as input into the tracker to allow evaluating them as numbers when retrieved.

#250

A way to bypass would be to only allow the chars etc to be inputted in the patterns, and when they’re retrieved from a pattern index interpret them as the ascii code (always a number)

#251

I wonder if this propsal has ever made it to something?

I tried to get there by averaging a looped addition of twelve random values but I could not figure out how to get it asymetric as @zebra suggested in that thread and how it’s known from the Buchla 266. An extended version of it’s second stored random function would be very useful - a bell curved distribution with parameters for the shape of the curve like Skewness and Variance. It’s great for pseudo random melodies and stuff…

4 Likes
#252

Dear Teletype community. A friend of mine is building me a DIY Arc, I would like to connect it to the Teletype, the same way I connect my DIY Grid. As far as I can see, libavr32 already supports arc messages (monome_ring_…), but there are no Arc OPs in the Teletype? Should not be hard to add a few? (If this has already been discussed, I would be happy about pointers to readup). I might just implement this privately for myself, but I guess I should do so in a way, that it could be at least considered for inclusion in the main branch at some point in the future.

Another request which comes to my mind would be the inverse BPM function which was found to be lacking in the “Teletype Talk” YouTube tutorial. If it has not been already done.

#253

It is a hard design problem, even if the code ends up simple. What are you hoping these OPs will do?

I think * / 30000 M 2 would work. A hypothetical inverse OP could save 6-8 characters, though. In what context was BPM needed as a whole number of beats per minute rather than the period in milliseconds?

#254

I think * / 30000 M 2 would work. A hypothetical inverse OP could save 6-8 characters, though.

If it is that easy, the feature might not be necessary. I was trusting the reviewer in this video, who goes to great lengths and chooses a rather inefficient looping strategy to calculate the inverse https://youtu.be/mMAhjRKrpZE?t=1155

I think the idea is mostly to have a more intuitive feedback, maybe also for quickly adjusting other devices working with BPM inputs on the modular.

It is a hard design problem, even if the code ends up simple. What are you hoping these OPs will do?

I guess, first of all to use the encoder knobs as virtual potentiometers, to set CV etc., and then set the LED feedback, similar to how it works for Grid (but without the graphical representation). Like setting a virtual scale, and then doing operations over ranges on this scale, or transposing the scale itself.

#255

@EqualTemperament wow, you really took the long way around on that one :laughing:

2 Likes
#257

I too would love to be able to easily shift randomness to a certain center or edge.

In other environments I would normally do it like this:

  • Generate a random number x between 0 and 1
  • x^2 or x^3 etc for shifting down towards 0
  • x^1/2 or x^1/3 etc for shifting up towards 1

With TT, I would do something like this as a crude workaround, which is not so elegant:

J RND 100
PROB 20: J RRND 80 100

Or maybe I am missing something?
I know there is CHAOS but it seems too specific for that use case.

1 Like
#258

I’m most interested in a way to distribute random as well…

#259

Hello @scanner_darkly, I would like to implement I2C-OPs for the ZRNA FPAA board. How do we start this correctly? Current I2C address seems to be 0x15, is that ok, or will there be a conflict with existing hardware?

Main site: https://zrna.org
Examples: https://zrna.org/docs/quickstart
Existing python I2C client: https://github.com/zrna-research/zrna-api/blob/16a4fa981e5e21202a0ad78a9b18ffa298ef17d0/zrna/util.py
Definition of remote procedure interface: https://github.com/zrna-research/zrna-api/blob/16a4fa981e5e21202a0ad78a9b18ffa298ef17d0/proto/zr.proto

#260

you don’t need to add ops - you can just use the existing generic i2c ops added in the latest beta (posted in the OP): https://github.com/monome/teletype/blob/main/docs/ops/i2c.toml

#261

Just a quick idea regarding the complication of entering the pattern backwards…
How about an OP that simply reverses an input (before it is evaluated)?

REV 23 // gives 32
REV 110 // gives 011

That op could be working on B numbers as well.

B1101 // gives 13
REV B1101 // gives 11

Then one could enter the pattern in correct order, reverse it and then use DEL.B:

DEL.B REV B1101
results in “ping! ping! (rest) ping!”

Not sure if this makes it more complicated than before. But a generic “reverse” operation could be interesting… ?

1 Like
#262

you don’t need to add ops - you can just use the existing generic i2c ops added in the latest beta (posted in the OP):

The recipient will not understand such commands at the moment - it uses I2C to transmit serialized protobuf messages; there are dozens of different object classes which take hundreds of named parameters, as you can see from the .proto file I posted in my last comment.
So I thought of using an embedded protobuf library like nanopb to create ops (https://github.com/nanopb/nanopb).

If you look at the example in the quickstart (https://zrna.org/docs/quickstart) I imagine it like this on the Teletype (OPs can be shortened):

Z.CLEAR
Z.PAUSE
G Z.GAININV
Z.GAININV.GAIN G 100 
I Z.AUDIOIN
O Z.AUDIOOUT
Z.ADD I
Z.ADD O
Z.CONNECT I G  (or Z.OUT I Z.IN G) 
Z.CONNECT G O (or Z.OUT G Z.IN O) 
Z.RUN

It might work with generic ops IF I would write an external protocol bridge, transcoding messages with protobuf, so the ZRNA board would understand. Still, I am unsure if complex OO parameters-as-commands (such as GAININV.GAIN, OSCILLATOR_SAW.OSCILLATION_FREQUENCY etc) are supported.

I could of course limit the level of control to setting a few numerical parameters, or introduce abbreviations.

Do you think using an embedded protobuf library such as nanopb would be outside the capacities of the platform?

#263

I built a TXi yesterday and, remembering this post from Trent about Crow’s hybrid leader-follower behavior, wondered if I could get TT to behave like this so I didn’t have to give up “follower mode” on the TT:

I haven’t exactly stress-tested this code, but TT seems to be perfectly happy doing exactly that if I init leader mode in the two TT leader functions, and then re-init follower mode right afterwards. Crow is able to trigger TT scripts and TT is able to read values from TXi.

4 Likes
#264

great to see it works! yeah i would say we would need to stress test it extensively, super fast metro with lots of both reading and sending i2c commands, several devices and several leaders.

1 Like
#265

are you thinking of adding this to the official firmware or just in your own fork? for the official firmware this looks like a large language extension, so it would need to be something that would be a fairly common use case.

hard to say without trying it. also keep in mind you’d likely have to reimplement the current i2c stack in libavr32 since it’s not really designed for such heavy communications.

1 Like