No. Currently, a complete list of all possible preset sounds (regardless of which ROMs are installed) is provided in the package (IMHO, regardless of whether it’s oram or vangelis). So you don’t need to do anything.
However, my suggestion would be to adapt the script so that it checks which ROMs are installed (especially the checksums) and generates the list of banks accordingly. In that case, however, the list would no longer be provided in the package, but would have to be generated dynamically.
I thinks this would be better because the user gets instantly an answer if the ROMs are working and if ROMs are missing no presets with no sound would be listed.
Thank you for the explanations. Nevertheless, I already tried to operate your procedure a few days ago, but the system returned that the script wasn’t allowed to run, because of some kind of protection, if I recall correctly:
login as root@zynthian.local
run ./generate_lv2_presets_VirtualJV.py >/zynthian/config/jalv/presets_VirtualJV.json
By the way, I surmise that the second line, with the rightward facing > arrow is a single statement, right?
I am operating on Oram stable from webconf Terminal in /root, where I have placed the script via SFTP.
Anyway, since I unfortunately lack the coding expertise to adapt your script, what would be the rationale and technical goals in doing so? (I might attempt it with the help of AI).
Great work on this! I’m trying with current Vangelis but the banks and presets in the zynthian UI don’t seem to line up with the actual sounds - ie the preset bank/ name for one sound plays a different bank/ sound. Any ideas?
I think I’ve worked out that it only works as expected if all the roms are loaded. If you have any missing then that leads to the mismatch! The idea of just generating presets for the roms you actually have is a good one.
That sounds rather logical, and would explain the fixed offset in patch recall (we could even verify it practically).
In fact, I do not have installed the last two expansion ROMs at the moment, which I did not struggle for because they are of no use for the kind of compositions I write. It makes sense, however, that the preset list generated for the last available plugin in the Zynthian official repo encompasses the patches of all existing ROMs.
Will chase the missing ones and have a try. Thanks for the clever suggestion anyway
I installed all available and legally sourced ROMs, searched again for engines and presets in Webconf > Engines, rebooted, reset the snapshot and armed a chain with VirtualJV.
Now I can select and play presets correctly, and they appear syncronised with the plugin GUI on VNC, which mirrors what is chosen and loaded on the Zynth.
Please, notice that the installation of the instrument is very ROM sensitive: thus make sure that you install all expansion ROMs, as listed in the preset library, and copy in the appropriate places the right jv880_rom2.bin
Cheers
PS I will also check if the plugin is synced two-ways with its native GUI, that is if preset selection and editing via VNC is reflected on Zynthian. Apart from that, VNC will be better switched-off, to preserve system resources, except maybe when it is needed to save the instrument’s configuration used in the snapshot.
Also, when this experimental new feature will be included in a stable release, I would recommend, like others, to have the banks/presets list generated dynamically, according to the available ROMs, instead of being embedded statically in the plugin binary.
Further to my latest post in this thread: i report that the synchronisation of the presets selection is not bi-directional, between the Z interface and the plugin GUI on VNC. Therefore, presets selected on the Z are reflected by the native graphical window, but not the other way around.
Furthermore, there are, apparently at random, patches which suddenly lock the audio engine to a no-output condition, which can be reversed if the saved snapshot is loaded again.
I also noticed that - in comparison with original hardware devices of the JV/JD lineage - loading of the sample content from mass storage memory is detectably slower, than accessing the same rompler data from 8 Mb EPROMs.
While this may seem logical hardware-wise (and taking into account that this synth is a low-level software simulation, of a digital audio processor hardware architecture), still it surprised me a bit, because the Pi 5 processor that churns audio data is by about two orders of magnitude faster than the original Roland DSPs, and my Zynthian plugins run on a fast nvme SSD.
Besides, I experienced a slightly high playing latency (but still acceptable) at 256 samples of duty cycle, with 128 samples the recommendable setting for live performance. This improvement in response is obviously not worthy of the added computational strain on the CPU, for DAW programming and sequencing.
Giulio Is definitely becoming an unstoppable driving force, in the purview of this specific manufacturer’s synthesisers emulations.
It needs to be compiled for Arm64 processors: theoretically, it may seem just a matter of using Projucer and Linux Makefile, with the appropriate libraries and dependencies, but I suspect that it wouldn’t be that straightforward, and that someone with enough coding/compiling expertise could be required.
Yes, it would be cool, to have this forefather of all stage pianos available as a softsynth, with all of its vintagey 80s flair.
Going from what I hear in demos, it shouldn’t be particularly demanding CPU-wise, certainly less than Pianoteq.
Anyway, it’s all down to the computational efficiency of the emulator program, taking into account that the synthesis algorithms run on another software layer, which in turn is the coded simulation of digital circuitry. And this particular model of calculation definitely requires some CPU muscle .
.