a bit of patience please, we are working on it 
the stdout issue is solved, now working on presets. We hacked some export together and had to change a bit of code so that they load, but now its working
9 Likes
On the subject of sysex to lv2 patch conversion, there is already a converter application in Zynthian which handles specific sysex formats such as Dexed and other proprietary formats such Obxd. Of course out of the box it is of no use for formats it doesnāt know about, but at least its an existing framework which would be suitable for augmenting with Virus sysex support.
1 Like
We have sorted it. Unfortunately, as we use Juce, we have to use the Juce style of encoding, which is not a common format unfortunately. To make things worse they even name it ābase64ā even though it isnāt 
https://docs.juce.com/master/classMemoryBlock.html#a531fe1cf6c9a9fe2ac72464a5d7599e8
The code to export presets has been written already, we can put that into anything needed. A command line program, executing while loading the plugin, whatever.
3 Likes
The application I was thinking of that is used by Zynthian is this one:
Iām assuming itās this version that is used in Zynthian, as I canāt find a clone of among the Zynthian repos on github, and itās our very own @jofemodo that is the author.
1 Like
Hi All,
I have Osirus preset banks (of 128 sounds) in .mid files. How do I add them to the zynthian library such that I can individually select them in the Zynthian preset UI window?
Thanks and cheers,
Maarten
Hi @maartmaart !
Using mid files as presets is not currently implemented and there is no plans to do it. Indeed itās the first time someone request it. Please, could you create a feature request, including the preset files in mid format?
Thanks
2 Likes
Hi @jofemodo,
Fast as always!!
Thanks for your reply.
In the Orsiris user interface I can load the .mid file and when I load a preset, it is loaded
When I then save the loaded preset in the Zynthian UI, it is saved as correct (loadable) zynthian preset.
However, to do this for each preset take a lot of manual labourā¦
I wil create a feature request!
Cheers,
Maarten
1 Like
Hi @maartmaart 
Do you need this feature to load into Osirus third-party Virus patches (there are tons of them available online) not included in the official ROM banks?
Hi @Aethermind ,
That is rightā¦ I want to import third party banks with presets.
Why are you asking?
Do you know a way?
Cheerd,
Maarten
Hi @maartmaart
Osirus presets should be located in:
/zynthian/zynthian-my-data/presets/lv2/Osirus.lv2/
as .TTL manifest definitions and related folders, generated while compiling the plugin from source at the time of installation, so no patch-related midi data is exposed in the synth structure and therefore cannot be manipulated or stored.
As far as I know, there is currently no way for bulk-importing Midi presets directly in the plugin within Oram, but you should be able to switch on VNC and import new presets with the patch manager of the native GUI. It should accept the following formats:
mid (Midi)
sys (sysex)
cpr (Cubase)
vstpreset (Virus editor)
Preset sharing in the DSP563 Discord channel is mostly done through sys files.
Hope it may help,
Cheers!
1 Like
Hi @Aethermind ,
Thanks a lot for your explanation and suggestions!
Have a great sunday!
Cheers,
Maarten
1 Like
Hi Maarten,
Forgot to mention that, in the Osirus patch manager of the native GUI visible on VNC, you can right-press with the mouse and add a ādata sourceā folder with the new presets, which I recommend keeping separated from the plugin directory. That should add the content of the whole presets folder to the patch database of the plugin. I think this basically does what you are looking for. Right?
I hope you also had an amazing Sunday! 
Cheers,
Paolo
1 Like
Hi @Aethermind ,
Thanks again!!
I also wanted to save the 128 presets in the .mid file as zynthian presetsā¦ in one go (so not manually creating preset by preset the individual Zynthian presetsā¦)
But that is not possible yetā¦ I requested to add this featureā¦
Cheers,
Maarten
1 Like
So, I recently had the chance to try out Osiris on my new-fledged RPi5 based V4. First of all, this is such an amazing feat, from the 56300 emulator itself to the Osiris packaging, to getting it all to work on the Zynthian! Great work everyone involved!
A few observations, not meant as criticism per se, see them more as questions if I grasped everything properly.
- The ROM presets are present as .ttl files, however, they seem to contain an encapsulation of the binary patch data, rather than ordinary lv2 parameters. As noted above, one would need to load a preset into Osiris, and then save it, in order to get the full lv2 rendering of it?
- Alternatively, Iām imaging that one could write a conversion script which would take .sysex or .mid data, extract the parameter data, and write it to a āproperā lv2 .ttl file? This shouldnāt be too difficult Iām thinking, but given the sheer number of parameters, it would be a bit of a chore.
- The above means that when loading a preset, all the UI parameters are set to 0, but they still control the relevant parameter when adjusted. Fair enough.
- All parameters seem to have displayed values from 0 to 127, even for parameters which are clearly bipolar (-64 to 0 to +63), or not continuous at all, such as Filter Routing. Iām assuming this was done to get the parameters out there sooner rather than later; more work would seem to be needed to make the displayed parameters more user friendly. Some things, like unipolar vs bipolar parameters, cannot be fixed in the UI alone, but Iām assuming would need modifications to the emulator?
- There seem to be a number of parameters which are not present in the UI, bend range for instance. Is this just a shortcoming/oversight of the current .ttl file, or are there limitations which make it impossible to access certain parameters this way?
Hi @ricard
Welcome to the usage on Zynthian of these outstanding software implementations, of DSP563XX-based digital synths.
You insightfully raised a few questions, related in essence to two interconnected standing limitations, affecting the whole emulators family:
A] Due to not compleye JUCE compatibility of the Zynthian OS environment, there is yet no two-way parameters feedback, between the Oram GUI and the underlying Osirus GUI structure (as natively visible on VNC).
B] Importing presets directly in the Zynth plugin pages is not possible, because of the current structure of the TTL manifest file. This has to be done on the native GUI on VNC.
Our devs and their DSP563 counterparts have been in touch, to overcome the last mile before complete integration of the emu, but it seems that making it 100% LV2 and thus Z-compatible would require some substantial reworking of the code, and maybe even forking officially a Zynthian version (which the programmers are understandably reluctant to do).
Have a nice day!
Yes, I read somewhere on the forum (possibly in the general DSP 56300 emulation thread) that a lot of work would be needed to get full LV2 capability in Osirus. But it seems that already itās possible to create LV2 preset files using the Zynthian UI and load them on Zynthian. [EDIT] How does this mechanism actually work? I looked at .ttl file that Iād saved in Zynthian, and the state string was significantly longer than in the ROM ttl files (like 145 kbytes vs. 361 bytes). It seems that within this format, the edited parameters are saved in such a way that when subsequently loading the preset, they are displayed in the UI. So Iām thinking that it should be possible to convert the ROM files so that the parameter values can be shown in the UI. Since normally .ttl files are written out based on the displayed values, Iām assuming thereās some special save mechanism to write the state string in the .ttl file rather than ordinary lv2 parameters?
At any rate, Iām thinking it should be possible to create an application to convert between the lv2 files and sysex files, which would allow presets to be moved between the LV2 and Osirus worlds, even if it doesnāt happen as seamlessly as if the Zynthian LV2 based and native Osirus UIās would directly interact with each other.
Ok, so I learnt a few things over the course of a few evenings: The Osirus dsp.ttl file is not used for the Zynthian UI, instead a custom Python file defines the parameters and pages. And the reason that some parameters are missing from the Zynthian is tightly coupled to the way parameters are controlled in the Virus. This must be well known to long term Virus owners, but Iāll repeat it here for noobs like myself (apologies if itās already in the thread somewhere): The parameters are divided into 3 āpagesā, A, B and C. All parameters can be controlled via sysex messages, but additionally, page A can be controlled via CC, and page B can be controlled via MIDI Polyphonic Aftertouch (i.e., it is not used as poly aftertouch, instead, the note number is used as a parameter number, and the aftertouch value then is the parameter value, which is a clever way of extending the CC range in the days before NPRN and other tricks). So the Zynthian UI as currently configured only generates CC values in the case of the Virus, and thus only parameters in page A can be accessed. Happily, these are the most frequently used ones (and Iām speculating that they correspond to the original Virus A setup).
It would be nice if the Zynthian UI could be extended to send sysex messages instead of CC when so configured; after all, it can send OSC messages in lieu of CC for synths that support that instead (such as ZynAddSubFX). There is the added complexity of having to specify additional data that needs to be sent in the sysex message, in the case of the Virus, there is an additional Device Number for instance, but it would allow all Virus parameter pages to be accessed from the Zynthian UI.
Indeed, what we need is that the LV2 parameters are defined with good names. Read this:
So we donāt have to use CC (nor SysEx) to control the parameters.
We would need that @dsp56300 or other osirus developer change the names for the LV2 parameters so they can be parsed by the Lilv library.
Regards,
1 Like
Yes, I read that, but I also read that it would require a substantial refactoring of Osirus/OsTIrus (although I canāt really understand why, if itās just a name change) which means it might never happen. If the names are related to some internal architecture, then one would think that a mapping to LV2 compliant names could be implemented (which perhaps also is a substantial effort).
Honestly, it is also beyond my technical understanding why a (mere?) change in naming syntax of parameters would imply a deep revisiting of the code, unlessā¦ this decision riverberated across a whole set of core functions, in the hierarchical tree of the program, making it less compatible - or even plainly incompatible - with more widespread and non-ARM Linux implementations.
That might be a major issue, which arguably could only be solved by forking a Zynth version of the plugin.
I havenāt the faintest clue about this, just speculatingā¦
Best regards