A full zynthian has audio and MIDI record and playback features, including support for mulitrack. This gives a substantial set of options for recording, including field recording, rehearsal, show, etc. I don’t think this is a requirement for JFK which is specifically a keyboard expander. I would expect JFK to offer the ability to play instrument chains (MIDI->MIDI FX->Instrument->Audio FX) with fast selection of presets and chains/instruments. It may not have most of the functionality of zynthian exposed (sequencer, mixer, recorder, player, etc.) These features may still exist in the base code and be accessible from API (e.g. CUIA) and hardware controller device drivers so that a user could configure a snapshot, use it to play from keyboard with simple UI and trigger these other features from external hardware devices but without GUI integration. (Hardware controller would be expected to have full control and indication integration, e.g. a launch pad that can launch sequences and indicate their play status.)
For me, not.
Only audio and MIDI play.
It could be useful for my live.
For my live, further request maybe too much and non appropriate in this topic, would be show PDF or jpg via HDMI.
I’m mostly interested in full Zynthian, so I’m not going to argue strongly for any features of the simplified product.
However, consider that even the most minimalist portable pianos tend to have a “user song” a.k.a. recording function of some sort. Clearly there is some sort of demand for this even by people who buy devices “just to play”.
There is likely some truth to the assumption that, say, 80% of people only need 20% of all features. But the set of 20% features will still differ from person to person. Some may ask for simple recording and playback. Some may ask for a separate metronome output. Some may ask for velocity curves or even per-key velocity adjustments to deal with the hardware they have. Some may expect being able to mix in Bluetooth audio for practicing. Some will probably need advanced settings for their MIDI pedal setup to control the performance. Some need to show lyrics and chords changes on screen, perhaps controlled via pedals.
If you simply define your target user persona as a musician with virtually no needs other than playing presets, you may end up with a lot of people that are interested in the rough idea but ultimately abandon this mode for not catering to a slightly specific need that’s a dealbreaker for them. When the next step up is a mode that offers the functionality, but is not fit for live use in the same way, that’s a recipe for disappointment.
I’m not advocating for the inclusion of every single feature, but pick your target audience wisely and make sure you thoroughly understand all the stuff they’ll need. And consider the fact that many manufacturers are putting out devices with a beginner-friendly efficient UX that are still somehow packed with features, because their users are asking for them.
Yes, and I know that making flexible devices appear simple is hard work with difficult trade-offs to consider. Thank you for spending your time on this. I’m not sure if I come across as an overly generic whiner, but I’m actually quite happy about what ZynthianOS is right now already, and excited about what you’ve got in store for Vangelis.
I have come to learn that both of you carefully consider all these factors, which may not always align with my own ideas but are well-considered either way. Perhaps one day I’ll find enough time to contribute something of value and bridge that gap.
Why not, for the future, to define a set of CUIA that a user can load to have on a V4 all buttons existing on V5? I mean a kind of keys extention that you can have simply connecting an USB PC keyboard,
This would allow to have a compact unit (V4) for live and an extending interface for production (V4 + keyboard)
That is already (kinda) implemented. There is a keybinding profile for numeric pad which maps the buttons from a USB (or Bluetooth) attached numerical keypad to CUIA functions. It was written before V5 so a dedicated V5 emulation profile may be beneficial. At the time we did consider producing a dedicated hardware keypad but it didn’t seem to be a viable product.
What if JFK were architected as an “app”, but I can also install other specialized interfaces, in the same way that I can add a device driver?
For example: At some point in the indefinite future, I may be interested in making a Zynthian version of the Bastl Midilooper, except backed by Zynthian chains and other common infrastructure. This may not fit with the vision for Zynseq, probably not with this JFK concept either, or if it does then it needs to be discussed and changed/downsized so that it does.
But it would be super nice if one could take over all of the buttons [1] and screen, reuse all the ZynthianOS infrastructure, and put a custom specialized interface on it. I could prototype the Midilooper and if something works out, figure out which parts are useful to port to Zynseq. Someone could port of the Dirtywave M8 interface and back it by Zynthian engines. Obviously some kind of tightly scripted workflow interfaces. Probably lots of things I’m not considering right now.
[1] Obviously there still needs to be a standardized way to switch back out of the “app” into a different mode, and presumably other global settings should be available as well.
That sounds similar to the long-held aspiration to separate the UI from the back-end (model / view) which we started with CUIA and continue with state manager but have not completed the separation. There is a thread on this forum discussing API which works benefit this approach. My high-level preference is to have a completely standalone, headless module and the UI as another standalone module that communicates entirely via API but it attempts to move that way have be influenced by the need to optimise for the available resources.
A pure MVP approach is attainable but likely to reduce capability due to increased overhead. I works still want to move closer to this though, but probably retaining some direct UI API elements (which we planned to do by retaining CUIA and implementation a separate API).
