Mhm, yesterday I updated to release 2022-10-07, restored my settings and snapshots, then there was the “Zynthian hangs/shutdown” problem again, like it’s described here: Multiple layers + external midi controller + stage piano? - #31 by pianissimo.
This happens when I try to work with this snapshot "
013-Full Piano.zss (24.2 KB) in this chain there is an ZynthAddSubFX inside which does not work anymore.
If you try to clean all, then you get the “ERROR” screen for a while. And if you directly try to shutdown Zynthian the device hangs.
This issue wasn’t there when working with build 2022-09-18.
Can anyone reproduce this problem?
Is the 2nd chain (ZynAddSubFX) working properly and you hear some audio output when there are midi keynote inputs coming in?
I’ll fire up the pedalboard; it’s a little bit easier to get MIDI into for reasons that are insanely complicated to explain…
I don’t get any response from channel 2 and I get xruns…
Strangely MIDI channel 1 does produce some low notes from the Bassgitaar Which is a bit peculiar.
root@zynthian-pedal:~# journalctl -fu zynthian
– Logs begin at Thu 2019-02-14 10:11:58 GMT. –
Oct 09 15:44:59 zynthian-pedal startx[467]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 15:44:59 zynthian-pedal startx[467]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 15:44:59 zynthian-pedal startx[467]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 15:44:59 zynthian-pedal startx[467]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Certainly not making any sound.
Can’t see any obvious python error reports.
Strangely MIDI channel 1 does produce some low notes from the Bassgitaar Which is a bit peculiar.
Can you rebuild the snaphot from scratch with a whole new instance? I know this isn’t ideal but it’s got me out of problems and there have been one or two problems with zss file hybridizing…
You can use the webconf to get fine details to get fine details of parameters if you need them…
Sadly MIDI monitor on the webconf is a bit, …unresponsive. There is a bug report on this MIDI monitor issue out there somewhere…
Now I will setup the release 2022-09-18 from scratch - let’s see if this issue will then be gone. Meanwhile I flashed the latest oct release from 2022-10-07 onto an older, slower 32GB Sandisk sd card. But there I got the same issue, no difference. I have in mind that there have been some sd card issues in the past. But this could not be the reason.
I’ve contrived several snapshots that produced a sort of electronic gurgle from Clacton where such issues are considered, occasionally without conclusion, with the presentation of the zss file…
It’s a feature of cutting edge research …
It does tend to concentrate the mind wonderfully during performance…
Just as a thought do you see this ( or similar without parameters …) in Audio Levels …?
Now it’s getting more confusing. I flashed the image 2022-09-18 back onto an empty card, setup Zynthian again and now I get the same issue like in the latest release 2022-10-07. When loading the above snapshot “013-Full Piano.zss” and trying to get some audio from chain 2 (ZynAddSubFX) it doesn’t work anymore. Why did this work before on? Damn that I don’t have the old sd card available, I only saved the snapshots. Maybe there is something going wrong when restoring snapshots on a freshly baked image?
– Logs begin at Sun 2022-10-09 16:47:06 BST. –
Oct 09 16:48:40 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:48:40 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:48:59 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:49:00 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:49:00 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:49:00 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:49:00 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:49:00 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:49:00 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 09 16:49:00 zynthian startx[503]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Do you get decent behaviour if you build a new chain from scratch after clearing all chains…?
i just got home and tried this. The snapshot loads as three chains:
- Pianoteq - no preset
- ZynAddSubFX - no preset
- FluidSynth - Bassgitaar3
- Chain 1 is cloned to channels 2 & 3
- Chain 3 has key range limit
- Stage Mode enabled
With chain 1 or 3 selected I hear the bass within the range as expected.
Adding presets to chains 1 & 2 I hear each as expected.
Is the problem that presets that were previously assigned have been lost?
[Edit] I see that the presets in the snapshot are:
- Steinway D Studio Recording BA
- fantasy choir
- Bassgitaar3
The Pianoteq preset may not be recognised since the Steinway D has become Grand Steinway D (New-York) (and Hamburg). Maybe this is the issue with that preset.
I need to do more investigation as to why zynaddsubfx preset isn’t loading…
Now I am back to image 2022-10-07 because the reinstalled image 2022-09-18 and the last one show the same effect.
I also setup a new snapshot with the same instruments (pianoteq, ZynAddSubFX and FluidSynth) and nearly the same settings (key range, midi channel cloning), but little different presets. The behavior is then the same - problems with ZynAddSubFX. And when trying to shutdown Zynthian you get the “ERROR” UI screen after a while.
Fantasy Choir is not the name of a preset in the Pads bank on ZynAddSubFX in the 2022-10-07 image.
If I setup a new chain from scratch with pianoteq, ZynAddSubFX and Fluidsynth I get the same behavior. And it does not depend on special presets. I took a different preset for ZynAddSubFX.
Are you testing with a fresh burned SD with the RC image?
https://os.zynthian.org/test/2022-10-07-zynthianos-staging-2210.zip
Also, could you report your hardware setup? A screenshot from the webconf dashboard will do the task.
Thanks
Yes I was testing with a fresh burned image 2022-10-07. The same effect happened with a fresh burned test image from the end of September. The curious thing is that while I was actually working with the image from end of September everything was working fine. The snapshot with now it’s issue was created during working with the september image. It seems that it has something to do with working on a fresh image and restored snapshots.
Sorry that you have to wait for further infos like screenshots. At the moment I am a little busy - writing now with my smartphone, sitting on the couch, missing playing my keyboards and Zynthian.
There may be done incompatibilities with previous testing branch versions. We aren’t able to keep compatibility with every iteration of development. I haven’t found any issues with migration from previous stable version.
To get the issue more isolated I burned the latest image from today (2022-10-10) and arranged a suitable test snapshot manually and freshly: Adding 3 chains (pianoteq 6.7.3, ZynAddSubFX and FluidSynth), added midi cloning from chain 1 → 2 and 1 → 3 and added some TAL-reverb to chains 1 and 2. Here is the corresponding snapshot:
001-Test.zss (25.3 KB)
The result is almost the same, now I can’t shutdown Zynthian, because I get the Zynthian logo screen with the red “ERROR”.
Here some further information about my setup.
I have a Raspberry PI 4 with 8GB RAM and bought the Zynthian kid 3/4 year ago.
This central midi rules help me to only let key note and sustain pedal presses from my Stage-Piano (Korg SV-1) go to Zynthian.
Debug-Log. The xruns occured during loading the snapshot, not while playing some notes.
Oct 11 19:20:13 zynthian startx[4020]: (==) Using config directory: “/etc/X11/xorg.conf.d”
Oct 11 19:20:13 zynthian startx[4020]: (==) Using system config directory “/usr/share/X11/xorg.conf.d”
Oct 11 19:20:14 zynthian startx[4020]: /zynthian/config/img/fb_zynthian_boot.png is 480x320 PNG image, color type GRAY, 8 bit
Oct 11 19:20:14 zynthian startx[4020]: Zooming image by 100%…done
Oct 11 19:20:14 zynthian startx[4020]: Merging…didn’t find evidence of prior run.
Oct 11 19:20:14 zynthian startx[4020]: done
Oct 11 19:20:14 zynthian startx[4020]: Building XImage…done
Oct 11 19:20:17 zynthian startx[4020]: libzynmixer: Registering as ‘zynmixer’.
Oct 11 19:20:17 zynthian startx[4020]: libzynmixer: Created input ports
Oct 11 19:20:17 zynthian startx[4020]: libzynmixer: Registered output ports
Oct 11 19:20:17 zynthian startx[4020]: libzynmixer: Activated client
Oct 11 19:21:53 zynthian startx[4020]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 11 19:21:53 zynthian startx[4020]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 11 19:21:53 zynthian startx[4020]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 11 19:21:53 zynthian startx[4020]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 11 19:22:42 zynthian startx[4020]: ZynCore: Setting-up 8 x Zynswitches…
Oct 11 19:22:42 zynthian startx[4020]: ZynCore: Setting-up 4 x Zynpots (zyncoders)…
Oct 11 19:22:42 zynthian startx[4020]: New instance of zynseq
Oct 11 19:22:42 zynthian startx[4020]: zynseq initialising as zynseq
Oct 11 19:23:13 zynthian startx[4020]: ./zynthian.sh: line 222: 4076 Segmentation fault ./zynthian_gui.py
Oct 11 19:23:13 zynthian startx[4020]: /zynthian/config/img/fb_zynthian_message.png is 480x320 PNG image, color type RGB_ALPHA, 8 bit
Oct 11 19:23:13 zynthian startx[4020]: Zooming image by 100%…done
Oct 11 19:23:13 zynthian startx[4020]: Merging…done
Oct 11 19:23:13 zynthian startx[4020]: Building XImage…done
Oct 11 19:23:29 zynthian startx[4020]: libzynmixer: Registering as ‘zynmixer’.
Oct 11 19:23:29 zynthian startx[4020]: libzynmixer: Created input ports
Oct 11 19:23:29 zynthian startx[4020]: libzynmixer: Registered output ports
Oct 11 19:23:29 zynthian startx[4020]: libzynmixer: Activated client
Oct 11 19:23:36 zynthian startx[4020]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 11 19:23:36 zynthian startx[4020]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
Oct 11 19:23:36 zynthian startx[4020]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! => delayed 0.0us
And I have a Pianoteq 6.7.3 License and uploaded binaries and licence key.
Now there are no more dependencies to older snapshots or images - the snapshot “001-Test.zss” was created inside the fresh flashed latest image.
I hope that someone could help to reproduce, dig down this issue and get Zynthian running again because I am using Zynthian in this kind of way as a keyboard expander. Sometimes on tests the last couple of days the chain with ZynAddSubFX wasn’t working and sometimes you cannot shutdown Zynthian or sometimes both.
Could you try with a really fresh image? I mean: no MIDI rules, no pianoteq license, no custom wiring layout, etc. Just the raw image. If you can’t reproduce the error with this, then the problem could be some of the customizations you use.
Thanks!
I will check this on the coming weekend. 
Are there some hints and rules available how snapshots are handled? if you will do an update from an older stable release to a newer stable release or from a test release to a stable release, etc.? Could there be situations where older snapshots get broken? What happens if patch names of synths change? I think there are a lot of dependencies
We are aiming to avoid breaking snapshots between stable releases but you are right there are many aspects that may trigger breaks. We want feedback from users in these next few days on their success and failure so that we can avoid such issues.
The snapshot does depend on preset names which is recorded in the issue tracker as a problem. We are likely to change that dependency in the future but it was not changed during this development cycle. (It was highlighted very recently so did not get resolved before now.) This can lead to snapshots failing because the preset does not (appear to) exist. This would be the same if you created a preset then renamed or deleted it. The manipulation of presets is a relatively new feature so this hasn’t been a big issue in the past. We need to resolve it but that is unlikely to happen before the stable release (unless @jofemodo decides it is sufficiently problematic). If engine default presets have changed name (upstream, pulled to Zynthian) then the same issue may occur.