(by the way… Robin is not going to react on your left messages or work on it since he has given no repons since a few months. A little bit scary…)
Everyone has a limited amount of time in their lives and must chose how best to use that time to benefit themselves, their families and their friends. We each have our own view of the world and it is rarely the same as others. Zynthian is an open source project that benefits imensely from other open source projects. We include a lot of work that has limited upstream support and accept there may be issues that won’t be resolved quickly. If there is sufficient enthusiasm, we sometimes contribute upstream or fork a project to fix such issues but of course, we too have limited time in our lives so must chose how best to target our effort.
We can report issues upstream and hope that our friends on those projects find time and enthusiasm to investigate but we can’t expect this so, we can wait and see. I hope that Robin finds the time or that someone else can help to resolve these issues but don’t expect it.
Fixing one build issue does not preclude there being more so it is never certain that initial engagement will lead to a working build. The build error here may be worked around, e.g. by avoiding building the test suite. Maybe someone will fix that and see if we progress further…
[Edit] Actually - looking at the errors, it looks like the failure is in building cairo which is a project upstream of ToobAmp and probably not required. These kinds of errors are frustrating because there are dependencies that fail where those dependencies are not really required for the core product and in this case it looks like the test suite for a contain used to test ToobAmp is failing so it is twice removed and kinda irrelevant to the thing we want - but, someone would need to investigate, possibly to disable building of cairo.
4 Likes
Of course, sometimes you just find time!
I have managed to compile and install these plugins on my V5 and initial testing suggests they work, at least the one I tested did something.
Steps to compile (mostly for own reference in case we want to do this again):
git clone --recursive https://github.com/rerdavies/ToobAmp.gitcd ToobAmp- Comment out
lv2cairoinmodules/CMakeLists.txt apt install librsvg2-dev libflac++-dev libboost-iostreams-dev./config.sh./build.sh- this fails trying to build the deb package. Could probably justmake ToobAmpin the build directorycp -r ToobAmp/build/src/ToobAmp.lv2 ~/.lv2/- probably the wrong place to installcp ToobAmp/build/src/ToobAmp.so .lv2/ToobAmp.lv2/- Find plugins in webconf
The build does take quite a while. If anyone else wants to try, they could validate this procedure. I guess I should test it a bit more. Now where did I put all of that spare time… ?
4 Likes
Hi Brian… thanks for for your time and effort!
I will try them as soon as I am home! 
Maarten
Hi All…
I made a nice pedalboard using the Toob plugins. Especially the ToonML and Toob stereo flanger are perfect!! Very nice stereo sound!
But, when adding Midi controllers to switch on and off the plugins (which only can be done using the MOD-UI pedalboards) the Snapshot saving fails … 
Adding MIDI controllers for plugins and instruments all done in the Zynthian app, it is OK.
I made a bug report…
Thanks!
Maarten
3 Likes
@maartmaart , I have a different workflow. I do not switch off/on audio fx inside the single audio chain when playing. I have multiple audio chains and have only one enabled and other muted. What I do is I create multiple audio chains with different aida-x captures and audio fxs settings required for a single song or a style. I use only one audio chain when playing while others are muted. I save such setup as a single zynthian snapshot so that I can load when playing that song or style. Most importantly I also save multiple zynthian sub snapshots (zs3) inside the snapshot were each sub snapshot has only one audio chain on and all other muted. Finally I assign midi control to each zs3 so that I can switch to a different audio chain while playing . I also alight audio chain from left to right so that they have the same order as my midi foot switches. In this case I do not need to think what foot switches will enable what audio chain required for specific part of the song. Also I give name to each audio chain to remind me where it should be used in a song (e.g. intro, rhythm, solo etc) or if I am composing o save it as a style/mode (e.g clean, crunch, gain)
There is one problem with this setup which is that if you have additional zsampler chain for playing a backing track it will stop playing when you switch zs3.
2 Likes
Have you reported that in the issue tracker?
No I haven’t, because I am not sure if this is a bug or it is intentional. If you think that there is no benefit for some other workflow to stop playing zsampler chain when switching zs3’s then I will raise it as the issue.
The point of ZS3 is to make fast changes (parameters, presets, etc.), ideally without interrupting the audio. The first principle is for fast change, e.g. between songs in an on-stage set. Some changes will cause disruption. But a secondary use may be to make scene changes during a song, e.g. to recall different configuration for different parts of a composition. This scenario requires minimal disruption to the sound and particularly for guitarists who want to change their sound throughout a performance.
ZynSampler started its life as a simple audio player and grew in features and complexity but many still use it as an audio player. If there is not change of its state saved in the ZS3 then it should not change state during ZS3 recall. I can imagine what is happening is the play state is saved in the ZS3 so it will restore to that state, e.g. stopped or playing - which is almost certainly not what is required. (Although some have commented that they like that the play state is restored on boot, e.g. if using it to play audio in an art installation that may be subject to power interruption.)
So yes, I recommend reporting it so that we can consider how best to handle the various scenarios.
2 Likes
Thanks for your suggestion. I wil look into that… I do not grasp how to use these ZS3 sub snapshots… I wil RTFM 
But apart from that, the control via midi should not impair saving the snapshot…
Always nice to have some help!
Enjoy your day and making music,
Maarten
1 Like
I will check tonight if playing state (on/off) is saved and if zs3 saved with audio on will temporary sort this issue. Anyway, I will raise this as an issue. Thanks.
Current behaviour is that parameters are saved in ZS3, including play state and play position. So if it is playing when the ZS3 is saved, it will resume playing from the same position when the ZS3 is restored. I can see this as both beneficial and undesirable, depending of the scenario.
Do add the ticket so that we can discuss it in the issue tracker and lets not talk further here as it is off-topic. 