Hello,
quick question:
Is it possible to use/run other GUIs on zynthian OS to connect and control zynthian base stack?
E.g. using Juce or QML/Qt to design UIs for selecting installed engines and sounds and accessing parameters?
Thanks again for making this great project opensource!
Hi!
There are a lot of discussions along those lines, short answer is: not right now, unless you want to mess with tkinter and the current codebase.
There is an interest in refining the GUI design and the user experience, so I’d think at this point any ideas/designs you can bring to the table would be greatly appreciated.
One thing to keep in mind is that the current motto is: keep the interface compatible with non-touch devices, as that is the current design ethos. Of course interaction with the touchscreen can be an option, but there would need to be a way of doing that withing the encoder controls.
For my own ideas, i have a thread discussing a possible alternative view and setup for the controller pages in the engine view.
Hi Pastitas,
and thanks for your reply!
Optimizations sure is fine, but there will always be preferences and drawbacks (mostly of course subjective and due to different usage or context).
So instead of adjusting current UI, an abstraction for offering the possibility to make other UI’s of certain Views (much like skinning Winamp or redesign/order Wordpress pages) would allow for most flexibility using Zynthian and its modules/componenets in a much broader way, also regarding possible hardware manufactures who like to do simplified, specific devices with it (like only a recorder/sequencer or only a synth player). Allowing other toolkits like QML/Qt to provide either highly reduced or even more sophisticated UIs would be amazing.
Therefore how difficult would it be to do a demo of such a usecase, like e.g. a “qml dummy ui view” to simply list all available installed synth engines, even if for now that would be hacked into a (forked) code?
The currently implemented API is incomplete hence you can’t drive all of Zynthian from an alternative UI client.
It is of course possible to write an alternative UI but that would require substantial reimplantation of the application. In fact you may think of Zynthian as a wrapper around engines with its own routing management and filtering, plus some extra bells and whistles. So the Zynthian UI is kind of its main function.
Thanks riban for the reply!
When you say incomplete, is there any part of Zynthian/the API that a programmer could use/connect to and test-demo an alternative UI element?
Like how would one go about letting Zynthian run and do its wrapping then use some (not yet existing, but potentially added) part via a new UI running parallel, like only the synth engine and patches listing and using some controls? so the new UI could support at first only the needed Views and there also only a subset of needed parts, while simply having the other menu options or controls not shown /accessible yet, until a proper API rewritten exists?
That way instead of rewriting all parts at once, it may be feasable to carve a path to rewrite the API in a way to use it first only e.g. as “preset player”, no sequencer, audio recording, etc.
Where would the programmer start best codewise?
The reason I ask is I know developers who could help a) with the proper API adjustments and b) showcasing module by module (or view by view) how to utilize a new UI without the need to remove or right away replace the current UI.
To give a superquick idea, here is a very simple demo UI (of course no functionality) what this could look like using QML/Qt:
We could then quicktest and rapid develop many UI ideas if we were able to then also connect them to actual be useful / functioning without programming the whole logic yet again.
So thanks again for any help to get a deeper understanding of Zynthians current inner workings and future potentials. 
I’m not sure what benefit we are looking at here. QT is a pretty bloated UI which conflicts with the Zynthian aspiration of proving as light weight UI as possible to avoid excessive load on the available resources. I don’t see much benefit in forming development to use an alternative GUI framework. It would make more sense deciding that an alternative (to TKinter) framework had some benefit then concentrating effort on developing that
Now I’m not sure what your opinion about a specific UI toolkit (e.g. Qt) has to do with the benefit of making the Zynthian API in general more UI-agnostic, to allow UI development more easily.
I think the point @riban is making is that the specific framework for the GUI is not the blocking issue here, but rather the fact that the current GUI is deeply engrained in the inner workings of the device, and that the only thing to do in terms of UI-backend separation is working on the missing parts of the API.
Also please keep in mind the resource usage consideration is an extremely important one when talking about a computer such as a raspberry pi, and I do agree that qt, gtk or something that extensive seems like adding too much overhead.
What you’re refering to (the separate ui design from the main interface) could be done, if you’re willing to work on the API, and this is a community projecy but there is still a clear leader that might not vet some stuff.
Feel free to fork stuff, but please remember to share your advances if they do work alongside the project’s guidelines.
Indeed, I could have said, tldr: anything is possible, nothing is easy!
Contribution and collaboration is welcome. We have previously discussed untangling the UI/core (search this forum / GitHub issue tracker) and agree it has benefit but it is a substantial challenge which is not currently top of the priority list. If it’s not (too) broken then don’t fix it (much).
I like this description 
And a complete zynthian UI includes the rotary+push physical interface.
If you want a dedicated/specific synth engine running on a RBPi with a highly customized UI, then you should think of bypassing the zynthianOS.
Anyway, we would like to extend the zynthian API, what should allow running some kind of “simplified/customized UIs”. I mean, for instance, having a super-simple stage-keyboardist interface, etc.
Regards,
I understand what you are saying and agree 
This is why I’m interested to find out what parts of the API would need help to be extended/completed and how to do that in the best way for the project, to avoid any fork simply due to not caring about what the zynthian devs actually recommend how to do this API extension/advancement properly.
Any example of an already existing part of the API would be nice to be pointed to and maybe a rough overview of what parts are either complete missing or not fully there yet, and how to revise them in a satisfying way.
Regarding the API improvement itself:
Currently we have implemented most of simple, non-parametric, actions. In fact, we use “CUIA” (Callable UI Actions) for naming this limited API.
CUIA has the advantage of being easily usable/configured with several interfaces:
We could follow this path and add more CUIAs, including parametric ones, like having full parameter control via OSC. This would be quite easy to implement.
If we want to go beyond this, we need to define and implement a parametric call-answer API, what suppose a good amount of work.
Current UI code uses lists with positional parameters everywhere, what is fast, but not well suited for defining a good, friendly, API. Changing to dictionaries could have a performance impact and adding a translation layer would increase code-maintaining work.
Anyway, i’m pretty sure that we will have a full API sooner than later. It’s a question of priorities and time availability. Step by step.
Regards,
Thanks for pointing out CUIA, I found some topics about it here in the forum. Will try to get an overview of how it all relates (OSC, PureData, Cuia, Mod Dep,…) and likely have some questions
Is anyone working on this project part- or fulltime, or only in their sparetime?
In fact, I’ve just thought that maybe a recent discussion on Open stage control and touchosc might apply, the only challenge would be getting the thing to run on the screen of the zynthian and mapping the required values via midi
I thought about your explanation of API and CUIA.
Here is a simple suggestion that from my understanding should work. Most GUI part either has lists and actions. The latter one can be handled well with CUIA. Regarding lists, I would see this as a list of parameters, where any control mechanism such as GUI, OSC etc should be able to edit this but also get updates if a value is changed by another source.
This could be solved by a simple API building upon 4 functions:
The listbox could then be coded in a very generic way and only this internally handles the positional parameter of selected index. To allow for various sorting mechanisms, I would introduce a translation layer of API index to listbox index. This could be done with an array, where index of array is fed with listbox index and the data at the index is the API index. This solution would be very fast! Applying a different sorted view would mean rebuilding this array but the access again would be fast. Unfortunately, what I have seen listbox of TKinter does not support a generic class or something more sophisticated for the data entries or did I miss something? In C# one could directly store the API index in the item object along with the name and use one for displaying and the other for processing. If something similar would be possible with the TKinter listbox, we could omit the array.
Maybe I am missing something that is also critical for the API but I am open for discussion, this is just a suggestion based on what I have read. Is it correct that enginges and FX have a predefined set of parameters that does not change in terms of parameters being added or removed? This would require a more sophisticated API approach…