#205

I don’t think that would be worth it because then you’d need all 16 bits defined basically every time you ran the OP. E.g. B1011 becomes B1101000000000000.

And QT.B, if similarly adapted, would start reading from the 12th bit of 16 bits, or ignore the 4 least-significant bits.

The marginal readability gain is not worth the increased length and complexity, IMHO. These OPs also work fine with decimal numbers that are (somewhat) easily held in the mind, like 7 is equivalent to B111, but who’s going to remember the decimal equivalent of B1110000000000000?

#206

I can definitely see the argument for not starting the .B ops from the MSB. Seems like we might have the optimal compromise already then!

I’ll just patch B locally to work backwards. I was never particularly attached to that convention anyway :joy:

1 Like
#207

DEL.B is great, thanks!

1 Like
#208

but you don’t really need to pad zeros, since they’re essentially ignored anyway. reading from the MSB, DEL.B B1101 is functionally equivalent to DEL.B B11010000 or DEL.B B1101000000000000.

#209

B1101 is parsed as 13, and the MSB of 13 has to be 0 but only because all those leading (trailing? if read backwards) zeroes could be part of the desired signal. If you always ignore the leading zeroes, then you can’t have your delay start with inactive taps.

E.g. we should retain the ability to go “(rest, rest, rest, rest) ping! (rest) ping!~”

1 Like
#210

makes sense! and this means that starting with the LSBs makes it easier to do shorter patterns, which is a good thing. also, keeps it consistent with other bit ops where the bit index counts from the right.

1 Like
#211

Here’s a handy little calculator for 16-bit signed integers in case you want to pre-calculate some bitmasks while away from your Teletype.

1 Like
#212

Haven’t tried DEL.B yet (soon!), but I think having to write the pattern backwards is going to be pretty awkward for me. Guess you could put the pattern into the tracker and loop backward setting a variable with BSET as a way around?

It would take a few more steps (and 1/4 of a tracker pattern) but I guess the other bonus is that it would retain the pattern for easy modification.

#213

There’s no easy alternative which doesn’t also compromise the functionality. :bowing_man:

If you are comfortable using so much pattern space on individual bits, that can work. I’d really recommend that you try B entry until you develop some muscle memory. You’ve already conquered Polish notation, so base-2 numbers should be a cakewalk!

#214

i think it’s worth considering why such an op is useful in the first place. it’s convenient to pack a 16 step trigger sequence into one number, since it’s more compact (instead of having an op with 17 parameters). binary representation is also good for readability, but doesn’t really come into play here since once you enter DEL.B B...: it’ll get converted to decimal.

the true value i think is the fact that you can alter sequences by applying math. what would really compliment this is having versions of ER and NR ops that would return a full 16 bit sequence instead of just one bit.

3 Likes
#215

Interesting. I think that’s true. The initial value that I saw was the ability to create a sort of custom clock that is not dependent on metro or an external trigger stream.

2 Likes
#216

I’ve gotten that exact “building an alternate metro” feeling from it (and the other multi tap delays–props to @alphacactus for leading the way).

One unexpected corollary: with the propagation of DEL.* OPs and the expansion of delay size to 64, DEL.CLR feels more important now than ever. I’m tempted to set up a second lane of delays with DEL2.* OPs so “selective clearing” could become a useful manipulation. I might play around with that only on my own branch for awhile, though, because I think the main repo has some outstanding items on the TO-DO list:

  • W/2 OPs (underway)
  • JF 4.0 OPS
  • Fix pattern indexing w/ P.START and P.END
  • Output mutes
1 Like
#217

Yeah, I was thinking of use cases outside of pulsing one of the TR outputs and I think there are maybe some pretty interesting ones. For example using DEL.B or DEL.G to clock a kria channel. Then kria is really in charge of deciding whether a voice triggers a note, but Teletype is advancing its channel clock in a non-steady (but rhythmic and perhaps repeating) way. This custom clock could be much faster or slower than metro - or related to it, and I think could retrigger itself without running into recursion issues?

The multiple delay queue idea is interesting for sure.

#218

Howdy! When folks get to implementing the TT->crow ops, it would be really nice if the outputs supported TR style ops as well as CV ones. Also, if there could be ops for reading the inputs without having to write any lua, that would be great. If it could have SCALE and STATE and whatnot for those, that would be amazing.

The reason I bring this up is that I was previously ignoring crow because I generally don’t want to have to write actual code on a computer to use a module, but if it could be used as a 4-out, 2-in expander in 2hp, that just so happens to be able to use lua to add some weird operations to TT if I want, well :exploding_head::smiley:

Also, all these neat new bitwise operators are looking great! This is exactly the kind of stuff I like to do with TT.

2 Likes
#219

Also voicing my support for the Crow ops as a fledgling TT + Crow user.

1 Like
#220

20 characters of LFOs and Envelopes

1 Like
#221

After watching @David_Rothbaum ‘s amazing patch from scratch video, in which he uses a Txo to route triggers into teletype at different rates, I realised how great it would be if we could have a generalisation of the current metro system in teletype.

At the moment we have a metronome that fires the M script at regular intervals controlled by the M, M!, M.ACT and M.RESET ops. How about a set of MS variants which would take an extra script argument to set a metronome for that script being fired at a particular rate? (And maybe also if an argument 0 is used it would control all scripts, which would be useful for MS.ACT in particular.)

Would that pose any major problems? I really ought to learn to make changes to the teletype firmware myself, but haven’t quite got to that stage yet!

3 Likes
#222

Hi @SimonKirby , do you have a link the video please? Thank you!

#223

It’s not quite the same thing, but you can kinda do this already by calling a script recursively using a DEL. For example, if you want a virtual M of 100ms on script one, you’d put this somewhere in the script:
DEL 100: $ 1
I guess that’s not ideal in case you want to set the rate from the outside, but in that case you could use a variable or an unused table entry to store the rate value.

#224

I’d love to have a CV.P op that worked like TR.P but for the cv outs.

CV 1 V 5
DEL 10: CV 1 V 0

works but takes up space :sweat_smile:

2 Likes