Hi there,
So it’s pretty rudimentary right now (just runs systemctl start and enable and stop and disable for the services) and checks for the service status.
I have made a pull request with the changes.
I don’t know if maybe this is more useful if i add an install VNC option first if the service is not installed, i was just trying to get acquainted with how the menu system works.
This does persist between reboots but it does so by using systemd.
What happens if you exercise the setting when vnc is not installed? Does zynthian_gui issue any errors or warnings (command line / log)?
If this feature is added to stable build then vnc should be installed by default (rather than installation triggered by application). That is the standard way to do things here.
I llike the use of systemd for persistent status but maybe @jofemodo knows better, e.g. it may or may not be desirable to save such a setting in backups in which case the zynthian configuration class would be used.
I wonder how many remote access methods we want to add here? vnc, ssh, x-forwarding, rdp, parsec, letmein?
I wonder how many remote access methods we want to add here? vnc, ssh, x-forwarding, rdp, parsec, letmein?
I think that VNC is really great to remote Zynthian UI via a computer, a tablet or a smartphone. For example when you want your zynthian in a distant position, like a pedalboard or a rack.
The main thing with VNC is that it comes builtin into the pi, somewhat at the very least. I just went with it because the installation was simple and it’s better then x-forwarding for some debugging.
I will check now to see what is the behavior of the zynthian if the service is not installed (maybe only show the menu if it’s installed or add it to a hidden developer menu?)
Hi,
do you know how much cpu/ram ressources this service use when it is enabled and used ?
Here are the system stats (filtered by “vnc”), when the VNC service is running with 1 client connected:
And with the service stopped:
By the looks of it it really does not mean much effort for the Zynthian so that’s a good thing, thanks for the question!
Thanks for response 
Yep, it’ seems no to be that much ressources consuming. Good to know.
Excellent. I am running VNC on a second X-Display so that it does not display the Zynthian UI but can be used to display output from synth UIs, or in my case QJackCtl. I just created an xsecondscreen.service to run that. I wonder if it would be possible to integrate that in the admin setting.
I could totally integrate that as an option but I need @jofemodo approval for this, as I’m basically doing it on my own, I’m not 100% sure if it can be integrated as is, as @riban said before.
That’s actually one of the use cases I had in mind in fact, so it could be very interesting.
The Pull Request does all the approval stuff… 
I really like using VNC especially in read only mode as a screen echo.
It’s also really handy with multiple zynthians. .
It’s a pain that android vnc client don’t support zero config networking ( avahi & bonjour) by default.
Games of hunt the ip…
Hi @zynthianers!
I finally integrated the “VNC Server” option in the UI’s admin menu. @Pastitas, I had to change a few things for using TigerVNC (instead of RealVNC), that is free software and it’s included on the raspbian repositories.
Simply update and test!
Notes:
You should connecto to zynthian.local:5901 and start your engines after that.
The password is the same than system password. When updating the system password from webconf, VNC Server password is changed too.
This integration is thought for running the engine’s UI on a remote display, not for running the UI itself. For that, you should start a VNC server instance for sharing display 0, or create another remote display and tweak the zynthian UI service. Up to you, but doesn’t use the display :1.
Enjoy!
Ok, I tested this with an updated Zynthian but I’m not getting this to work for me…
After enabling the VNC server from the menu, I can succesfully connect with Tiger VNC Viewer to zynthian.local:5901 and I’m presented with a console screen of the zynthian. So far, so good.
If I subsequently start a Zynaddsubfx layer on the zynthian, it works as expected on the zynthian, but no ui is launched on the vncviewer.
If I peek from the console in the processes launched on the zynthian, I see that this is not a surprise since it is launched headless:
# ps aux | grep zynaddsubfx root 14331 4.6 1.1 138244 94076 pts/1 SLsl+ 16:30 0:00 /usr/bin/zynaddsubfx -r 44100 -b 256 -O jack-multi -I jack -P 6693 -a -U
(The -U is the flag to launch without GUI)
so it seems that config_remote_display is not detecting that I have a remote session running.
From the console I also spotted this:
root@zynthian:~# env | grep VNC
ZYNTHIAN_VNCSERVER_ENABLED=0
Which I suspect needs to be something else when connected through VNC.
Should I connect in a different way, am I doing something else wrong or is this an issue?
Hi @twelve!
It should be working now. Please, update and test.
Ahhh! And read this too:
https://discourse.zynthian.org/t/cant-use-vnc/3407/44
Enjoy!
Hi @jofemodo,
Thanks a lot for this!
I can confirm I get a working engine UI of ZynAddSubFx working now through VNC (using tigervncviewer)!
It seems that the quality and interactiveness before tweaking with display and compression options seems to be quite slow this way.
The quality of the display and the interactivity experience with the NoVNC connection seems to be quite better out of the box, quite useable.
It’s not quite clear to me what UI’s will show up and which ones do not, I assume LV2 engines won’t show (yet).
For now I just managed to get 1 UI Instance of ZynAddFx showing up, not of any other engines yet.
Again, thanks!
Currently you can access the native GUIs from these engines:
I think we can easily add “setBfree”, although it’s not so useful as getting the LV2 GUIs. This is a little bit more challenging, but the incentive is high because this would cover most of interesting engines: Dexed, OBXd, Noizemaker, Helm, etc.
And the way to follow is not so hard. Simply we have to replicate the CLI functionality from jalv on the jalv.gtk and jalv.qt programs. I would do it ASAP.
Regards,
This is great! yeah, i figured that RealVNC was probably not the best option, but I’m glad it was useful anyway!!
The ZynAddSubFx UI is quite nice and useable for me (and I do prefer it a lot over the older UI) using the NoVNC web UI, even over Wifi.
I fully agree that the LV2 GUI’s would add the most value most quickly as it would add the UI’s of the most used engines!
Hi @zynthianers!
I just upload some changes that allows opening a bunch of plugin native GUIs remotely. For instance, using the new VNC interface
I’ve tested with a few synth engines and FX plugins:
It works quite well for most of them, although we haven’t full bi-directional sync between the native GUIs and Zynthian UI. I.e. moving a controller from zynthian UI will change the GUI’s controller, but moving a GUI controllers don’t move a Zynthian UI controller. I hope to improve this very soon.
Also, we have some important absences, like:
Simply update and enjoy!!
Outstanding!
