After every update, my zynthian automatically starts playing a caption, I previously recorded. This started about 4 or 5 updates ago.
Same here. (EDIT: It happened once here, not again)
1 Like
I also had some auto-play events.
IMHO, play status shouldn’t be saved/restored. I think this is going to cause unexpected behaviour. If i poweroff my zynthian while playing, i don’t expect It start playing when poweron 2 days after. I suspect this behaviour will result annoying for most users.
Regards
There are son et lumiere performances where this is precisely what you want it to do when started by simply turning on the power…
Of course, you can always find use-cases for everything. For one feature and for the oppossite. But we can’t have a config option for everything. In this case, 95 of 100 users, probably more, will find annoying this behaviour. Should we add a config option for the 5% when pressing play is so easy? What about playing sequences and audio clips? Should play state for these be saved and restored too? And what about playing position? Should be saved/restored too? I’m pretty sure we can find use-cases for both possibilities More config options?
Perhaps we should have a full config section for all these (restore playing state), but the default would be “no restoring playing state at all”. So, let’s disable this feature and discuss about the need for having it as an option.
Regards
2 Likes
Perhaps we should have a full config section for all these (restore playing state), but the default would be “no restoring playing state at all”. So, let’s disable this feature and discuss about the need for having it as an option.
I agree that should be the default…
A config setting would seem sensible to allow a mode of operation that myself and possibly others have used effectively in creative endevours over a month, operated by totally non technical people simply turning the device off and on… (quite what happens on shutdown might also be a config option)
I have played and discussed about using zynthian for “sound sculptures”, “interactive installations” and other pieces of “sound-art”, so yes, i agree that “restoring playing state” can be an interesting feature although normally not for the average user.
Indeed, running a post-start script can be still more interesting from this perspective. Sending some CUIA can do this task and many others. This is still more interesting if you want/need to sync several zynthians.
Perhaps we should put the effort on implementing post-start scripts that you can edit easily (webconf) and improving the scripting capabilities instead of adding a lot of config options to support highly specific use-cases that would be best solved with some scripting.
Regards,
1 Like
Agreed. Events in CUIA does provide a considerably more flexible infrastructure.
Its easy to overload the admin parameters …and we perhaps could even use the event cuia for other housekeeping and environmental actions…
Low power would be one that springs instantly to mind…
So perhaps we could think of the points where we want scripting. For instance:
- Just before zynthian-UI is started
- After zynthian-UI is started, but before the last-state snapshot is loaded. This script could decide what snapshot to load, etc.
- After zynthian-UI is started and last-state has been restored.
- Periodic execution scripts
- Event-triggered scripts
- Just before exiting the UI
- Just after exiting the UI
Indeed, perhaps we could have a single script with several entry points that are triggered by events coming from the UI.
Anyway, this is not for now (we have to release Vangelis as stable!), and probably it should be best discussed and driven thru our ticket system 
All the best,
Not too detailed but a place holder.
All very interesting but this is an actual bug. The player is in stopped mode when zynthian is shutdown and in play mode when it starts. Let’s fix the incident then see if there is a problem to solve.
1 Like
Disabling “play state restoring” would solve the issue.
It might not if the bug is in the lib! Let’s fix, not hide the bug first.
1 Like
OK. You suspect it’s not related with restoring the “transport” controller state but it could be deeper.