Which zynthian directory are the damaged file reported in. ?
Because you could simply pull in that repository as was done with webconf in the example above.
It would probably a good idea to copy the soundfonts you want somewhere safe if you happen to have a spare 45G somewhere. My desktop machine is a pi so I use the desktop file manager to open up a ssh connection to the zynthian and then drag and drop items like the soundfiles into a backup folder.
Zynthian updates are pretty good, but it canāt account for a file that promises to come but never arrives.
Looking at the log above I think they are all in /zynthian/zynthian-webconf/.git/objects. But that is also the only directory I performed the git fsck on, because the update log showed the error when updating webconf.
I usualy have them all mirrored on an external USB HDD at my pc. But that doensāt prevent me from copying them over if I burn a new sd. I would love to have the whole zynthian-my-data folder on an extra partition which would be unaffected by burning a new image but I think this is not intended right now.
I also think so. Maybe it could ping the internet before it starts working.
I am afraid I have to adapt some things. Being at vangelis I think I should replace stable by testing I guess, donāt know if the other things apply.
Instead of pointing the newly created HEAD to the branch pointed to by the cloned repositoryās HEAD, point to branch instead. In a non-bare repository, this is the branch that will be checked out. --branch can also take tags and detaches the HEAD at that commit in the resulting repository.
The code fragment above also copies the cert . Others have said you can delete the certs successfully. A certain air of mythology hangs over them . . .
Hi @jofemodo! . My custom colour profile is based on a spectrum of blue-light blue-greyish cyan and green (basically, my fav colour areas), but it would absolutely suit me to design a green monochrome scheme a-la-Fairlight for the Zynth!
Hi all, quick note that I submitted a pull request for updating RipplerX to the latest version. I already wrote a wall of text on that PR, so Iāll keep this comment short.
I found that the following practice works well for searching and reordering parameters:
Using double-digit numbers for parameter group displayPriorityentries.
For actual parameter definitions, use the groupās priority and append an extra single digit to it for reordering within the same group.
For example:
plug:G5D_NOISE_ENV # actually defined at the bottom, below all other plugs
a pg:InputGroup ;
lv2:name "Noise - Envelope" ;
lv2:symbol "g5d_noise_env" ;
lv2:displayPriority 17 .
plug:noise_att
a lv2:Parameter ;
pg:group plug:G5D_NOISE_ENV ;
lv2:displayPriority 174 ;
lv2:designation param:attack ;
rdfs:label "Noise Attack" ;
rdfs:range atom:Float ;
lv2:default 1 ;
lv2:minimum 1 ;
lv2:maximum 20000 .
plug:noise_dec
a lv2:Parameter ;
pg:group plug:G5D_NOISE_ENV ;
lv2:displayPriority 173 ;
(...)
plug:noise_sus
a lv2:Parameter ;
pg:group plug:G5D_NOISE_ENV ;
lv2:displayPriority 172 ;
(...)
plug:noise_rel
a lv2:Parameter ;
pg:group plug:G5D_NOISE_ENV ;
lv2:displayPriority 171 ;
(...)
So, RipplerX becomes Rippler and from version 1.5.18 itās closed source.
OK. I will update to the last free version and letās hope the developer change his mind in the future. If not, i will be pleased with the 1.5.18 version. It sounds really well and itās hugely generous from @tiagolr to bring us this as free software!!
Oh, I just saw this, thanks @jofemodo for merging it!
I think in terms of parameter group organization, maybe the best way forward would be to look into conditional visibility of groups based on another parameterās value. Model type enum, in this case. This would allow us to implement the better grouping (imho) that I outlined toward the bottom of this long GitHub comment (āAnother approachā), but without blowing up the number of groups and adding awkward text to their names.
The comments he left in this GitHub issue suggest that the closed-sourcing of future versions is quite intentional. However, the current version is indeed terrific and very generous to have been open-sourced in its current form. The fact that he left the open-source repository intact, and started a new one for the closed effort, should also make it easier to contribute any maintenance patches in the future.
This is not an easy task. I donāt think LV2 currently have this functionality. We could extend LV2, of course, but this is not going to happen tomorrow.
If you are interested on this, you should open a feature request and describe your proposal in detail.
Yes, Iām aware, and no rush. Iāve tried my hand at some prototype LV2-extension syntax, but this isnāt quite ready for consumption at this time and I may not get back to it in the near future. If you have more straightforward group name tweaks in mind, please just go ahead with these ones.
I do think that conditional group visibility has potential also outside of just RipplerX, especially for more complicated semi-modular synth types, where entire blocks of functionality can be enabled or disabled with a switch and the associated parameters become ineffective. But also, Zynthian has been doing okay without these for a long time, so itās probably not going to be all that high up on the priority list
. My custom colour profile is based on a spectrum of blue-light blue-greyish cyan and green (basically, my fav colour areas), but it would absolutely suit me to design a green monochrome scheme a-la-Fairlight for the Zynth! 
