if a feature requires a separate discussion thread create one under Development category, tag it teletype and post a link to it here. i will update this post with the links.
updating flash will erase your presets! please also note the 1st time you run it it will ask you if you want to overwrite scenes - this is expected (see this for details), just follow the screen instructions.
includes everything from the latest official 3.0 version plus:
The elephant in the room is probably additional scripts, and possibly additional variables. Seems almost too greedy to even ask given all you have done. The number of ops, communication destinations, and generally what can be done with Teletype continues to grow, but the number of available script lines has remained constant.
I’m sure this is more than a small tweak. Complete rewrite? Is there even enough bandwidth left in the CPU to be able to trigger additional $ OP only scripts and still maintain the integrity/timing of hardware triggered scripts and metro?
Thought I’d list it, as it is probably near #1 on my wish list. But totally understand if it’s a non-starter.
Thanks for the link. I see now it’s even more complex than I thought, as it’s also political in addition to technical. And I can appreciate that. It looks like you were in favor of some additional scripts (or at least a way to create some additional space for code) at one point.
What is actually needed to get a change like this to the master branch of the released firmware?
In the interest of “more scripts” for those of us who don’t necessarily need more text but want more ways to trigger unique events – are script lines able to be indexed?
Perhaps it could it be LN, mirroring the PN standard? Each with its own index position.
e.g.:
LN x y would execute the yth line of code in script x
LN.I x y would set the index position to y in script x
LN.HERE x would execute the line of code in the index position of script x
LN.NEXT x would increment the index position of script x and execute that line of code
LN.PREV x would decrement the index position of script x and execute that line of code
Some stuff wouldn’t track, like LN.INS, but some stuff like LN.RM might allow for some weird performative race against the sandcastle washing away.
Is this insane? It feels reckless to even suggest it.
this would be really cool, especially if extended all the way to self generating code. but probably too much of a special case for the official firmware (makes me want to explore ways to emulate software decay though, code that rots, gradual loss of precision, teletype that is not sure what it should do next…)
this is pretty accurate. i’d say #3 is a must, and 1 and 2 for the most part. often there is an accompanying discussion that helps shape a feature, but sometimes it’s a single vision that gets championed and executed by a single developer (it’s also a complex question as evidenced by the linked thread…)
i’m going to use this as an opportunity to clarify that this thread is a completely free discussion of what people would like to see in future versions, and me starting this thread is just that. this also applies to my participation here - i will try and provide a developer point of view (say, if something is not feasible technically) but otherwise i’m just one of the participants, so me commenting or not commenting on specific features should not be seen as an endorsement or commitment to implement them or otherwise (although if there is a general consensus and @tehn agrees, and it’s something i want to work on i imagine some features might get implemented along the way - but it is my hope to also see both the old devs - @sam, @sliderule - i’m looking at you and maybe some new devs joining, how awesome would that be!)
Longer init script for sure, scrolling here is not the end of the world. As cool as the timeline seems in theory, I’d rather just have a big bucket of commands to execute: with grid ops and Telexes I am chewing up 3 or more scripts just setting stuff up. I don’t think I’d care too much about shadow scripts, etc. if I had a full 8 scripts available in practice after setting up the scene.
This is a really neat idea. Part of me wonders how comprehensible a scene that used a lot of these types of ops would be to the person who didn’t create it, and perhaps to the person who did create it a few weeks or months later.
Can’t tell you how many times I’ve wanted to do something like this. As well as IFC, ELIFC, ELSEC, WC.
i appreciate @scanner_darkly putting #3 first, but honestly #2 is by far the most important element at this point as i am fully buried in norns development.
regarding feature requests, i’d suggest including as much detail as possible so that a design can be considered as a whole proposition, not just a spark of an idea that then needs to be designed around. ie, scrolling scripts.
memory usage, are people happy with vastly fewer scenes?
how does scrolling actually work in terms of UI? hotkeys?
is there visualization of scroll position? does that effectively shorten line length?
is scroll position stored when moving around scripts?
does this feature break or interfere with any other UI?
does this feature open up possibilities to expose CPU limits, memory limits, stack limits, etc? ie, does it mean the user will have to internalize more user limitations, rather than have the design of the system have its limitations set intrinsically?
that last point is the most important in my opinion. it’s too easy to imagine anything is possible. even my proposition for the “timeline” feature may run into the same issues… creating situations where “normal use” actually breaks the whole thing. this is what i’d like to avoid.
that said, i don’t think these features should not be explored— but someone must have the time to do the actual work.
Answers not required from anyone in particular, just kicking this around:
memory usage, are people happy with vastly fewer scenes?
What’s the tradeoff? In other words, how much storage is available, how much does a scene currently consume, and how much does a line in a script consume?
how does scrolling actually work in terms of UI? hotkeys?
Follow the Rule of Least Surprise: do whatever Tracker Mode does.
is there visualization of scroll position? does that effectively shorten line length?
There are two unused columns of pixels to the left in script view. Use one for scroll position (dimmed pixels).
is scroll position stored when moving around scripts?
As above: do whatever Tracker View does.
does this feature break or interfere with any other UI?
If it is confined to a single script (i.e. init), I don’t think so.
does this feature open up possibilities to expose CPU limits, memory limits, stack limits, etc? ie, does it mean the user will have to internalize more user limitations, rather than have the design of the system have its limitations set intrinsically?
That depends on how scenes are stored in RAM and how they are processed. I would be overjoyed to have, say, 30 lines’ worth of init.
(The main use case for extra scripts IMO is function-like behaviors called from e.g. loops.)
Some ideas I’ve had floating around for rhythmic sequences, in order of increasing nerdiness:
LROT x y / RROT x y for bit shift with rotation
IF BGET C 0: TR.P 1
C RROT C 1
BIN x (alias ‘#’ since I assume the standard ‘0b’ prefix is going to be confusing in all caps) for binary constants. Line length is a possible gotcha, but 8 bits may still be useful.
A BIN 1000110010001010
B | LSH B 4 # 1010
Also possible HEX or OCTL. A bit less intuitive for rhythm than binary, admittedly, but more concise, and possible to set variable display/pattern editor (DEVICE.BASE x).
ER.V x y for the values of Euclidean patterns (max length 16) as integers from binary, with ER.V x y where x= fill and y = length. So for example:
Actually, expanding on the “loop on several lines” thing, it would make sense to have only one “continue” pre operator that would work for L, IF, ELIF, etc.
Expanding on the idea of adding bases: I’ve wished Teletype had support for base 12 in the tracker view for quite a while as it would be really useful for manipulating notes. In base 12 it’s very easy to add and remove octaves and interpret note numbers. Here are some examples of why this is the case.
Here are the basics
base 10 base 12
C 0 0
C# 1 1
D 2 2
D# 3 3
E 4 4
F 5 5
F# 6 6
G 7 7
G# 8 8
A 9 9
A# 10 A
B 11 B
Now, let’s try some notes with different octave numbers. You’ll see that notation is base 12 is much simpler to interpret, because we can tell the octave by the first digit, and the note by the last one.
In contrast, in base 10, the number is equal to the note number at octave 0 plus the number of octaves times 12, which just isn’t intuitive.
We also don’t have weird cases where we get a three digit base 12 note number, because you’d need to use a range of 12 octaves or more, which is more than Teletype can output, and more than the earing range.
I think the place where this would be most useful is in the tracker view. It would be ideal to be able to set the display base for each pattern rather than the whole tracker view, as it would allow different types of data to coexist.
We could even generalize the idea to arbitrary bases, so we’d have a BASE B X to convert number X from base B to base 10, and P.BASE B / PN.BASE N B to change the tracker view display format of the selected pattern to base B.
It looks like you were in favor of some additional scripts (or at least a way to create some additional space for code) at one point.