#42

having single char math operators will go a long way for sure, as they are often used together with PRE.

shortening commands - it’s always going to be a struggle between readability and compactness, but there might be some ways to improve the latter without sacrificing the former. the dot in TX commands is not strictly needed - what about changing TO.TR.PULSE to something like XTR.PULSE?

1 Like
#43

Personally, I’m a fan of the line constraints but it is a trade off. Through most of the development of the ansible midi ops I had longer more descriptive names but right at the end I shortened them somewhat to get more script density.

2 Likes
#44

ok i’m back. love the hotkey propositions, particularly the linux-centric ones

very much against line continuation. that really kills the flow. i think the tradeoff of shorter lines for instant full readability is a very obvious design decision. but i concede that TT is now a community project.

7 Likes
#45

I agree with the idea of keeping all lines visible.
But am excited about all other ideas people tossed around that allow for some extra savings in space by eliminating spaces or offering alternative naming/commands etc.

4 Likes
#46

I like the monome design as it was developed. It feels like a real instrument framework, with all its design decisions.

Seeing that it became a community project now is exciting but I wonder if there will remain an official firmware branch that gets supported and debugged within the existing design framework? For those of us who cannot participate in the coding community or develop their own firmware versions.

I am a little bit concerned if longer lines with longer/more complex scripts and more complex screen maths will have an effect on the stability and performance of the firmware as the now wider used i2c features do have. A defined and maintained frame within which everything does work as expected would be great to rely on.

Regarding shorter commands I would vote for something that still has a connection to the actual function, not just one letter. But as Iong as it is arbitrary it sounds great and would be easy to learn stepwise. I like some of the other propositions to save line space too as dropping the spaces around colons (I tend to forget typing them anyway - maybe due to having no coding background).

Maybe I am a bit conservative and anxious. I think I just find this:

more useful than this:

:smile:

3 Likes
#47

I’m also in favour of keeping it all on the screen so you can see it. But I also know that I can cheat quite easily by writing new ops or otherwise fiddling with the firmware (see all the changes that I’ve made…), so I’m trying to be open minded.

If I were trying to find some extra space on the screen for more ‘script’, I would be looking to get rid of the error line, and use a pop up for messages, that would bump the number of lines to 7. Next if we allow editing in place (with suitable UI), that would give us another line. I’m not saying that any of these are good ideas, but that’s where I’d look next.

AFAIK, this will be the official version once it’s finished.

I don’t think you need to worry, I’ve been rewriting a lot of the underlying code as I’ve been adding features, and with all due respect to @tehn, the code quality is a lot better now.

Just in case anyone is not aware, shorter commands are in addition to longer ones, e.g. both TR.P and TR.PULSE work. Hopefully this will be much clearer once I get some documentation sorted.

7 Likes
#48

@scanner_darkly, just been looking at the held keys code, and I’ve found a weird bug.

If you’re on the preset write screen and you hold down a key, say F, then tap RETURN once (while keeping F held), it behaves as though RETURN is being continually pressed. Any ideas?

#49

Managed to get a decent amount of stuff done today. I’ve moved the ‘help mode’ and ‘preset read mode’ code into their own files. As well as split out the flash reading and writing into it’s own file too.

I’ve been a bit arbitrary about which functions go in which file, partly because it’s a bit too WIP and I don’t want to spend too much time thinking about it.

You can see the updated files here.

#50

Yes, just to clarify:

I think it is extremely important to keep the original TT script commands in addition to the new, compacted versions. The TR.PULSE —> TR.P is a great example, or the ADD —> + where both versions can be used interchangeably, based on user preference.

I think a good revision of the TT script manual/reference will be due with the official TT2 release too, which should include some clever, easy to see/understand way of showing this information.

1 Like
#51

The plan is to use some sort of structured data format in addition to Markdown to store the op documentation.

e.g. (in toml)

[ops]
[ops.ADD]
prototype = "ADD x y"
aliases = ["+"]
short = "Add 2 numbers to together"
description = """
Add 2 numbers together

Example:
> `ADD 2 2`
"""

This can be processed and spat out formatted as (and made into PDFs and cheatsheets, etc, etc):

ADD

ADD x y

  • aliases: +

Add 2 numbers together

Example:

ADD 2 2

+

Alias of ADD

Furthermore, I’ve got some python code that can parse the list of ops as defined in the source code, so I can even print out a list of ops with missing documentation.

4 Likes
#52

Looks/sounds great!
The formatting looks very transparent.
Though in addition to that, I personally like a smaller, quick lookup/reference sheet. With the suggested formatting, a full reference would be many pages.
So basically (not unlike the code abbreviations we are discussing) I am thinking of the “alias” version of the command reference :slight_smile:

1 Like
#53

Yeah I’ll try to do a cheatsheet / reference page too. That’s what the short text would be for.

Once I’ve got the basics up and running, I’ll start asking for contributions to help fill it all in.

2 Likes
#54

Crazy thought – what if we made these ops descriptions discoverable in Live mode? So if you just type an operator without any parameters the error returned is the documentation for that operator? Probably easier said than done :slight_smile:

1 Like
#55

it wouldn’t be only on preset screen, you can probably reproduce in script editing as well. not near TT right now, are you sure it actually behaves the way you described? i would expect it to continue with F once you release RETURN. not sure this is something that can be easily fixed - from quick code/google check looks like HID frame for release does not specify which key was released, and it will continue sending frames for the keys that were not released yet.

1 Like
#56

I totally agree with the screen limitation thing, less is more as they say BUT i don’t really feel the same about the 4 patterns limitations having 2 pages of them (so 8 in total) would allow creation of more advanced algorythms (especially when the TxI and TxO will be out).

1 Like
#57

I’ve got some ideas about short inline patterns (via ops), which should open up avenues for arps, mini sequences and scales. I need to get a prototype worked up first to make sure it really will work the way I think it will. But if it does and it’s easy enough to use then it might relieve some of the strain on patterns.

I’ve moved out the ‘preset write’ mode code into it’s own file this morning. I also abstracted out the line editing code:

https://github.com/samdoshi/teletype/blob/2.0/module/line_editor.c

Next up, need to abstract out live and edit mode, and get them to use the new line editor. Then pattern mode.

Once that’s done, I’ll start adding all the new keybindings and do a new beta release.

2 Likes
#58

Making decent progress in splitting the modes up, just edit mode left to go. Have really reduced the number of global variables in main.c.

Add some new ‘pending’ features to the list at the top:

5 Likes
#60

I think that is more of an Earthsea firmware thing, the code to send II commands on the Teletype is minimal (for all devices), the main code for dealing with it is on the Earhsea itself. I take it Earthsea is using ES.CLOCK as a kind of alternating clock on, clock off message?

#61

I believe the reason it requires 2 clocks is for note-on then note-off. It’s been a while since I was used this feature though.

I guess the trade-off for one-trigger per note is you lose control of note-length – should the notes be legato (no gap) or fixed-width (how long?)? Perhaps the best solution is to write a script that sends the ES.CLOCK message twice with a delay before the second to set your pulse width?

Sorry if this is totally off track!

1 Like
#63

this is what i’ve done in the past - works well. i’ve also mapped delay time to the param knob so i could “dial in” the note length and play with it.

2 Likes