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 I’m still hoping for CUIA encoder controls to feed the engine parameters.
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.
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.
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.
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…
Turning the encoder clockwise…
Turning the encoder anti clockwise…
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.
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.