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.
Ah, the holy grail! You found it again! Maybe we will keep track of it this time.
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’.
Also another one :
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.
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
> teletype: grid code exchange
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).
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
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).
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?
Like this : `
L 0 7: Y I; SCRIPT 8
G.GRP Y; A MUL Y 8
G.BTX A Y 0 1 1 1 0 7 1 8
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!
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.
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.FDX - these stay as they were. there will be new ops added, denoted by additional
G in the name:
G.GFDX. think of these as
PN versions of
I wish this would find its way into manual as it’s been a bear to find.
yep, it got removed when the docs were redone, i mentioned it here: Teletype docs enhancements (docs are live, cheatsheet will be live very shortly)
i’ll see if i can add it tomorrow!
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
Yeah, i don’t know why i asked for 16.
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.
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.