Running on desktop (for Development) [WIP]

[VoidField101]

I noticed the Emulator is no longer being developed and pyqt4 is also no longer supported and seemingly not easy to install on a newer system. I did some initial testing porting it to pyqt5 but I didn’t get the ZynthianUI running.

Instead of focusing on the emulator I found multiple issues keeping Zynthian-UI from starting on my desktop OS which is currently Fedora 38. This thread is more to document the issues and how I am fixing them (probably going to make a PR when I’m done)

Code snippets that are currently in the post will be moved to a Github fork soon

1. Shellscript
Based on then zythian_gui_emu.sh in the zynthian-emuface repo I created the following script:

#!/bin/bash

source ../zynthian-sys/scripts/zynthian_envars.sh

export DISPLAY_WIDTH="480"
export DISPLAY_HEIGHT="320"
export ZYNTHIAN_TOUCHOSC=1
export ZYNTHIAN_WIRING_LAYOUT="EMULATOR"
export RBPI_VERSION=""

cd ../zynthian-ui
exec ./zynthian_main.py

The RBPI_VERSION is necessary due to an “in” check in zynthian-ui/zyngine/zynthian_engine_jalv.py: line 80 which crashes unless this variable is set.

2. LV2 Plugins not found causes crash
zynthian-ui/zyngine/zynthian_lv2.py: line74 tries to get the last file modification time of the Jalv lv2 config, which doesn’t exist. This causes a crash.

My current workaround is to just set mtime to 0 instead of using os.stat. This is only a workaround and not a fix. Ideally this would be changed later to happen when the file is not found.

3. Zynthian Gui config crashes if Zyncoder is missing
Mainly because certain variables are undefined if that happens. I just added default declarations in zyngui/zynthian_gui_config.py: 694:

 num_zynpots = 0
 num_zynswitches = 0
 last_zynswitch_index = 0

4.1 Zynmixer can’t be compiled
This is mainly caused by the distro I’m using (Fedora 38) shipping Pipewire-Jack instead of Jackd.
Pipewire still provides Jack development libraries but the CMake file doesn’t know how to find them.

Fix: Use PkgConfig to find the proper Jack library options:
Modified zynthian-ui/zynlibs/zynmixer/CMakeLists:

cmake_minimum_required(VERSION 3.5)
project(zynmixer)

include(CheckIncludeFiles)
include(CheckLibraryExists)
find_package(PkgConfig REQUIRED)

pkg_check_modules(JACK REQUIRED IMPORTED_TARGET jack)

add_library(zynmixer SHARED mixer.h mixer.c tinyosc.h tinyosc.c)
target_link_libraries(zynmixer PkgConfig::JACK)

install(TARGETS zynmixer LIBRARY DESTINATION lib)

There are still some issues like the Python wrapper expecting zynmixer to be at a absolute path which can’t be changed.

[jofemodo]

Hi @VoidField101 !

Nice to see you are re-activating this. It’s been a long time i stopped working on it because i always work with several real zynthians over my desk, with all the stuff connected, etc. so i always test the code in, at less, 2 different devices (V4 & V5 now).

When we released the V4, i realized that having several hardware interfaces increased the complexity and maintainance of the emulator, so i stopped working on it and decided to spend this time improving my development workflow with real zynthians.

Developing on a “desktop zynthian” can be more agile, but before committing serious changes, you always have to test in real devices, so you loose part of the benefit. Anyway, feel free to find your path to zynthian development. Your fingers are really welcome

If you do so, i would recommend to rewrite the “emulator” from scratch using the CUIA system, so the desktop zynthian wiring layout is configured as “dummies”. This will simplify maintainance a lot.

Alternately, you could create a virtual MIDI controller and program a driver for it.

BTW, using debian instead of Fedora will ease the setup quite a bit. Up to you!

In any case, please, don’t hesitate to ask your doubts in this thread.

All the best,

[VoidField101]

I got a V5 recently, which is why I’m actually interested in starting development. However I can’t really test for the V4.

My first try was to get the emulator running, I actually succeeded in getting a window using PyQT5 but without getting the Zynthian UI to run there isn’t much the emulator can do and in fact it crashes when trying to move one of the emulated encoders.

The changes I currently did to the build scripts aim to make the build system more “durable” especially if people want to change to the Pipewire-Jack implementation in the future. Also I didn’t mention it but on newer CMake versions I get a warning that the previous 3.0 version compatibility will be deprecated which was fixed by the same change.

My assumption already was that I need to move to CUIA because I couldn’t get the zyncoder to compile properly without some hardware specific header files.

PS: I guess it would be better in general to get it working on a VM, but at least for me working locally seems a bit easier. At least for now except for the Pipewire vs Jack issue, which in the future might be more problematic on other distros too, I didn’t encounter any distribution specific issue yet.

[VoidField101]

Small update.

I got the UI to run without crashing:

I also moved some of the patches to a github fork although some fixes aren’t up there yet so that repo won’t get to the same result yet. GitHub - VoidField101/zynthian-ui at emulation-fix

The UI is pretty much useless at the moment because there are still a lot of exceptions thrown in the python script causing non of the options to actually work. During startup zynthian also tries to execute systemctl commands which isn’t ideal.

Depending on how much I can change with environment variables I may have to try to get the UI to make less assumptions about the underlying system.

Another Issue I encountered is that embedding the window in the emulator may be more difficult now that many distros use wayland and I would rather not make the assumption of it running on X11 forever. So some solution to draw the UI into another window has to be worked out.
One Idea might be to move the entire Zynthian UI into a qemu environment and render the graphics output into the emulator window but that is probably more work (and I don’t know how much time I can invest into this right now, but I might toy with it a bit).

PS: Maybe relevant for 64-Bit migration I also encountered a segfault because Python seems to assume 32-Bit value parameters for FFI if not specified otherwise, which caused some 64-Bit pointers to be truncated to 32-Bit and therefor be invalid in the C-Library. Specifically this was caused in zynaudio player with my version of the fix here: Fix segfaults in zynaudioplayer · VoidField101/zynthian-ui@211334a · GitHub

[jofemodo]

Hi @VoidField101 !

The 64-bit related issues should be solved in the testing branch. Aren’t you running this branch?
All developers should run testing branch and any new development/improvement should be done from testing branch as a base.

Anyway, as i try to explain in my last post to this thread, we decided to not keep maintaining the emiulator as it take too much effort and the development environment differs too much from the real thing. The “qemu” environment is more interesting and indeed we use it for building automated SD-images. Also, we have some plans for implementing an automated testing environment using CUIA and log-parsing , that would run on qemu environment. This would really help us to detect bugs and improve the code.

Regarding development itself, i really love to work on real zynthian devices connected to real gear. This gives me an unique feedback that it’s not possible to have with emulated environments,

Perhaps Mr. @riban have something interesting to add to this conversation, as his development workflows differs quite a bit from mines

All the best,

[riban]

I never use emulation. I use a laptop (usually a Chromebook) to ssh to a real Zynthian. I enable VNC and use the web based VNC Viewer for UI interaction. I use VSCode connected via ssh for code editing and debugging. This can (and often is) done remotely, e.g. sitting on a comfortable sofa and on occasion, from the other side of the world!!! Of course I do have to go to the device sometimes for physical testing, e.g. sound, touch, encoders, etc. I had no luck with the emulator and frankly, the cost of a raspberry pi is much less than the cost of my time to get some emulation working and it gives real performance testing. So I always test on a real Zynthian.

An advantage of testing remotely with VNC is that I see some of the touch / pointer / keybinding issues that sometimes arise (as well as it being more comfortable lounging on a chaise longue).

[VoidField101]

My fork is using the testing branch from a week ago. I noticed that it didn’t crash on an a 4GB Raspberry Pi 4 with a 64-Bit OS but it does crash on an 32GB amd64 machine.
It depends on where the heap of the zynaudio library is located in virtual memory space. If the pointer value to the audioplayer can be represented by 32-Bit it works, if thats not the case only the first 32-Bit will keep their value the rest is 0.

[wyleu]

Actual zynthian development . . .