Settings in synths change unexpected

@wyleu @riban
One more question.
I tried to burn a new SD for three times now.
Initially the Raspberry starts and I can enter it using Webconfig. After changing kit to custom, Zynthian does not come back from the Save operation.
As said, I tried this three times over again.

I can still access en shutdown the raspberry with PuTTY.

Is there a way to back to a previous stable?

Is there

I have just updated the bug report - this is not just cosmetic - sound changes (which is rather annoying). Avoid using the touchscreen to change parameter page until this issue is resolved. (I just lost a load of sound design - grrr! :angry: .)

@BertB are you saying that selecting custom breaks webconf and / or Zynthian UI?

I am not sure it actually breaks it up. I have tried it several times all from start with a fresh SD.
Sometimes it takes 15 or 20 after Save for zynthian to respond. Sometimes i have to reboot via putty SSH.
With Top in the SSH i see python3 consuming a lot of processor time.

Please raise a ticket in the issue tracker for this completing all the info in the template so that we can better understand the issue and it gets tracked better.

Tonight I will start the procedure all over again and document the process.
Then I will make ticket.

1 Like

Today, I’ve started one of my Zynthian, it was running on testing, latest zynthian-ui commit: 32c4ef4
(25 days ago). I’ve loaded a preset with 5 instruments and one of them is fluidsynth. I didn’t noticed any weird behavior as stated above. But I didn’t test it extensively.
Then I’ve updated the software, and with same preset the problem occurs.
There’s this commit: Touch interface broken - after commit 32c4ef4.
I can’t tell if it’s related, but it’s the only one that “touch” the HUI.
Maybe I can investigate further later this evening.

Hi @zynthianers!

I was debugging this problem and discovered it’s an old concurrence (a “mutex” scenario) problem that was supposedly solved but in some point, probably when implementing the new controller screen workflow, it was revived. Fortunately, some lost neurons in my brain recalled the old crussade and i could re-enable the original solution (lock/unlock the right code fragments).

Anyway, stay alert with this, as i’m not 100% sure of not creating side effects. Concurrence is a slippery snake.

Simply update on testing and test.