Grid ops / integration

[chapelierfou]

Like this : `
I:
L 0 7: Y I; SCRIPT 8

8:
G.GRP Y; A MUL Y 8
G.BTX A Y 0 1 1 1 0 7 1 8
`

[simondemeule]

The development work being done here is amazing. Getting Teletype already was unavoidable, but now I fear I will need to get a Grid too!

[unity2k]

Then you may as well also accept that an Ansible and Arc won’t be far behind. I too am needing a Grid, should you accidentally buy two and are feeling generous I’ll PM you my shipping address.

[scanner_darkly]

yeah, a loop with SCRIPT is one way to achieve this. i do think that having group ops would be beneficial though, and i’m not suggesting adding group parameter to G.BTN, G.BTX, G.FDR and G.FDX - these stay as they were. there will be new ops added, denoted by additional G in the name: G.GBTN, G.GBTX, G.GFDR and G.GFDX. think of these as PN versions of P ops.

[unity2k]

To load the mlr.txt file to scene number 10 you rename the file to

tt10.txt

and place it on your flash drive.

I wish this would find its way into manual as it’s been a bear to find.

[scanner_darkly]

yep, it got removed when the docs were redone, i mentioned it here: Teletype docs enhancements (redesign in progress)

i’ll see if i can add it tomorrow!

[ghost]

Like this

That’s nice, you’ve given me some good ideas, and I can also see why we might want more than 8 groups. Increasing groups gets my vote @scanner_darkly Is there really a reason to limit it to 16 even? I see in a previous post you talked about the visualiser issue - I must admit I hadn’t figured out where group visualisation was…

G.GBTN, G.GBTX, G.GFDR and G.GFDX

This would be awesome

[chapelierfou]

Is there really a reason to limit it to 16 even?

Yeah, i don’t know why i asked for 16.

[scanner_darkly]

adding more groups is very easy - they don’t take much space and there is no performance impact, so we could easily have 32, 64 or even 128 groups. the only reason i had it at 8 was because the main purpose i had in mind for them was to make creating multi page interfaces easier, and i thought having 8 pages would be more than enough. i’ll be happy to be proven wrong though! the example with 16 radio button groups was a good one. curious how would you use 32 (or more) groups?

I must admit I hadn’t figured out where group visualisation was

it’s the 1-8 numbers to the left of the grid area. disabled groups are dimmed, and the currently active group has a marker beside it.

[ghost]

curious how would you use 32 (or more) groups?

I guess an obvious thing would be having 16 radio button groups for a 16 step sequencer + various other groups for other menus/pages/functions…that could easily take you into the 20s. I admit I can’t imagine wanting more than 32 (or being able to fit the code in!)

I love the way you can use groups to create pages. It feels quite elegant to switch between them.

[scanner_darkly]

i think i will change to 64 groups. this could allow you, for instance, to have 8 pages and then you can use groups within each page to set properties on multiple controls at once.

as it won’t really be all that useful to display the state of each 64 on visualizer i’ll change it to just show the current group number instead.

[scanner_darkly]

changed the visualizer screen. the currently selected group is now shown in the right top corner (and as you can see there are now 64 of them available).

still not entirely happy with the icons… @laborcamp do you think perhaps you would have a chance to help design something better? the top left icon is supposed to show which half of a bigger 256 grid is shown (upper or lower) and the one underneath is active when grid rotation is applied. both are 6x6 pixels.

[laborcamp]

6x6 is very tight, of course.
I am not sure if i can do much better than what you have.
The arrow, I agree, is a bit rough looking.
The only alteration that I maybe would be tempted in trying is to see if the “half grid” icon could be articulated by “filling” in one half or another, rather than just altering the brightness of the outline edge. But honestly, am not certain if that would be an improvement. Just something I would want to “try and see”.

[scanner_darkly]

thank you! yeah, i like the idea of filling in the half that is active, i think it makes it more clear which half is being shown, i’ll try that. was also thinking of reducing their size to 5x5. for the arrow i’ll try to play with some simple anti aliasing.

[laborcamp]

a quick try on the fill, and some 6x6 arrows.

[scanner_darkly]

these look great! for the arrow the middle one in the top row matches the meaning the best (rotating grid 180 degrees).

[laborcamp]

Perfect!
It’s little things, but it all matters!

[tambouri]

late to this party, but I grabbed the beta last night, and worked through a few of the studies and fell into a few playful digressions that follow studies

@scanner_darkly this is a really impressive and inspiring addition to an already impressive and inspiring module

thanks!

[chapelierfou]

Would it be possible to enter negative values for col/row arguments on G.BTN and G.FDX, so we can change the way ids are distributed ?
That would spare some maths.

[scanner_darkly]

great idea! i’ll add it. would also be nice to have ids arranged by rows first, but i can’t think of a good syntax for this…

curious though, what math do you need for ids? i find i usually need to use calculations on ids to determine a button’s coordinates (for something like trigger sequencer), for this use case i’m going to add dedicated ops since it seems to be an often used case (so something like G.BTN.X and G.BTN.Y).