Arduino USB HID Controller

Are you running aseqview? That users port 128 by default

Ok moving the device of MIDI channel 16 seems of have made the difference.

And it seems to be independent of changing the Master MIDI Channel

Perhaps unplugging the YETI Microphone made the difference …?

So the current dilemma…

Do I send throu’ Encoder turn as CC with value 0 or 127 as direction, or do I implement these as notes…? And if I do them as notes do I encoder the phasing of the encoders as ON & OFF or do every interrupt event as a Note ON/ Note Off combination?

Note Number Function Note Name
51 SELECT D#3
52 SELECT_UP E3
53 SELECT_DOWN F3
54 F#3(Gb3)
55 SELECT SWITCH G3
56 SELECT DN G#3(Ab3)
57 SELECT UP A3
58 A#3(Bb3)
59 SWITCH_LAYER_LONG B3
60 SWITCH_LAYER_SHORT C4
61 SWITCH_LAYER_BOLD C#4
62 SWITCH_BACK_LONG D4
63 SWITCH_BACK_BOLD D#4
64 SWITCH_BACK_SHORT E4
65 SWITCH_SELECT_SHORT F4
66 SWITCH_SELECT_BOLD F#4
67 SWITCH_SELECT_LONG G4
68 SWITCH LAYER SWITCH G#4(Ab4)
69 SWITCH LAYER DOWN A4
70 SWITCH LAYER UP A#4(Bb4)
71 SWITCH_SNAPSHOT_SHORT B4
72 SWITCH_SNAPSHOT_BOLD C5
73 SWITCH_SNAPSHOT_LONG C#5
74 SWITCH BACK SWITCH D5
75 SWITCH BACK DOWN D#5(Eb5)
76 SWITCH BACK UP E5
77 SWITCH SNAPSHOT PRESS F5
78 SWITCH SNAPSHOT DOWN F#5(Gb5)
79 SWITCH SNAPSHOT UP G5
80 SCREEN_ADMIN G#5
81 SCREEN_LAYER A5
82 SCREEN_BANK A#5
83 SCREEN_PRESET B5
84 SCREEN_CONTROL C6

Which would be the more rugged approach ?

Shown below, in the foreground the 4 button 4 encoder USB HID controller connected to my “roadworthy” zynth. Not quite ready for a :face_with_monocle: I’m still hoping for CUIA encoder controls to feed the engine parameters.

4 Likes

I think we are very close…

What MIDI messages does your HID send for each action?

@wyleu,
Yes we are very close.

The the large difference between our similar projects is how it appears to the raspberry PI. Mine appears as a USB keypad device, not a MIDI device.

It sends [up arrow], [shift][down arrow] and similarly mapped CUIA keyboard interface actions.

I’m not sure at this point which approach will win out. Your approach of using MIDI by far has much more flexibility, and the possibility to expand beyond the 4 button/4encoder whereas mine does not. I’m imagining I’ll go back and do another firmware that mimics yours and appears as a MIDI device to have both possibilities.

1 Like

Apologies, didn’t re-read properly.
Two differing approach’s to the USB controller…

i think you can be more than one usb device type at the same time… why not both keyboard and midi?

btw i also fancy the “mimic a usb keybaord” idea… is your code shared anywhere?

You are correct. It should be possible to be both, mainly it would depend on the Arduino library support for dual mode devices.
I haven’t shared the code yet, but I intend to soon. It’s been stable for me for a bit now, and I don’t expect any large changes. If I add MIDI or dual support I’ll do that as a new series of commits.

I think that for the MIDI device it should be a low level interface aimed at the zyncoder end of the Zynthian not the python elements.
i.e. it should send the encoders as thou they were simple note on and note off for the individual encoder and have the zyncoder sort out the direction and propagate up the up and down signals for the subsequent handling.
The main issue is that if you change the short/bold/long timings these are NOT propagated to the HID without a two way interface which seems best to avoid.

I’ve assumed control is on MIDI channel 15 as per, but ,of course this might also need configuring in some way.

@wyleu,

While looking at zynthian_gui.py it seems that the LAYER_UP, LAYER_DOWN etc. have not yet been added as MIDI notes. They do exist as keybindings.

@MrBroccoli and @jofemodo
Here is my code: GitHub - smiths73v3/zynthian_controller_external_usb

Also thanks to @riban for the initial information and helpful suggestions.

1 Like

Yes, that’s my next stage I now have a HID that generates pure Note OnNote off implementation

So for the top left encoder

PRessing the Encoder button…

image

Turning the encoder clockwise…

image

Turning the encoder anti clockwise…

image

So a bit of logic should be able to turn this into higher level signals…

Are you sending note on / off on two note numbers for each encoder? I would recommend encapsulating that to a single note on for each direction. I don’t think the logic to decode quadrant encoding should be in the MIDI client, it should be in the HWC.

Agreed, It was more of a proof of concept, and accompanied by mucking around with one encoder and a couple of LED’s to check whether or not an encoder ever settles with both switches on, it does and also with one or other of the switches on, but it’s balanced on a detent when it does it…

It seems sensible to have all the controlling signals of one ‘type’ for ease of processing and anything we can do to cut down on the chatter seems like a good idea.
If we are left with a switch connected as described do you think it would be best to have a timeout to send the note off ?

You may omit the note off and just send note on. This is quite acceptable. Drum pads often do that and this is a specific use case which shoul dnot cause an issue.

I tried to see if this would fit the teensy-lc I have, but the way you use pins won’t really allow… I considered refactoring for teensy pins but then I realized black pills are very cheap too and just ordered one of them instead. All in, though… The code looks good to me. I’ll test it properly in a few days when the £5 black pill turns up.

1 Like

@wyleu,

My patch for LAYER_UP, LAYER_DOWN CUIA midi mapping went in a day or so ago, You should be able to grab this and use the newly added “note on” events for these to interact with the ui.

@smiths73v3 Trying to run your code …

Aimed at a MKRZERO…

Not sure where I need to start to address this error…

PA10 is a constant defined to identify a GPI pin. If you are using a different microprocessor you may need to change the pin numbers to those you are using and the naming convention for the microprocessor.

1 Like