I built a favourites snapshot file which runs 3 engines:
ZY, FS and BF .
Each of them has up to 18 ZS3 program changes programmed.
Unfortunately after playing (and changing programs) for a certain amount of time (10minutes or the like) a random program change makes the zynthian crash.
Only repowering helps.
The zynthian log in debug mode doesn’t show anything.
I am runnning the stable branch.
Is this a known issue?
When can we expect a more stable version?
I experience more xruns than 2 years ago as well.
It’s on a V4.5.
You say the zynthian-ui log doesn’t show any error? This is strange. Could you check that Jack is still running? Could you check if it’s a “engine” crash? I start to suspect the last version of ZynAddSubFX is not totally fine. Could you check the system log?
What sdcard are you using? Could you test with a new one? Samsung EVO+ and Sandisk Ultra/Extreme work quite well for RBPi normally.
Actually, I had a crach on a (not latest) testing on a V2 as well, which was running PT with 12 zs3 snapshots programmed. I have to repair my snapshot on that one first. As you know the new audiomixer destroys former snapshots and it seems, that after storing a working one, it destroys them again. I keep you updated.
Are your program changes in Stage Mode (where each program change opens an engine on a new MIDI channel)?
Or are the program changes in Multi Channel mode (18 program changes on MIDI 1, 18 program changes on MIDI 2, and 18 program changes on MIDI 3)?
Regarding FluidSynth:
How many sound fonts are you opening, 1 or 18?
How big are the the sound fonts?
Do the program changes span several sound fonts or are they contained in one sound font?
I had best results when I opened only one sound font (600mB) on one MIDI channel, and I restricted program changes to within the one sound font:
New Layer
Midi Chanel 1
FluidSynth
mysoundfont.sf2
PC1 Piano
PC2 EP
PC3 DX
PC4 Brass
etc…
If you use LinuxSampler I would use Stage Mode to avoid unloading and re-loading big sample files to memory:
Yes, current testing is quite “testing”. It’s a good idea to have separated SDs for stable and testing. Changing back from testing to stable doesn’t work always, and snapshots are not compatible. A snapshot is a “capture” of the zynthian state, and it depends of the underlaying data structure. When the data structure that generated a given sbapshot is too different to the current one, it’s difficult to load the snapshot and get a fully functional state. Some times you loose some routing, some times it’s worst.
When testing is merged on stable again, we will implement am “auto-import”, so the transition should be friction-less, i hope.
But memory is not the problem here. Only lightweighs like ZY, SF and BF, each on a channel.
Under no circumstances a complete crash should happen.
But I am trying to start over with a new image. Let’s see if that helps.
It’s a good idea to have separated SDs for stable and testing. Changing back from testing to stable doesn’t work always, and snapshots are not compatible. A snapshot is a “capture” of the zynthian state, and it depends of the underlaying data structure. When the data structure that generated a given sbapshot is too different to the current one, it’s difficult to load the snapshot and get a fully functional state. Some times you loose some routing, some times it’s worst.