Using MIDI controllers instead of Encoders

Hardware
21

That’s the stuff. Only problem, I’m supposed to be reading about Nuke Python right now lol

Cheers, if the timing is done in python that’s even easier, I assumed it would be down in the C code.

22

The encoders are interfaced with C and low-level timing is done there but the slower millisecond stuff is done at the higher python level.

23

It could be useful for you to know than V5 has 20 buttons + 4 encoder switches, all of them fully configurable. This is a game changer and the discrete SWITCH CUIA is not suitable for this.

We will be changing this to a more flexible scheme using CUIA parameters. This is already implemented in the testing branch.

I mean you will have SWITCH CUIA like this:

  • SWITCH 14,S => SWITCH 14 SHORT PUSH
  • SWTICH 8,R => SWTICH 14 RELEASE
  • etc.

All the best!

1 Like
24

Twenty buttons, you say? Are they by chance arranged chromatically? A capacative keyboard is high on my list of things I plan to add onto this.

For the moment I’m going to finish and enjoy my v4. Now that I’m employed I’ll probably order a v5 as soon as they’re available and save myself the hassle. :>

25

And this is how families of zynthians grow…

And don’t even start about if it’s left or right handed.

TeeHee.

1 Like
26

OMG!!! Don’t even mention this to Ramon. We tried to design a device that could be mounted on both configurations (left & right), but we abandoned when things started to be too complex. It could looks a simple task, but devil lives in the little details.It’s easier to design 2 devices.

BTW, it’s left handed, of course!! Right hand is for playing notes or moving knobs.

1 Like
27

unless you are in the southern hemisphere, of course…

1 Like
28

I just pushed a few changes to testing branch that include the new CUIA scheme i commented before.
All of you using CUIAS in some way, please take a look to the testing branch and the new parametric CUIAs:

  • ZYNSWITCH index, action_type

    • index => integer number, starting from 0
    • action_type =>
      • P => Push
      • R => Release
      • S => Short
      • B => Bold
      • L => Long

  • ZYNPOT index, delta

    • index => integer number, starting from 0
    • delta => integer number, it can be negative/positive

Be warned that i’ve removed a lot of old CUIAs, simplifying the list and increasing coherence a little bit.

The default “Master Note => CUIA” map has changed accordingly and it’s quite different to the old one, but it’s fully configurable from the webconf’s MIDI options tab.

Also, when configuring Master Note CUIAs, if you omit the action_type parameter, like

ZYNSWITCH 3

you will get a full emulation of SHORT/BOLD/LONG action on the configured note. I mean, it will use NoteOn for push and NoteOff for release. Nice?

Enjoy!

2 Likes
29

And at precisely which time…?

1 Like
30

Here is the new default “Note => CUIA” map:

NoteCuiaDefault = {
	"0": "POWER_OFF",
	"2": "REBOOT",
	"4": "RESTART_UI",
	"5": "RELOAD_MIDI_CONFIG",
	"7": "RELOAD_KEY_BINDING",
	"9": "RELOAD_WIRING_LAYOUT",
	"11": "LAST_STATE_ACTION",
	"12": "ALL_NOTES_OFF",
	"14": "ALL_SOUNDS_OFF",
	"24": "TOGGLE_AUDIO_RECORD",
	"26": "START_AUDIO_RECORD",
	"28": "STOP_AUDIO_RECORD",
	"29": "TOGGLE_AUDIO_PLAY",
	"31": "START_AUDIO_PLAY",
	"33": "STOP_AUDIO_PLAY",
	"36": "TOGGLE_MIDI_RECORD",
	"38": "START_MIDI_RECORD",
	"40": "STOP_MIDI_RECORD",
	"41": "TOGGLE_MIDI_PLAY",
	"43": "START_MIDI_PLAY",
	"45": "STOP_MIDI_PLAY",
	"48": "ARROW_UP",
	"50": "ARROW_DOWN",
	"52": "ARROW_RIGHT",
	"53": "ARROW_LEFT",
	"55": "BACK",
	"57": "SELECT",
	"60": "SCREEN_MAIN",
	"62": "SCREEN_ADMIN",
	"64": "SCREEN_AUDIO_MIXER",
	"65": "SCREEN_SNAPSHOT",
	"67": "SCREEN_ALSA_MIXER",
	"69": "SCREEN_MIDI_RECORDER",
	"71": "SCREEN_ZYNPAD",
	"72": "SCREEN_PATTERN_EDITOR",
	"74": "SCREEN_BANK",
	"76": "SCREEN_PRESET",
	"77": "SCREEN_CALIBRATE",
	"79": "LAYER_CONTROL",
	"81": "LAYER_OPTIONS",
	"83": "MENU",
	"84": "PRESET",
	"86": "FAVS",
	"90": "ZYNSWITCH 0",
	"91": "ZYNSWITCH 1",
	"92": "ZYNSWITCH 2",
	"93": "ZYNSWITCH 3",
	"94": "ZYNSWITCH 4",
	"95": "ZYNSWITCH 5",
	"96": "ZYNSWITCH 6",
	"97": "ZYNSWITCH 7",
	"98": "ZYNSWITCH 8",
	"99": "ZYNSWITCH 9",
	"100": "ZYNSWITCH 10",
	"101": "ZYNSWITCH 11",
	"102": "ZYNSWITCH 12",
	"103": "ZYNSWITCH 13",
	"104": "ZYNSWITCH 14",
	"105": "ZYNSWITCH 15",
	"106": "ZYNSWITCH 16",
	"107": "ZYNSWITCH 17",
	"108": "ZYNSWITCH 18",
	"109": "ZYNSWITCH 19",
	"110": "ZYNSWITCH 20",
	"111": "ZYNSWITCH 21",
	"112": "ZYNSWITCH 22",
	"113": "ZYNSWITCH 23",
	"114": "ZYNSWITCH 24",
	"115": "ZYNSWITCH 25",
	"116": "ZYNSWITCH 26",
	"117": "ZYNSWITCH 27",
	"118": "ZYNSWITCH 28",
	"119": "ZYNSWITCH 29",
	"120": "ZYNSWITCH 30",
	"121": "ZYNSWITCH 31",
	"122": "ZYNSWITCH 32",
	"123": "ZYNSWITCH 33",
	"124": "ZYNSWITCH 34",
	"125": "ZYNSWITCH 35",
	"126": "ZYNSWITCH 36",
	"127": "ZYNSWITCH 37"
}

Note the last keys, from 90, are configured with “ZYNSWITCH index”. They use Note On/Off to emulate push/release actions so you can perform short/bold and long key presses.

Enjoy!

1 Like
31

Very Nice! [dim question here, didn’t read it closely]

1 Like
32

That would be underhanded.

1 Like
33

How will this be configured for keybinding? Currently webconf shows discrete actions and allows binding of keys+modifiers but the new architecture is more extensible so may require a more complex webconf interface. (Currently keybinding is broken.)

[Edit] We could change the CUIA trigger configuration which is currently done in the Wiring page of webconf:

  • Allow adding and removing rows (currently fixed, based on the hardware type selection)
  • Allow each row to be a switch / key binding / other trigger
  • Columns are populated based on the trigger event type

I would suggest this moves to the UI configuration and not left in Wiring. It becomes a CUIA trigger configuration panel. Maybe it integrates with the new MIDI keyboard view.

2 Likes
34

So if I want to try testing, I just switch the repos all to testing and update? I’m gonna try that, but if not lemme know lol

35

Testing seems to be broken today. I would avoid switching to testing until @jofemodo has fixed the problems.

36

It did get real ugly after I switched it over, but I ssh’d in and did a git pull in the directories and it has started back up. Not sure if that means I fixed it or just that I got it to boot up.

I’m currently reworking my controller’s code for testing, no point finishing that timing pain if I just need to wait for testing to be ready. Though my struggles have all been of the C++ nature, I’m a big clumsy baby in that language. :>

edit: I do see the new set of cuia stuff though, this is more what I was expecting to see before lol

1 Like
37

Putting the buttons all sequential starting at 90 is a very nice touch - lets me handle all the buttons efficiently from a single byte array of the pins. I spent most of today fighting the Bounce library until I realized I was consulting docs for different versions and getting different examples.

1 Like
38

Not sure if it’s just broken like riban says, or else I’m not understanding what happened to layer_up, layer_down, back_up, back_down, etc. I see them as individual entries but not pairs of encoder options.

edit: I see they’re still configurable CUIAs but the default config seems to have forgotten about the rotary encoders, and I haven’t seen the panel layout of V5 yet so I don’t know, maybe you’ve moved to a purely button-based interface? Please advise.

1 Like
39

This could be confusing and very very long. Also, it’s convenient to have separated profiles for every trigger-input source. I would keep separated the different input sources:

  • hardware switches
  • keybindings
  • MIDI notes (it should be extended to other MIDI events)

but a single panel with 3 tabs could be a nice interface for configuring all this :wink:

Regards,

1 Like
40

These CUIAs doesn’t exist anymore. All low level CUIAs mapping to switch or encoder actions have been replaced by 2 single CUIAs as described above:

Regards,

1 Like