You could try this recipe:
git clone --recurse-submodules https://github.com/dsp56300/gearmulator.git
cd gearemulator
umount /tmp
cmake --preset zynthian
cmake --build --preset zynthian --target install
rm -rf /tmp/*
mount /tmp
Regards,
4 Likes
Just tried it out . It’s crazy how well the Virus TI works on the Zynthian. Now all that’s missing are the parameters and the presets . Very good work…
2 Likes
Hi @dsp56300 !
I just tested and both emulators works very nicely. Stability issues seems to have vanished now. Thanks for fixing the “logging” problem.
Please, let’s try to address the preset generation task.
Do you think is possible to implement this workflow from your side:
-
When the emulator is started with a given ROM file, it checks if the presets for this ROM file are generated. Probably, it should check for a LV2 bundle-dir containing the presets.
-
If they doesn’t exist, then it would generate the presets for the ROM
-
If the bundle-dir with the presets does exist for this ROM, then do nothing.
-
I think this is simple enough for you, and it can be easily implemented in the zynthian side:
- We would have a ROM management tab in the webconf.
- When a new ROM is uploaded, replacing the existing one, if any:
- the plugin will be run for preset generation and finished.
- then we will search for new LV2 presets, updating the zynthian presets cache.
Please, tell me if this works for you and i will start working in in our side.
The best!
2 Likes
Great, I will also try this path! 
Hi @dsp56300 and @jofemodo: slight_smile:
Performance report on OsTIrus: it holds well while playing but, at least in my installation, it seems to suffer from random disconnections from the Zynth audio engine. This happens unpredictably, just with certain presets, only while selecting them on VNC, and sometimes when engaging full modulation with the wheel on the keyboard.
I wonder if:
-
Something has gone wrong after all with my compiling from source: there was a passing yellow warning about a missing component, which didn’t interrupt the process.
-
The issue is due to the VNC inherent latency.
-
The problem depends on the yet unresolved single/multi mode operation of the plugin. OsTIrus is almost unresponsive at beginning in single mode, while it reacts on channel 1 to incoming Midi data, when multi mode is activated.
Thanks, and all the best!
edit —
I think the problem runs deeper… I’ll review the thread above to see if there’s any way to change presets from the zynthian interface, rather than the synth UI in VNC… and see if this makes a difference.
I’m having the same issue. It seems that if I move mod wheel to 100% or other midi CC controllers to 100% it seems to crash completely. I’m wondering if the OsTirus has an indexing of 1-128 and zynthian 0-127 or vice versa, causing a null index pointer.
Hi @infinitymodular!
For the time being, the listing of OsTIrus presets and related parameters is not yet implemented, at least going from recent words of the devs, and on the basis of the current source code stored in the github repository (however, they seem to have already a testing internal variant up their sleeves, with exposed parameters and presets).
Yes, thanks for this. I understood that to be the case. During my skim through the conversation I’d noticed a preset template from @jofemodo as below…
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 ; ] .
I thought I might be able to manually play with some files somewhere just for testing. But I guess there’s no shortcut here. It looks like whatever solution happens would need to be a collab between @dsp56300 and @jofemodo and co.
So I will wait patiently on the sidelines. If there’s anything you folk want tested, I’m happy to play.
1 Like
I can confirm, any amount of parameter editing via vnc, causes disconnects of the emu from zynthian engine. Removing the chain and adding it again (essentially rebooting the emu), restores to default state again. I’ve tried playing with the emu’s latency blocks, cpu clocking, sample rate and so on, but the problem persists. Also using the emu “panic / reboot” option causes it to hang. And switching to TI-Snow rom causes it to hang. My bet would be that once controllers are linked to zynthian e.g. like the default “mod wheel” that control parameters of the TI, the same problems will occur. I’m guessing there’s some kind of timing / sync issue between the plugin and the host.
Hi! As far as I can see, the emu and Z devs appear not to have spotted (yet) our desync/audio disconnection issue with OsTIrus, alternatively due to some config/tuning aspect more curated in their software than in our compiled versions, or to them already playing with imported presets onboard the Zynthian.
My guess, going from your words, is that the culprit could be the VNC lan connection and its unavoidable in-out latency, which might randomly disrupt the sync link between the host and the plugin.
How does this disconnect behave? Is the Z audio engine stuck and it displays an overload icon in the upper right or is it running normally and there is just no sound anymore?
There is no Z audio system crash, as a matter of fact. Upon selection of a random preset in VNC the Z audio stops, only to resume when another patch is selected. Contextually, the pointer’s movement on the VNC interface seems a bit slowed-down. The same behaviour happens with certain patches when full modulation is activated.
There is no red warning or red heart signal on Z whatsoever. Honestly, I haven’t investigated if the issue is consistent with specific presets.
EDIT: When I can, I will try and ascertain if certain presets always give the engine stop problem, due to some element of their sound design, or the behaviour is completely random and not patch related.
I’ve noticed something else.
I have two instances open.
1xOstirius
1xNoisemaker
Ostirius plays a bassline and the modweel is mapped to an external controller.
The cut off in Noisemaker is also mapped to an external controller.
If I now move the cutoff of the Noisemaker via the external controller, there are xruns and the red symbol in the Zynthian.
If I change the cut off in the Zynthian this does not happen. Everything plays normally.
- The context, please (hardware & software)
- Could you send the snapshot?
Thanks!
Zynthian V5 RPI oram
Akai LPD8 to USB
LPD8 mapped to Noizemaker Cutoff Freq
If I deactivate the VNC server the problem is gone.
So it seems to be related to the problem described above.
008-groove digga virus.zss (58.0 KB)
If you use NoizeMaker alone, do you have the same issue?
Could you check with more engine combinations?
Thanks
This problem does not exist in connection with other plug ins.
With Osiris it is the same problem as with Ostiris.
Mine would be the first option. Z audio engine stuck and it displays the red icon in upper right.
Any advice (running the latest stable Zynthian build).
Is this a Z 5.1 i.e. a raspberry pi 5 inside?
1 Like