Hi @le51!
There have been significant changes, since the already compiled version originally posted by @dsp56300, so yes, you have to compile from source in order to use the latest plugin’s code. 
Ok, thanks.
why you do not add these new synth to Zynthian repository?
They’re buggy, they’re only useful with a pi 5. They make no sound at all without providing a rom image which is copyright and therefore illegal to distribute.
I think adding these to zynthian would be a terrible idea.
edit: someone hosting a repository of precompiled binaries and having instructions to add it is fine. Like Rpmfusion with Fedora.
3 Likes
Hi @Baggypants!
I think that maybe this is a bit too pessimistic:
I respectfully opine that DSP56300 emulators may be a bit bumpy, complicated to manage system-wise and not yet completely optimised for the Zynth, for the time being. But once they will, they will also represent a formidable asset for the platform, will not they? 
All the very best 
Please, ignore my previous note about not being able to see the generated presets of Osirus and OsTIrus, because (SUCCESS! 
) I found the way to have the Zynthian see them after the plugins’ compiling and installation!
It dawned on me that, after the presets generation through terminal commands, the user needs to search (again) for engines and then search for presets in webconf > engines, for Oram to show them in the Zynth’s UI, as it finally turned out to be the case (see screenshots attached).
The plugins stability and audio clarity seem WAY better than on VNC, with its entailed CPU overhead, and the overall playing impression is very fluid and satisfying 
(I am on a medium overclocked Pi5 with an audio buffer of 256 samples).
For the time being, it appears that I am not able to drive Osirus and OsTIrus other than on Midi Channel 1, from my external DAW and Midi keyboard, but I will have to investigate the current workaround apparently based on recent (testing) additions to the OS by @riban and @jofemodo.
All the best to all @zynthianers 
I see you also don’t get Banks A & B in Osirus. Something is wrong with this 2 Banks. Perhaps a bad character in the TTL…
Regards
Yes, I noticed that (missing A and B Osirus banks), and also the Ostirus presets generation reported an S bank error (a missing character apparently), but most of the patches seem there.
Best regards
I’ve also noticed the “only on midi channel #1” issue, that obviously poses a problem with running more than one instance e.g. OsTIrus and Osirus concurrently.
I’m running PI5 with no overclocking and hdmi audio @ 512byte buffer. No noticable lag, and no issues with the virus plugins.
in the second instance of Ostirus/Osirus you have to change the midi channel via VNC, right-click on the input and select the channel you need, e.g. ch2.
Or switch to multimode via VNC.
I have saved two presets via the Zynthian UI, Multi and Single, which I can use to call up the basic states Single and Multimode from the Ostirus plug-in.
You can do the same with switched midi input channels.
1 Like
Hi @highsiderr,
Thanks for the clue, on running multiple instances of the Viruses in the same snapshot on different Midi channels.
I am not sure to have got the precise meaning of your words: do you maybe mean switching to multimode in the native plugin’s GUI through VNC, having just an active Midi input channel, to be changed 1-16, for each plugin instance that is driven by the internal Zynthian Midi flow?
If I am interpreting correctly, Ostirus and OsTIrus should always be set in multi, with a single different Midi input channel, in order to be used as several instances in the Z. This seems to rule out, intrinsically and at least for the time being, the possibility to control multitimbrally from different chains a single instance of the plugins.
As for the single mode, I will have to investigate in VNC on the native interfaces, but it would seem that it only works on Midi channel one.
Here is an Ostirus multimode snapshot with 2 channels.
Switch the Plugin to multimode in the VNC.
Start in Padseqencer on the Zynthian Clip 1 and 2
You can also switch the presets in Ostirus on CH1 and CH2 in the VNC or via Midi CCsend (midi tool).
003-multi forum.zss (10.3 KB)
Possible with the Snapshot from above
4 Likes
Great @highsiderr,
Many thanks for the info and practical examples. Will implement them asap in my personal scenarios 
It’s complicated at the moment.
Let’s see what comes of it.
However, I don’t think it will be any easier if all the parameters are visible, about 3000 parameters on the touchscreen could be a horror.
Let’s see how the multimode, which is advantageous for this plug-in, is implemented in the future.
I have thought about it but have not found a solution.
A slimmed-down Zynthian version similar to the MidiCC list of the VirusTi ?
Creating than presets via VNC?
Wait and Drinking tea… 
Hi!
Regarding the future real multitimbral usage of a DSP56300 emu (let’s not forget also the Waldorfs possibly on the line), it will arguably be similar to what is currently implemented for Zynaddsubfx, which is treated under the hood as a multichannel engine, even if the user adds multiple chains of it.
As it stands, mounting a multitimbral snapshot with Osirus and/or OsTIrus is extremely resource-consuming, since it entails using a different synth instance for each Midi channel. I am sure that the 56300 and Zynthian devs will come up with a leaner and more CPU-effective solution, in the end .
As for the subject of managing the parameters of the TI on Zynthian, which can easily escalate to mind-numbing numbers due to the variety of available engines, I have already suggested a practical approach: just expose a limited gamut of really meaningful values for each categorised synthesis model, and leave in-depth sound design to temporary VNC visualisation of the native GUI.
In the meantime, the multi-instance solution is an acceptable compromise for achieving multitimbrality, as long as the Pi 5 handles the computational load!
They present a legal liability. In the future anyone with the rights to Access Virus intelectual property can waltz along and do to zynthian what Nintendo did to the Switch emulators.
By all means work on integration, but I think including them in an official capacity invites money to be wasted on lawyers, and repeated support issues about a synth engine that makes no sound out of the box because no-one reads the docs,and then people getting annoyed because the answer will only ever be “We included this thing but we can’t tell you exactly what you need to get it to make sounds because of lawyers. Sorry lol”
You may as well ask that a copy of Disneys “The Little Mermaid” get included in the zynthian repos.
1 Like
I already acknowledged, in another thread on a JV-880 emulator, that the inclusion of DSP simulations might cause
Also
About the rights of the Access company - now apparently no longer a synthesiser brand - they obviously stay with their legal owners, till the legal binding of the intellectual property lasts.
They almost certainly tried/are trying to squeeze every last penny out of their dearly earned DSP code, attempting to resell it to another major firm.
Except… it is not happening, maybe because we are talking about twenty years old software, and professional-grade digital synthesis has progressed elsewhere, in parallel with stronger hardware specs and in reaction to unavoidable changes in musical taste. Therefore, perhaps there is not such a huge business space today for a commercial Virus TI reincarnation, on the part of a similarly respectable company.
In the end, when/if someday the Access firmware copyright will naturally expire, the better for the world and Zynthian will be able to support it officially. If not, and somebody takes the hat and starts producing the Virus 3, good luck to them! We will keep on using a free TI 2 clone with the due ROM sourcing cautions on every compatible platform.
This said, the final word on including or not the DSP56300 emulators in the Z repos is @jofemodo’s and @riban’s. I can perfectly live with whatever they decide, also because I have alternative IT resources to run OsTIrus if Zynthian is unavailable to do it.
I don’t see a problem in making available the DSP56300 emulator binaries. This is not a problem because these binaries doesn’t content any copyrighted stuff and emulating chips by software is perfectly allowed by laws in all countries. There is nothing wrong with this.
What we can’t do and we wont do is encouraging people to infringe copyright laws by downloading copyrighted stuff, what include any ROM file with copyrighted firmware. It must be clear that any message in this direction will be deleted from this forum immediately, as soon as it’s detected by moderators.
Regarding the question of including the DSP56300 emulator by default, we are not going to do this in the short term because of several reasons:
- It only works in Pi5
- It doesn’t work by itself and it’s only useful to Virus hardware owners that have right access to ROM files with the firmware. And this is something that is out of discussion in this forum.
Anyway, we would make available the DSP56300 emulator binaries, and we will do a good integration with the zynthian core so Virus hardware owners can enjoy their favorite synthesizer inside zynthian.
All the best!
11 Likes