Our friend @riban has implemented a new feature that allows to control the Zynthian-UI using a standard computer keyboard. Of course, you can also use a custom keyboard made with arduino
This is the current key bindings list:
Key
Modifier
Function
Enter
None
SELECT
Enter
Shift
Bold SELECT
Enter
Ctrl
Long SELECT
Backspace
None
BACK
Backspace
Shift
Bold BACK
Backspace
Ctrl
Long BACK
Escape
None
BACK
Escape
Shift
Bold BACK
Escape
Ctrl
Long BACK
L
None
LAYER
L
Shift
Bold LAYER
L
Ctrl
Long LAYER
S
None
SNAPSHOT
S
Shift
Bold SNAPSHOT
S
Ctrl
Long SNAPSHOT
R
None
Start audio Record
R
Shift
Stop audio Record
M
None
Start MIDI Record
M
Shift
Stop MIDI Record
M
Ctrl
Reload MIDI Config
Space
None
All Notes Off
Space
Shift
All Sounds Off
Space
Ctrl
All off
Insert
None
Restart UI
Insert
Shift
Reboot
Insert
Ctrl
Power Off
Up
None
Listbox Up
Down
None
Listbox Down
Left
None
BACK
Right
None
SELECT
As probably this will change in the future, the updated list is in the Wiki:
Really like the None/Shift/Control mapping to Short/Bold/Long.
But No Play/MIDI play?
Perhaps we could be a little more protective and make R Cntrl Record and use R & P for Audio Playback
and similarly for MIDI with M and N (simply next in alphabet) ?
I’m beginning to wonder about page up and down for Listbox…
Well it’s possible but the a little bit convoluted with the present grammar.
You would need to drive the GUI interface into a Known Patch Selection Mode, and then provide a mechanism to programme up your patch selection, mindful of changes in the patch structure on both sides ( ) .
A much more intersting possibility would be an embedded MIDI send that would allow a specific MIDI control being sent to the Zynth . . . .
|Typed String|Desc|
|‘MIDI’ B0 00 01|Switch to bank 2|
| ‘MIDI’ C0 02|Switch to the third patch in this bank|
Me too! I think it may be worth adding Page Up, Page Down, Home & End for lists. Also maybe a shortcut to take you to particular pages, e.g. Layer page (Shift Home?).
The other considered element is patch order.
Alphabetic is ok if you can remember the patch name but some degree of categorisation is probably required, because we present an potentially enormous number of patches and the simple process of choosing from ‘piano’ sounds or ‘bass’ sounds is probably more likely to be of use to a user than separating Vox & Viola.
Sadly we have actually, conceptually, already ruled out the keyboard as a straight name searching tool, as lots of letters now do ‘interesting’, unexpected things.
We have another mode case, which is name search in list, to allow for finding ‘v’ sounds quickly. If I saw a zynth for the first time with a keyboard attached, I’d probably want it to find violins.
Modes are obviously a whole new ball game but we already have several possible use cases.
This sort of stuff becomes possible if we are considering a qwerty (sorry Jofe…) keyboard as an primary option, rather than restrict it to the webconf.
The categorisation option is a discipline to apply, and starts to imply the wider handling of patches & snapshots, do we need a hashing mechanism with a separate database to keep track of all this?
Yes I know go away and write it wyleu . . . I’ve done a fair few sound effects in the past and tagging is probably as good a solution as we came up with, ( and that wasn’t brilliant ). A fast preview was probably of more benefit for the actual process of selection and obviously that’s partially available now.
To have watched Lloyd Billing tearing apart a film library of sound effects was a joy to behold!
We are really bolting a grammar around zynthian functionality and perhaps we need a very clear definition of how that is to be implemented. If obviously has big and useful features for remote control of zynth’s which seems to be a direction we could be heading.
IT’s amazing what one extra feature exposes in this sort of stuff!
Seems the concept of ‘current’ recording and test voice as default, might address this initially. Last recorded might well cover most use cases as the play mechanism is delayed so isn’t, as yet, a suitable production/live tool except in very general background ambience or as a pure playback feature, but even then it’s useful. Backing tracks/Karaoke sort of apps.
This feature is very much a bolt on to current behaviour. I feel the overall Zynthian workflows could be significantly improved but we need to make the base system stable before considering such changes. That would be the subject of a different topic. Let’s discuss here how well (or poorly) the current key binding aligns with the current Zynthian operation.
As ever … Scroll Lock It would seem that like the Toggle aspect of insert for editing, scroll lock used to pin the cursor and scroll the page display data.
Probably a big thing on Teletypes…
I think we should be careful of inventing functionality to respond to stimuli, althou conceptually, it’s an interesting approach if we had the resource
I made the update and QWERTY is working fine for me. The only USB keyboard that I could lay my hands on was a gaming keyboard with flashing LEDs and I started to get the dreaded under voltage warning. So I’ll try again with a more frugal keyboard.
I’m tempted to use a USB Numeric keypad (17 keys) since they don’t take up so much space. Then I’ll need to patch the keybindings…
Yes, numeric keyboards could be quite useful and much more portable
Perhaps we don’t need a full keybindings configurator in webconf. A “keybinding” map selector should be enough. Keymaps can be stored as text files using some easy to read/write format (yaml?) and selected from webconf.
In fact, i would go a step forward and add the possibility of mapping “note events”, so you can configure keyboards as “piano keyboards” or more “imaginative” MIDI keyboard (modal scale maps, armonizer, etc.). Funny toys
Or maybe both? Method to create maps within webconf so that users may map their keyboard bindings as they like and a method to save and recall these maps. I created bindings based on the first keys that came to mind, influenced by my native (English) language and experience of similar bindings. I can’t imagine what key a native Russian speaker may wish to map the “Layer” button to. It may be beneficial to get community input to create default maps based on keyboard layout and language so that, out of the box Zynthian offers a binding maps that suits most users.
Small format keyboards are definitely a good use case for key mapping. I can imagine a USB keyboard built with a microprocessor (similar to the far more expensive, propitiatory X-Keys). I have seen various implementations and have had such a device on the back-burner for some time. You could have keys with legends and laid out to suit your use case.
The use of a standard (QWERTY or similar) keyboard is a good starting point and gives a useful input. In fact, I have taken my Zynthian apart this week and it is currently working with just HDMI + QWERTY keyboard so that I can continue to use it and develop ideas whilst I refactor the hardware.