I think I’m beginning to see your point.
This would be a complete paradigm shift for most of us, but I think there is a lot of truth in it.
I’m beginning to look forward to your POC 
1 Like
clearly not an AKBP
I play Nord Stage 3 and Kurzweil PC4 and during live
I always need to adjust volumes of each section to balance the live mix so when I use Zynthian I would need the mixer on touch screen if I play a keyboard without sliders or MiDi controls
It would be also useful to have on screen touch buttons to switch slow fast of rotary or touch buttons to change zs3 or snapshots
Hi all
I definitely welcome the idea of having a simpler Zynthian performance UI, a “Zinny mode,” as you describe, maybe even codenamed after some minimalist musician.
I’m not sure I fit the definition of the Average Keyboard Player, but I’ve certainly been chasing that kind of workflow for my “keyboard expander” use case. And I’ve seen many users here expressing similar needs, which makes me believe this direction would benefit both them and the project as a whole.
Let me state it clearly: the developments from @jofemodo @riban and other zynthianers are delightful to me, both from an engineering and musical perspective - even in areas I don’t expect to use, given my own approach to music-making. Still, my personal Zynthian eldorado is a simple, hassle‑free way to navigate and recall presets during performance (ZS3), based on chains I’ve carefully crafted over days or weeks, with fine‑tuned parameters, added FX, and whatever else is needed to match a particular gig (snapshot).
The idea of a 4‑button‑only interface also sounds appealing. I must confess that I often find myself lost in the expanded V5 keypad.
1 Like
Probably kind of AKBPs of some type …
@wyleu, after re-reading this thread, i realized that there is a very good definition for AKBP:
AKBP is someone targeted by the (still not developed!) zynthain JFK variant.
Cheers!
4 Likes
I agree with you - this is essentially just another way of presenting what already exists in the mixer view, but with some thoughtful options to keep things simple, consistent and performance‑focused, especially when the musician’s attention is on the keyboard rather than the sound tools 
Simple is not necessarily weak or poor…
1 Like
That would be indeed my basic concept for a “modular” Zynthian GUI and UX.
Should a similar approach prove to be cumbersome to code and maintain, I think that it wouldn’t even be required to have total freedom of functional configuration, but maybe a limited gamut of typical use profiles would suffice, like, say:
-
Zynthian Full;
-
Zyn Expander (with multichannel mixer view, chain options, FX and engines parameters: essentially a sort of evolved and focused Oram);
-
Zynthian Live;
-
Zyn Sequencer;
-
Zyn Audio (FX Processor - Audio Recorder).
The ability to switch between usage profiles on-the-fly would be amazing, with or without (even better) system reboot.
I obviously ignore the amount of code refactoring that would be necessary to this end, thus its possible viability is up to the evaluation of our generous developers. 
Cheers 
1 Like
I keep coming back to this with the feeling that we’re already imagining it as more complex than it needs to be, perhaps because we always want to preserve full flexibility.
The simplistic Live mode described by @jofemodo at the beginning of this thread is really what’s new here. With the aforementioned highly curated library of snapshots, we could deliver a powerful music machine for people who need a more immediate approach, with far less frustration (for owners and supporters) in getting it to deliver the great technology we know is already there. There are multiple reasons why this makes sense, as we’ve seen in other recent threads.
I wish I could embark on such an effort. I’ve even spent some time lurking on GitHub trying to figure things out, but it’s clearly out of reach for me. So all I can do for now is keep lobbying and be patient with my musician friends who keep bugging me with links to what many pros use, Gig Performer and similar apps.
I still believe Zynthian is the right way to go.
4 Likes
And this i feel i’m often exposed to. Not so much in my musical life (cause it is not that extrovert) but in life in general.
I’d certainly be a user for a JFK Zynthian. I’ve been lurking here for years while still using my original 3.5” 4 Encoder Zynthian as a sound source. I like the idea of having a very stripped down UI for live playing. I have the luxury of playing with a band that has real drums, guitar, bass & horns so the audio recorder, sequencer & looper aren’t important when playing live.
3 Likes
Just to add my two cents…
We’ve been using a Zynthian in the band (live) for several years now. We’ve put various sounds into the channels in a preset and set the volume levels. The sound is changed by selecting the channel. In addition, the volume of the master channel is mapped to a slider on the MIDI master keyboard (sometimes also the filter of a synth to the other sliders).
These functions have proven to be the most important ones. The second keyboard is an older Roland Juno, which has very different volume levels for each sound and these cannot be easily adjusted – not ideal. In this respect, we are happy with the current implementation – it should not be made more complicated.
Regards,
Holger
2 Likes
I think there’s no need to reinvent the wheel here. Zynthian already has most of the things an average musician might need on stage. The problem arises when it comes to quickly changing the active patch. Simply put, the current GUI (despite the excellent ZS3) does not provide that level of flexibility. The way I see it, the easiest and most straightforward solution would be to create a grid view as part of stage mode. The grid view would be populated with predefined ZS3 patches, and a simple touch on the screen would change the active patch/instrument.
2 Likes
One thought regarding this concept.
My impression is that the idea is akin to, “less options == more suitable for stage use”. These are definitely related, but I don’t think it quite hits the nail on its head.
Imho stage usability is rather defined by two things:
- Easy, immediate access of important functionality from anywhere.
- Predictability: every control will always do what you intuitively think it does (or doesn’t do). Likewise, for anything you want to do, it’s clear which control would do it (and which ones wouldn’t).
Reducing the accessible functionality is one way to optimize for these criteria. However, there are other avenues as well.
Here are some thoughts on what might also help - much of this could benefit Groovebox Mode (Zynthian AFK?) as well:
- Clear, consistent, traceable, and ideally not very deep navigation trees.
- Reducing the amount of “context” that a user has to keep in mind when using the device. For example, instead of switching between audio recording mode and MIDI recording mode, why not record both by default and leave the choice about what to use to “post-production”.
- Using the same interaction patterns everywhere. The user should have to learn only a few central ideas, and then apply those everywhere. For example, the same icon could be shown in the same place when you select a GUI element that will open a child view when pressed.
- Not overloading the conceptual use of physical controls. For example, a given encoder should only be used for navigation, or only for parameter control, and never switch context between these two modes. Or, a given button always has a global function or always a view-dependent function, but never a “fallback to global” in some views. Or, turning an encoder could map to up/down arrows on the button grid or to left/right, but that shouldn’t change based on the view.
- Simplifying from short, bold and long press to just short and long press.
- Having at most one alternative button assignment. Whereas two different functions for long press vs. Alt+short press adds too much mental overhead and potential for errors in the heat of the performance. The user should never have to think about which one of these to use.
- Always showing an indicator on screen next to the physical controls (encoders or a small set of multi-purpose buttons) that make it clear what they will do. This may limit flexibility in which hardware is suitable for this UI, but will improve usability in return.
- Deciding whether your UI canvas scrolls toward the right, or toward the bottom, or perhaps scrolls in one direction with encoder but uses pages in the other one, selected by arrow keys. Always sticking with that concept, and determining the layout/function of physical controls accordingly.
- Color-coding UI elements to make it immediately clear what’s being edited.
- Rejecting the idea that users have to read the manual to discover and successfully use most of the useful features.
- Moving away from a “select an item, then edit” flow toward “turning or pressing (in a given view) has an immediate effect”.
I’m sure there’s more, this is just the immediate stuff that comes to mind.
I think it may be insightful to investigate the Studiologic keyboard (Numa X, SL88) interface for inspiration. Like Zynthian, it relies on a relatively limited set of (largely encoder) controls. But it also seems to strike a solid balance between ease of use and functionality.
Finally, I’d like to leave two links to KDE’s Human Interface Guidelines documentation that I think are relevant also in this context. KDE has a mantra of “simple by default, powerful when needed” and like Zynthian, is facing the challenge of making powerful features accessible to regular people. These are some ideas about how to deal with this:
Thanks for tuning into my soapbox. Happy keyboard-expanding!
8 Likes
Hi @jpetso !
“Not very deep” => we need to “prune” some options 
Again, the easiest way of reducing context is reducing options.
Recording MIDI is not something musicians do in stage. It’s more a production task, so we can “prune” it. Recording audio can be interesting in rehearsal, but not in stage! You don’t want to risk your performance having XRuns. The guy in the mixer table can do the audio recording way better and without incurring risks.
We try to do this all the time. It’s not so easy in a limited physical UI with 4 rotaries and 20 buttons (V5)! Still less easy in a V4 UI with just 4 rotaries and 4 buttons. We do our best to find the balance between flexibility and simplicity.
Please, remember that zynthian is not a desktop or tablet application. It’s a dedicated physical device with a minimalistic UI. Reading the manual is mandatory, like any other similar device.
Over loading functionality in the limited amount of available actuators is something we can’t avoid.
Of course, there are always room for improvement and we are thinking all the time about how to improve workflows. Don’t doubt for a moment that we invest many many hours thinking about this, imagining workflow interactions, trying to find better ways, etc.
But devil is in the little details and designing good workflows for a device like zynthian is all but easy. We are always open to improvement proposals! Please, make your proposals! But they have to be realistic and doable in the current framework. Step by step.
All the best,
Agreed.
Evil is in the little details. Wishfull thinking is easy, defining and implementing is hard. Zynthian has limited resources and priority is performance. It can do many different things, but thinking that It can do everything at once is an error. It can’t. No if you want to ensure there are no XRuns.
Anyway, you need separated workflows to play audio and MIDI…
1 Like
Would the JFK, be expected to record?
Would MIDI recording be such an imposition?
The recording workflow outside of the V5 implementation without specific buttons allocated to it is non intuitive, and the workflow around performing recording confirmation, both whilst recording and post check is rather involved. Especially if memory sticks are used. Locating what is where can be confused with webconf seemingly not able to offer selection of the current volume.
Apologises for getting well off track but a cut down live machine should take a view on recording.
The V5 workflows are available using the V5 touch buttons and i have plans to improve It.
You have to be realize that maintaining several UI workflows with the same codebase is not easy.
Making available the 100% of features in the limited V4 UI is really hard. Having 2 touch interfaces (V5 buttons and touch widgets) doesn’t help. We should converge, ideallyntowards and V4 owners should realize that some features won’t be easily available on these devices.
regards
I fully agree. It’s not a criticism, I remember when the ability to record first appeared. The efforts to avoid becoming a DAW were strong, but in the very success of what is now being attempted there are some issues that require careful consideration.
I have done a lot of field recordings on zynths and if it is to be considered as a facility then looking at popular devices like the zoom recorders would probably pay dividends.