#21

I’m still for shadow scripts… it’s just a perfect match for the grid ops! (while staying in familiar territory concerning GUI)

great idea! not too enamored about the A and B clashes with variable names. but I would love this as an optional setting/converter for the tracker for sure!

#22

True, that would make it impossible to input base > 10 data with digits > 9 using BASE.

The first thing I thought about was adding some special characters. But that would need annoying key combinations, and might complicate exporting scenes. A more elegant solution I think is to have Teletype recognize characters as digits whenever they are preceded by a digit. This would work because (as far as I know) no OP starts with a digit. B would refer to the variable B, while 0B would refer to the number B (11). This also gives us the whole alphabet, if for whatever crazy reason we want to play around with base 35.

4 Likes
#23

Yeah I’m not familiar with the innards. Since the tracker isn’t evaluating expressions (?) I thought it might be technically possible, but at the least it would be confusing otherwise.

#24

@scanner_darkly @sliderule this [arbitrary bases] might be something I could implement, given some time. Would you give me some pointers on how to go about it?

#25

Thinking in base 12, it Would be useful if the grid control mode coarse update would be +/- BASE. As this would allow you to easily pitch pattern values up and down octaves if they are passed to N.

Instead of a and b, you could do _0 and _1.

Also would be cool if you could get set base with a BASE op that could be updated in real time as a performance “gesture”

#26

the main change would be in the tracker UI: https://github.com/monome/teletype/blob/master/module/pattern_mode.c

it’s an easy change for any base > 7. but for anything below it’s a major UI change as it would require scrolling. i think the UI for this should be given careful consideration - how do you display tracker in this case? would some banks be displayed partially, or do you just display the ones that fit? it would be also good to show the bases somehow, especially if you can set it per bank, but i’m not sure there is enough space. then for base 2 you probably want it to display the actual binary representation, not the positive portion with a minus sign - i don’t really see the benefits of the latter.

(as a side note i think only 10, 16, 12 and 2 are really useful, so not sure supporting any arbitrary base is necessary).

then you would need to implement the op, check the readme on the tt repository, it has some documentation there and i can help with specific questions.

finally, the choice should be persisted in flash, for that you would need to:

  • modify module/flash.c to store it
  • modify module/main.c to read the setting from flash upon bootup
  • add a function to update the setting to src/teletype_io.h - this is what the op will call
  • implement that function in module/main.c and make sure it updates flash. edit: also need to implement it in tests and simulator

and as @jlmitch5 mentions, the grid control mode will need to be updated - i can handle that part.

for base conversion patter.c uses itoa function, don’t remember for sure but i think it might have a hack that only makes it work with base 10, you want to double check that as well

1 Like
#27

Can we merge @alphacactus’s XDEL OP? And perhaps consider my RAT variation? I understand the delay timing in general is a bit rough (±10 ms) but we’ve already got DEL so we might as well have other delay OPs :slight_smile:
I think that DELAY_SIZE would have to be increased to accommodate the larger queues.

#28

yeah, definitely, just need a pull request.
we should discuss limiting the overall number of delays first though, it’d be nice to improve timer accuracy at some point and high number of delays might make it unfeasible.

#29

Imagine if we went suuuuper retro with it and forced everyone to familiarize themselves with which hexadecimal digits correspond to which chunks of 4 binary numbers :joy:

that said, I do think base 2 has a good reason to be included if base 16 does, namely, if you want to use @starthief’s bitpacking correspondence between numbers and trigger patterns, but you want, say five or 11 beats per bar rather than four or 16.

1 Like
#30

reminds me of the fact that the old classic trackers (and renoise now) had the option of switching between decimal and hexadecimal…

thinking more about it, for hexadecimal it probably also makes sense to treat values as unsigned.

2 Likes
#31

ok give me like an hour and I’ll get it ready. if I recall the only bug I had was with very long delay times wrapping into negative and triggering immediately. never got around to fixing that.

1 Like
#32

ok here’s the branch. it built okay, but I won’t be able to flash/test it for another hour or so here. I can hold off on the pull request until I can test it myself if desired.

1 Like
#33

yes, please test it before a pull request. i would also recommend running tests, they are super helpful to catch any ops that are not set up properly.

re: op name - not sure about RAT as the op name. it’s short for “ratchet” but that kind of implies how it would be used, while something like REP would be more generally descriptive.

#34

Yeah, the XDELAY / XDEL names are good IMO since DELAY / DEL are established. But between RATCHET / RAT and REPEAT / REP my preference is simply due to my love of rats. :rat::mouse2::rat:

4 Likes
#35

yup I ran make tests earlier with no issues. flashed the build and ran a few commands without issue. is there anything in particular you’d like me to test?

#36

just the new functionality and make tests and whatever else you think might be affected by the new code.

it’d be a good reason but then the cat people will get upset. on a serious note, XDEL is even better as it’s easier to remember and follows established naming conventions. that’d be my vote.

2 Likes
#37

How about NDEL? Maybe I’m just being silly and like the look of the letter n, but it’s used in some ops already and conventionally designates number of elements.

2 Likes
#38

XDEL is good by me. I’ll think of some edge cases to run it through tomorrow night.

if we name it XDEL then the documentation should read as XDEL x y where x would be the number of delays to queue, and y is the delay time. so I’ll have to modify the code for that if everyone is in agreement.

edit: NDEL is very good too

1 Like
#39

Those were proposed as two separate OPs! XDELAY for adding x commands to be executed later, RATCHET for executing once now and x-1 times later.

#40

the code change linked only had one op. i can see benefits for having both (and NDEL also sounds good). sounds like this needs more discussion?

(just want to reiterate again, i’m participating here as a teletype user, not a teletype developer. unless, say, something is not possible technically or needs to be considered within a bigger context in which case i’ll use my dev hat)