I would just add that this should apply to all the devices supported by emulators that need original firmware.
e.g. DSP56300 also emulates Waldorf microQ, Microwave XT II, Clavia Nord Lead 2x and soon others which all have the same issue. Same goes for Nuked-SC55, Munt and others.
It might be worth putting these in a separate category to make it clear that only owners of the appropriate hardware can use them legally.
(one good use I can see is if you have a device and it’s broken)
I think Jofemofo has made the right decision. But one last note on the issue then I’ll finally shut up.
I think statements like “It’s not happening” are a little naive when discussing intellectual property. I’d like to remind people that PropellorHeads legitimately sold ReBirth for 20 years, and then got stopped by Roland.
One of the great things about technology is it’s ability to apply rule sets rigorously.
It’s getting the human agreement to define the areas that is where the issues arise.
The parallels within the linux distribution world to the issues being flushed out by the zynthian eco system are quite reassuring.
But I’m a Nord modular user so deeply biased. I had Virus envy at the time.
May i ask how you get around the link step here:
[188/189] Linking CXX shared module source/osTIrusJucePlugin/osTIrusJucePlugin_artefacts/Release/LV2/OsTIrus.lv2/libOsTIrus.so
FAILED: source/osTIrusJucePlugin/osTIrusJucePlugin_artefacts/Release/LV2/OsTIrus.lv2/libOsTIrus.so
: && /usr/bin/c++ -fPIC -march=armv8.2-a -DZYNTHIAN -O3 -DNDEBUG -Ofast -fno-stack-protector -flto=auto -fno-fat-lto-objects -Wl,–no-undefined -shared -o source/osTIrusJucePlugin/osTIrusJucePlugin_artefacts/Release/LV2/OsTIrus.lv2/libOsTIrus.so source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_utils/juce_audio_utils.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_processors/juce_audio_processors.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_processors/juce_audio_processors_ara.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_processors/juce_audio_processors_lv2_libs.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_gui_extra/juce_gui_extra.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_gui_basics/juce_gui_basics.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_graphics/juce_graphics.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_events/juce_events.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_core/juce_core.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_data_structures/juce_data_structures.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_basics/juce_audio_basics.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_formats/juce_audio_formats.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_devices/juce_audio_devices.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_cryptography/juce_cryptography.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_AAX.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_AAX_utils.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_ARA.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_LV2.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_Standalone.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_Unity.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_VST2.cpp.o source/osTIrusJucePlugin/CMakeFiles/osTIrusJucePlugin_LV2.dir//JUCE/modules/juce_audio_plugin_client/juce_audio_plugin_client_VST3.cpp.o source/osTIrusJucePlugin/osTIrusJucePlugin_artefacts/Release/libOsTIrus_SharedCode.a source/osTIrusJucePlugin/libosTIrusJucePlugin_BinaryData.a source/virusJucePlugin/libvirusJucePlugin.a source/jucePluginEditorLib/libjucePluginEditorLib.a source/jucePluginLib/libjucePluginLib.a source/juceUiLib/libjuceUiLib.a source/jucePluginData/libjucePluginData.a source/virusLib/libvirusLib.a source/synthLib/libsynthLib.a source/libresample/libresample.a source/dsp56300/source/dsp56kEmu/libdsp56kEmu.a source/dsp56300/source/vtuneSdk/libvtuneSdk.a source/dsp56300/source/asmjit/libasmjit.a source/baseLib/libbaseLib.a /usr/lib/aarch64-linux-gnu/libfreetype.so /usr/lib/aarch64-linux-gnu/libasound.so -lrt -ldl -lpthread -static-libgcc -static-libstdc++ && cd /root/gearmulator/temp/cmake_zynthian/source/osTIrusJucePlugin && /root/gearmulator/temp/cmake_zynthian/source/osirusJucePlugin/juce_lv2_helper /root/gearmulator/temp/cmake_zynthian/source/osTIrusJucePlugin/osTIrusJucePlugin_artefacts/Release/LV2/OsTIrus.lv2/libOsTIrus.so
In function ‘__copy_m’,
inlined from ‘__copy_move_a2’ at /usr/include/c++/12/bits/stl_algobase.h:495:30,
inlined from ‘__copy_move_a1’ at /usr/include/c++/12/bits/stl_algobase.h:522:42,
inlined from ‘__copy_move_a’ at /usr/include/c++/12/bits/stl_algobase.h:529:31,
inlined from ‘copy’ at /usr/include/c++/12/bits/stl_algobase.h:620:7,
inlined from ‘__uninit_copy’ at /usr/include/c++/12/bits/stl_uninitialized.h:147:27,
inlined from ‘uninitialized_copy’ at /usr/include/c++/12/bits/stl_uninitialized.h:185:15,
inlined from ‘__uninitialized_copy_a’ at /usr/include/c++/12/bits/stl_uninitialized.h:372:37,
inlined from ‘__uninitialized_move_if_noexcept_a’ at /usr/include/c++/12/bits/stl_uninitialized.h:397:2,
inlined from ‘_M_range_insert’ at /usr/include/c++/12/bits/vector.tcc:801:9,
inlined from ‘_M_insert_dispatch’ at /usr/include/c++/12/bits/stl_vector.h:1779:19,
inlined from ‘insert’ at /usr/include/c++/12/bits/stl_vector.h:1481:22,
inlined from ‘exportLv2Presets’ at /root/gearmulator/source/virusJucePlugin/VirusProcessor.cpp:193:26:
/usr/include/c++/12/bits/stl_algobase.h:431:30: warning: ‘memcpy’ reading 1 or more bytes from a region of size 0 [-Wstringop-overread]
431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ^
In member function ‘allocate’,
inlined from ‘allocate’ at /usr/include/c++/12/bits/alloc_traits.h:464:28,
inlined from ‘_M_allocate’ at /usr/include/c++/12/bits/stl_vector.h:378:33,
inlined from ‘_M_allocate_and_copy’ at /usr/include/c++/12/bits/stl_vector.h:1614:40,
inlined from ‘_M_assign_aux’ at /usr/include/c++/12/bits/vector.tcc:318:40,
inlined from ‘operator=’ at /usr/include/c++/12/bits/stl_vector.h:785:21,
inlined from ‘exportLv2Presets’ at /root/gearmulator/source/virusJucePlugin/VirusProcessor.cpp:192:172:
/usr/include/c++/12/bits/new_allocator.h:137:55: note: at offset 9 into source object of size 9 allocated by ‘operator new’
137 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n * sizeof(_Tp)));
| ^
In function ‘__copy_m’,
inlined from ‘__copy_move_a2’ at /usr/include/c++/12/bits/stl_algobase.h:495:30,
inlined from ‘__copy_move_a1’ at /usr/include/c++/12/bits/stl_algobase.h:522:42,
inlined from ‘__copy_move_a’ at /usr/include/c++/12/bits/stl_algobase.h:529:31,
inlined from ‘copy’ at /usr/include/c++/12/bits/stl_algobase.h:620:7,
inlined from ‘__uninit_copy’ at /usr/include/c++/12/bits/stl_uninitialized.h:147:27,
inlined from ‘uninitialized_copy’ at /usr/include/c++/12/bits/stl_uninitialized.h:185:15,
inlined from ‘__uninitialized_copy_a’ at /usr/include/c++/12/bits/stl_uninitialized.h:372:37,
inlined from ‘__uninitialized_move_if_noexcept_a’ at /usr/include/c++/12/bits/stl_uninitialized.h:397:2,
inlined from ‘_M_range_insert’ at /usr/include/c++/12/bits/vector.tcc:801:9,
inlined from ‘_M_insert_dispatch’ at /usr/include/c++/12/bits/stl_vector.h:1779:19,
inlined from ‘insert’ at /usr/include/c++/12/bits/stl_vector.h:1481:22,
inlined from ‘exportLv2Presets’ at /root/gearmulator/source/virusJucePlugin/VirusProcessor.cpp:193:26:
/usr/include/c++/12/bits/stl_algobase.h:431:30: warning: ‘memcpy’ reading 1 or more bytes from a region of size 0 [-Wstringop-overread]
431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ^
In member function ‘allocate’,
inlined from ‘allocate’ at /usr/include/c++/12/bits/alloc_traits.h:464:28,
inlined from ‘_M_allocate’ at /usr/include/c++/12/bits/stl_vector.h:378:33,
inlined from ‘_M_allocate_and_copy’ at /usr/include/c++/12/bits/stl_vector.h:1614:40,
inlined from ‘_M_assign_aux’ at /usr/include/c++/12/bits/vector.tcc:318:40,
inlined from ‘operator=’ at /usr/include/c++/12/bits/stl_vector.h:785:21,
inlined from ‘exportLv2Presets’ at /root/gearmulator/source/virusJucePlugin/VirusProcessor.cpp:192:172:
/usr/include/c++/12/bits/new_allocator.h:137:55: note: at offset 9 into source object of size 9 allocated by ‘operator new’
137 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n * sizeof(_Tp)));
| ^
Illegal instruction
ninja: build stopped: subcommand failed.
(venv) root@zynthian:~/gearmulator#
?
The compiling routine is not stable yet, and it does not proceed consistently on all Oram systems each time one attempts it. I suggest you report upstream. Regards
Have you actually heard about Access trying to sell the DSP code to another company or was that purely speculation? Because otherwise - and this is maybe a bit naïve - has anyone actually contacted Access or whoever owns the ROM contents now, and simply ask if they would consider releasing the binary ROM code (perhaps under some proviso, that no one reverse engineers the code)?
Sure, they’ve invested a lot of time into their DSP code, but it’s also true that they have gotten their return own their investment with years of sales of Virus synths, and the ROM binaries are basically useless from a production point of view as they require now-obsolete (or nearly obsolete) hardware to run on (i.e. in terms of the DSP56000 DSP’s that they are intended to run on). Assuming they or someone else would want to start manufacturing Virus synths again, it would be more likely that they would want or need to revamp the code to be compatible with modern hardware, a modified feature set, etc.
So it would seem that the ROMs are actually virtually useless to Acccess, and thus it would not be a great loss for them to release them, quite the contrary as it would be an act of goodwill towards the synth community. It’s not like Access is Nintendo (although their owners might at like them, who knows). At least I don’t think it would hurt to ask; it’s not like they would be unaware about the existence of Osiris/Ostiris.
As far as I know, @dsp56300 the makers of the DSP56300 were in contact with Waldorf and Access.
You can read what happened in the Sequenzer.de forum.
Although it is not explicitly stated anywhere, in their blog or Discord channel, I too consider likely that @dsp56300 aka The Usual Suspects contacted Access and Waldorf, about the demanding retro-engineering enterprise they were embarking on.
Gestures of corporate-level goodwill are not unheard of in the music tec world: the devolution to Dave Smith of the original Sequential Circuits trademark on the part of Yamaha comes obviously to mind.
Still, we ignore what value old firmware binaries can actually represent for their owners. There might be a symbolic vintage potential for synth reissues, or parts of DSP code are deemed characterising for a brand-specific sonic imprint, or else (with @ricard) ROM binaries actually hold little residual value, in the face of their prospective reuse in a different hardware architecture.
Moreover, I would suggest to adopt from now on a purely technical and goal-oriented attitude in this thread.
There has been quite a bit of both constructive and non-constructive arguing over here, over the various implications of integrating DSP emus in Zynthian.
Let us keep the discussion on a positive technical level henceforth (bugs, solutions, advancements, etc.), avoiding direct mentions of third-party corporate strategies and copyright issues, since a stance on the subject has been already taken and clarified by the Zynthian Labs.
Most of all, in any case, let us focus on ideas and not on the presumed standpoint of their bringers.
Best regards
I don’t know if it is relevant, but while compiling from source OsTIrus and Osirus on my custom Pi5 Oram Z station, with the prescribed commands:
git clone --recurse-submodules GitHub - dsp56300/gearmulator: Emulation of classic VA synths of the late 90s/2000s that are based on Motorola 56300 family DSPs
cd gearmulator
cmake --preset zynthian
cmake --build --preset zynthian --target install
I get this yellow warning, without further visibile consequences for the outcome of the whole process:
CMake Warning at source/findvst2.cmake:10 (message):
rclone.conf not found, unable to copy VST2 SDK
Call Stack (most recent call first):
source/CMakeLists.txt:25 (include)
Also, while regenerating OsTIrus presets, the system returns, apparently pointing to some syntax error in the ttl manifest file:
Regenerating LV2 presets DB: http://theusualsuspects.lv2.OsTIrus …
INFO:root:Workaround took 14s
error: /zynthian/zynthian-my-data/presets/lv2/OsTIrus_TI2_Rom_U.lv2/S_y__TI___.t
tl:12:18: missing ‘;’ or ‘.’
lilv_world_load_file(): error: Error loading file file:///zynthian/zynthian-my- data/presets/lv2/OsTIrus_TI2_Rom_U.lv2/S_y__TI___.ttl' error: /zynthian/zynthian-my-data/presets/lv2/OsTIrus_TI2_Rom_S.lv2/___U____CC.t tl:12:16: missing ';' or '.' lilv_world_load_file(): error: Error loading file file:///zynthian/zynthian-my-
data/presets/lv2/OsTIrus_TI2_Rom_S.lv2/___U____CC.ttl’
INFO:root:Command took 15s
Running Flag Actions from '/zynthian/zynthian-sys/sbin/regenerate_lv2_presets.sh
Anyway, most OsTIrus presets are there.
Edited: It is maybe worth mentioning that I still do not obtain the Virus C banks A and B.
Best regards!
Hi @ledan,
Just to be sure, have you removed the 100 Mb system temp file limit, before trying to compile the plugins from source?
This is the procedure:
1] Enter Terminal in Webconf or connect via SSH.
2] Edit the file fstab with:
nano /etc/fstab
3] Comment with # the lower third line, thus deactivating the following string of statements:
proc /proc proc defaults 0 0
PARTUUID=a78e54ac-01 /boot/firmware vfat defaults 0 2
PARTUUID=a78e54ac-02 / ext4 defaults,noatime 0 1
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
4] Save and exit (ctrl+x then ctrl+y then enter)
5] Reboot Zynthian.
IMPORTANT: after successfully compiling remember to remove the hashtag and save again, in order to reactivate the size limit set for the system temp file. Not doing so might harm the correct operation of the Zynthian OS.
Best regards
As far as I can make out after reading sequencer.de @dsp56300 has been in contact with all manufacturers. Most of them have not answered at all and have remained silent. I think Christoph Kemper initially expressed his personal enthusiasm for the project because it was keeping the Virus heritage alive but then also fell silent.
I think the reason is that legally it is tricky ground, and no manfufacturer wants to spend money on crafting a legal statement one way or the other, especially not Access who has left the Virus dead in the marketplace even if they still hold the intellectual property rights to it. When these synths were manufactured, the idea of being able to emulate them using the binary code on a completely different hardware was totally far out. So the licensing of the synth never included such statements as “The binary code in this product may not be used for other purposes”; indeed, cloning of musical products has not been a thing until Behringer showed up, and even then their products are generally not exact clones anyway. Thus it’s hard to crack down on copies of the ROMs because frankly, they’re out there and not hard to obtain, at the same time, they might want to issue a rerelease of a Virus in the future running on a DSP56300-emulating FPGA or whatever. I’m not even sure it’s legal to make a personal copy of the ROM in my Virus KC in order to run it on different hardware. Although likely not explicitly stated, that was not the intention of the instrument when it was manufactured, someone might claim.
So the best route for these manufacturers at this time is probably just to keep silent, and raise a racket if and when it becomes a problem for them, just like Roland did with ReBirth (which by the way was history to Propellerhead anyway when Roland clamped down on them in 2017, not having been supported for several years).
So, FWIW, I agree with @jofemodo that the best route for Zynthian is to ‘facilitate but not actively endorse’ the use of these emulators together with their required ROMs. Something could blow up at any time and we don’t want Zynthian to be a target.
I must admit though that it it is the prospect of running a Virus C on Zynthian that has seriously made me consder purchasing a new V5 to completment my V4…
Thx Aethermind,
i made the steps suggested by you here (also made sure to pull the latest from the repo) and then started the build process. What i do notice is that it goes successful for quite some time, before it gets “stuck” in various stages for a long/eternal time. When this happens i restart the unit and retry it. The last time i’m doing it (actually right now), it stuck at this point:
(venv) root@zynthian:~# cd gearmulator
(venv) root@zynthian:~/gearmulator# cmake --build --preset zynthian --target cle an
[0/2] Re-checking globbed directories…
[1/1] Cleaning all built files…
Cleaning… 809 files.
(venv) root@zynthian:~/gearmulator# cmake --build --preset zynthian --target ins tall
[0/2] Re-checking globbed directories…
[592/617] Building CXX object source/o…/juce_gui_basics/juce_gui_basics.cpp.o
So close, yet so far away 
I guess with some luck, it might be successful one of these trials.
But at least i’m getting somewhere now so big thank you for outlining the steps.
br
Hi @ledan!
Just because it worked for me once, try to press return at a given time, when the process seems to be stuck.
I am not sure that it does any sense, but it seems that at times the ensuing statements of a complex command sequence need to be “confirmed” with enter.
Just guessing, and anyway keep in mind that I am not a Linux CLI expert, but a patient collector step-by-step of working bits! 
Also, I recommend checking that you have a stable and robust Internet connection reaching the Zynthian, for the compiling routine to access the required online components.
Best wishes 
Hi @ricard 
Thanks for you contribution to the topic, all the most welcome since it comes from a distinguished plugin programmer for this platform.
With regards to the subject that you raise, I think that we should just abide to the discussion rules about firmware files installation, shared by the @dsp56300 community and also adopted by the Zynthian developers, whose formulation I quote thereby:
“Per our very simple and straightforward rules we will not tolerate any requests for additional information, further explanation, or any further discussion of this issue. As a legal owner of the hardware synthesizer, you are entitled to possess a backup copy of the firmware files taken (dumped) from the EEPROMs in your hardware synth. While we are unable to provide, facilitate, or permit any direct assistance to anyone here for how to achieve this process, a simple internet search for similar support issues other hardware owners have overcome in the past should provide you with information to assist in efforts to do so”
I am fairly confident that the collective of skilled Osirus/OsTIrus coders will have already and extensively pondered all the implications and limitations, of running simulations of DSP hardware on CPUs.
By the way, I did not manage to find the article on the German site attached, relating the interesting background story behind the Virus emulation project.
All best regards
Somewhere here …
Thank you @highsiderr 
Hi @highsiderr
I have researched on your suggested model of multitimbral usage of OsTirus, and now I am able to arm a multichannel layout with just an engine instance, driven by further MIDI chains thanks to the ingenious internal rooting of Midi data devised by @jofemodo and @riban.
I must say that for me this is already a huge step forward, on the path of the real-world OsTIrus usability on the Zynth. 
Nevertheless, what remains to be ironed out, for my specific use scenario, is how to select a Multi patch saved on VNC from an external DAW, which for me is important because I use Zynthian primarily as a multi-channel Midi receiver, for externally arranged compositions.
In a nutshell, what I aim at for the time being - until a complete integration of the plugin is achieved - is not to change presets within a Multi on the Zynthian, but to be able to recall consistently a saved Multi from a DAW, for the Z to play the Midi flow that I am sending to it (while also potentially receiving individual program and parameter changes, on different Midi channels of the same Multi).
I have investigated on the topic, on the basis of the original hardware’s documentation and other online knowledge, and so far I have come up with the following workflow, for selecting a Multi patch within a specific user-saved bank:
1] Instruct the synth to switch from Single to Multi mode, by sending:
CC122 as on/off (presumably 1/0) toggle
and/or a sysex message with the HEX syntax
F0 00 20 33 01 dd 72 00 7A vv F7
where dd addresses the Device ID and vv the Midi mode (0, 1, 2).
2] Dispatch a bank select command to the plugin, by using CC0 (MSB) and CC32 (LSB).
3] Point at a specific Multi preset in the selected Multi bank, with a Program Change message.
Notwithstanding, I did not manage to make it work until now, and OsTIrus does not respond to my externally sent Midi configuration commands.
As far as I can see, these could be the possible issues:
A) My Multi patches selection procedure is simply mistaken.
B) OsTIrus does not receive Midi config messages because they aren’t sent to its Midi Global Channel, but I have not been able to find a related selector in the Common and Menu areas of the plugin’s GUI on VNC. For the moment, I am surmising that it might be Ch 1.
C) OsTIrus does not receive Midi config messages because the Midi IN port is not correctly set, as either Port 0 or f_Midi, however the engine loaded on Zynthian appears to receive Midi messages through both ports, with a reassuring blinking “m” symbol.
I will maybe try to report the problem upstream, unless @dsp56300 shows up here to offer some direct insight!
The ultimate goal would be to reliably recall and control Multi patches on Osirus and OsTirus, from an external computer or sequencer, switching on the VNC server only for designing Single presets and building Multi layouts.
Best regards
-Switch Ostirus to multi mode in VNC.
-Save a preset in Zynthian via its GUI, e.g. name it Multimode.
-Save a snapshot.
You can now either load this snapshot manually or call it up via Midi.
Hmmm… Interesting,
So, if I read your words correctly, you may mean that I could save a preset on a Zynthian chain armed with OsTIrus, even if no plugin parameter has been actually edited on board, and that if I save a snapshot with that chain it will recall on reload what Multi patch was selected in VNC on the synth GUI, when the preset was created on the Z and the snapshot saved.
It would maybe be consequential that afterwards I could switch the VNC server off, and use the created snapshot and preset without it.
I will have a bit of experimentation with this, and get back here.
Thank you, all best regards.