#202

ok, not a big deal, just dreaming :wink:
thanks anyways for that awesome work

1 Like
#203

i think i finally got the mlr style scene working including recording… will post it in the next couple of days, need to clean it up a bit. once i figured out how to setup er-301 things just worked as expected which is amazing. er-301 and teletype is insane combo.

15 Likes
#204

Ah, the holy grail! You found it again! Maybe we will keep track of it this time. :wink:

#205

i thought of a feature ‘request’ :

More precise/unstepped values for faders.
You could control the faders with a press+hold of the destination (not necessarily to get reached). The speed to reach the destination would be variable.
The last button of the fader could use variable brightness to display that it’s not ‘full’.

Thoughts ?

3 Likes
#206

Also another one :

“Grid Memory”
a collection of memory slots that you can use to store values and states of all (or grouped) grid elements.
That would be great to recall sequencer presets, for instance.

#207

i like this idea. i will need to rework the visualizer part and there isn’t enough space to display numbers for all 16 groups the way it displays the 8 groups now, but i don’t think numbers are really needed, i will change it to dots or something similar.

i did have group versions of button and fader ops but thought they were too unwieldy and removed them… but i think it makes sense to bring them back. so basically it will be something like:

G.GBTX group id x y w h latching level script countx county

2 Likes
> teletype: grid # code exchange
#208

do you mean being able to have sort of like a slew when changing fader values? the problem with this is - teletype is not really set up to track continuous changes. say, if we had this ability and a fader is slowly changing its value from A to B when should we trigger the corresponding script? if we just trigger it when it reaches B then we don’t really gain much. the workaround is using a very fast metro script, but this really feels hackish…

i do agree it would be nice to have the ability to have finer control over fader values, otherwise they don’t seem all that useful. so yeah, we could use varibrightness and have some button combo to increase/decrease value in smaller steps. i will add this to the list!

this is probably less likely to happen… the reason is - if we had additional memory slots i would expect them to be stored in flash when i store my scene. we have some space there but storing grid state takes quite a bit of space, and in the future we might have new features that will also need to use storage, so we have to be careful what we allocate it for.

a workaround for this is using our existing infrastructure in the form of patterns. it’s really easy to do something like L 0 15: PN 0 I G.BTN.V I. with upcoming bitwise ops it will also be easy to pack 16 button states into one pattern value (i have example of this above in the pattern canvas scene). i think what makes more sense is expanding the number of available pattern banks to 8 (or even more).

2 Likes
#209
#210

I can see the delicate balancing act that you’re doing here but agree this is worth doing for sure. Would allow much more complex arrangements of buttons/faders

I would also like to see this. I can see how this would be a lovely way to visualise levels/data

1 Like
#211

i am not entirely convinced of the need to add an extra argument. i think the syntax is already quite long to remember, and the screen space is precious. And if you go in this direction, why not have separate ids for buttons and faders ?

But in any case, i find myself easily needing more than 8 groups (currently on a scene with 10 radio buttons).

#212

How do you fit the commands to create the buttons in if you’re changing the group 8 times? Am I missing a trick here?

#213

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
`

2 Likes
#214

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!

1 Like
#215

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.

2 Likes
#216

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.

1 Like
#217

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

2 Likes
#218

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!

2 Likes
#219

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…

This would be awesome

#220

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

1 Like
#221

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?

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.

2 Likes