Yes! Having the parameters well organized in groups would help a lot to get Osyrus being more usable from zynthian UI.
Thanks!
1 Like
I don’t remember. Is it possible for a LV2 plugin to expose its plugins dynamically rather than via a ttl? I thought this was an option so that a plugin could provide default presets. I wonder if there is the possibility for the plugin to dynamically expose its presets so that, when zynthian queries jalv, the plugin’s internal presets are advertised.
I haven’t seen this implemented in a LV2 plugin, what doesn’t mean it’s not possible.
Anyway, the LV2 preset/bank way is a paved way that works pretty well and we already have enough work with the new “dynamic propierty parameters”. Let’s focus on this. Step by step!! 
Regards,
2 Likes
What can be done quite easily is exposing the internal presets like this:
<http://theusualsuspects.lv2.Osirus:preset1>
a pset:Preset ;
lv2:appliesTo <http://theusualsuspects.lv2.Osirus> ;
rdfs:label "default" ;
state:state [ <http://theusualsuspects.lv2.Osirus:Program> "0"^^xsd:int ; ] .
Regards,
1 Like
Is it possible for a plugin to generate .ttl files dynamically, for example: upon first load with an arbitrary rom (permissions?) and does the UI support this / can it re-scan the presets when you enter the preset selection?
If that was the case we would be able to generate .ttl files on the fly
2 Likes
I’m not sure that jalv can do this in its current state, but we can run the plugin just for generating the presets when the rom file is uploaded from the webconf. Then the UI will parse the presets and add it to the DB. This is quite easy and would work without modifying current UI or Jalv code. In the future we could see if dynamic loading can be implemented.
Regards,
2 Likes
I added some test data to
/zynthian/zynthian-data/presets/lv2/Osirus_Presets.lv2/xxx.ttl
However, I cannot see them in the GUI. Do I have to do anything special to make them appear? Recanning something or so?
Rebooted already but this didn’t help
1 Like
There is a button in the webconf “Engines” tab to “Search for presets”, but this is a very slow operation because it looks for presets for all the installed plugins (> 1000).
You can search for presets for a single plugin with this command:
regenerate_lv2_presets.sh <plugin_uri>
In your case:
regenerate_lv2_presets.sh http://theusualsuspects.lv2.Osirus
Then you should restart the Osirus processor (plugin) or restart the UI to get the presets refreshed.
We lack a mechanism for dynamic refreshing the presets in a loaded processor, but it wouldn’t be difficult to implement.
Regards,
3 Likes
thanks, seems to work like charm, banks work also.
4 Likes
Any advancements with the Osirus/OsTIrus Zynthian integration @dsp56300 ? 
Just in case, do perhaps the already shared Osirus/OsTIrus links host their respective recent versions immune from the (apparently overcome) stdout issue?
And, might we apply the presets enumeration procedure explained by @jofemodo, in order to get a selectable patch list inside Zynthian?
Thank you,
Cheers!
1 Like
The preset export is not in yet because we need to discuss how we want to do it. But the logging issues has been fixed. If you want to build from source you can try it.
git clone --recurse-submodules https://github.com/dsp56300/gearmulator.git
cd gearmulator
cmake --preset zynthian
cmake --build --preset zynthian --target install
Then search for new engines and you should be able to play with Osirus and OsTIrus.
3 Likes
Thanks @dsp56300 
,
I will absolutely try this! 
They do indeed both work
Although building (for me) did require removing the tmpfs entry from /etc/fstab, as that is set to 100Mb and it will run out of space.
There was also a warning about webkit2gtk-4.0? but that (apt install libwebkit2gtk-4.0-dev) doesn’t seem to make any difference.
Thank you!
1 Like
Hi @gadg3ts! 
Could you maybe expand a bit on this concept and procedure?
It will certainly sound like a silly question for you, but where do I find the directory tree related to the tmpfs entry to be cancelled? (before or after compiling?)
Thanks!
Sure. No problem.
The /etc/fstab file tells the system where to mount the filesystem partitions.
proc /proc proc defaults 0 0
PARTUUID=a78e54ac-01 /boot/firmware vfat defaults 0 2
PARTUUID=a78e54ac-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,size=100M 0 0
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,size=200M 0 0
tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,noexec,size=20M 0 0
Temporary files are stored in the directory /tmp, and this (by default) is limited to 100Mb.
There’s more than one way to disable this entry, but the easiest is just comment the line, save the file and reboot.
So, edit the file
nano /etc/fstab
Move to the start of the 3rd line from the end and comment out the line with ‘#’ like this
proc /proc proc defaults 0 0
PARTUUID=a78e54ac-01 /boot/firmware vfat defaults 0 2
PARTUUID=a78e54ac-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
# tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,size=100M 0 0
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,size=200M 0 0
tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,noexec,size=20M 0 0
Save and exit with ctrl+x then ctrl+y to confirm
If you then reboot your zynthian, the /tmp directory will no no longer be restricted in size, and all the compilations can complete successfully.
Is that ok?
1 Like
Remember that this is a temporary step to allow the software to compile. You should restore the system to its previous state afterwards. Zynthian has been tuned to work within parameters that may, if changed result in undesirable effects.
If/when we integrate this in zynthian, users won’t have to compile from source and so this step will not be required. It is only for the adventurous and eager amongst you.
2 Likes
I have removed, commenting with #, the 100 Mb tmp limit, as suggested by @gadg3ts, and then reinstated it as rightly pointed out by @riban for system stability.
Osirus and OsTIrus seem to have recompiled successfully from repository source, and indeed in my SFTP Mac client they appear updated to October 7th, thus arguably overwritten today over the previous september version! 
Apart from a yellow warning during the compiling cycle - about a certain cmake command call not apparently updated, which did not interrupt the process nevertheless - all seems well. I obviously still do not see any presets in an Osirus or OsTIrus chain, but this is expected for the time being.
I have to experiment more, but I already tried briefly an Osirus chain with presets selected through VNC patchage, and the engine seems to work very well on a Pi5 Oram with a single track snapshot. No glitches, no dropouts, no audio blocks, no audio crashes in idle state. 
I will check OsTIrus as well and publish updates!
Many thanks 
Thanks @riban for aptly specifying this crucial detail! 
I was debating whether to include this, so thank you for pointing it out.
It’s obviously there for a reason