EN16 - Encoder button flicks rgb for encoder range

Hi,

I’m trying to build a multiple configuration control mode based in columns.

The button on the first encoder on each column would change the function CC sent for all encoders on the row.

The visual feedback would be to change flick the r,g,b base components of the color in the encoder between two configurations.

I tested the following basic config and it works but the base color only changes once I rotate the encoder a little bit.

Is there any way to force the color to update?

I have another question part of the same exercise but will post it separately to keep the information easy to find for others.

P.S.: if you enable the capabilities of users to create tags, that will improve exponentially the usability of the forum. Tried adding tags but is not working for me.

We have a couple of configurations that allow you to have multiple CCs for the same encoder you can change on the fly.

The biggest, best supported ones are the 64CTRL and 256CTRL configurations on the Cloud. Try them out and see if they fit your workflow!

1 Like

Thanks for the reply!,

I’ll check those configs and see what I can learn. Really want to do the configuration myself :slight_smile: Still fighting the editor a bit regarding element contexts and where/when and how things can interact with each other etc.

Is there any plain LUA editor mode where all the components are summarized in structured codebase?

Cheers.

Sadly no full code editor is available, but it’s a much requested feature, so we’re working towards a solution like that. TBA tho.

1 Like

TBH, the editor is a very nice feature and I much appreciate it. But when you start wanting to understand the interconnection of elements and how things really work it hides a bit all that.

For instance in the CTRL64 config it seems that you have spread the logic across the different elements (I guess that as a way of fighting the char limit and as a way of structure the code somehow). But it is confusing from a code architecture perspective as you are expecting any general functions to sit at System and then controllers would just consume whatever is defined there.

Let me know if I’m understanding that config in the wrong way.

One lesson that seems interesting is that functions defined in the setup of the controllers are shared across all of them.

BTW, I think that I found a bug regarding the NRPN block. It seems that after you configure it and save it, if you re-open the editor you cannot edit it anymore and after clicking on it the editor becomes unresponsive (clicking in other elements have no effect). Check video HERE.

Tested both, the local app and the web editor and the behavior is the same.

It’s easy to spot as all NRPN components show (0,99,) in their reduced view.

Ah that NRPN bug is back huh. Please make a report of this on the Issue Tracker.

About the 64CTRL: yeah, its code is mostly a relic of the old 390 character limit which has been increased since to 899. It would require me to rework the code, since it’s kind of legacy at this point. But currently, I’m working on VSN1-related configurations so stuff like this will just have to wait.

For the 64CTRL many tricks have been employed to fit into these code limits:

  • functions have been split into parts across elements
  • variables are declared on Timer Events too, not just on Setup Events (big no-no :D)
  • the 256CTRL by EchoMatter has streamlined some of this code, but kept the core of it

So I would say they are not ideal for learning, but there’s a bunch of cool things in there that could teach you the basics.

1 Like

Hahahaha, ok, makes sense.

Can you recommend me a few good sources to investigate more contemporary patches to learn?

Bug reported, I hope this helps: bug: NRPN MIDI Component is buggy · Issue #1430 · intechstudio/grid-editor · GitHub

1 Like