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 . . . .
|‘MIDI’ B0 00 01|Switch to bank 2|
| ‘MIDI’ C0 02|Switch to the third patch in this bank|
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.
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.