Interesting, I’m using metamodule simulator to make tests, and all settings are transferred using it. Can you send your patch file to sickozell@sickozell.org to make some comparison? Thanks
Atm, I’m creating a new patch with six SickoCV plugins. I can save and sent the version saved from vcv and afterwards from MM (same settings). This should be a good base for a comparision.
So it works? I don’t understand
I have carefully completed and tested the patch. All modules were loaded with v0.7 and v2 11.3 and the settings were adopted.
1 Like
I noticed, too. That the midi map inside MM doesn’t work with the SickoCV modules either. It’s the same behavior, after restarting MM you can see that modul is mapped with MIDI Clk/12 but on the scope the is no reaction. After remapping everything works. So atm, I have to do the midi wiring afterwords in MM with the midi modul.
Sick.yml (593.3 KB)
It seems that the size of your patch file depends on OrangeLine:Morpheus settings
Ah okay. I had Dejavu from OrangeLine before.
I’m away from the computer and can’t test loading patches right now but can chime in:
The “v2.0.0” needs to be there for the Auto-loader to find it. If the version is missing then the auto-loader assumes v1.x and ignores it.
But you can still load the plugin manually without the version.
Our CI release script adds this suffix when we generate a release.
Are you getting this message when you transfer over wifi?
It means that you modified the patch on the MetaModule and also send a new version over wifi. So now you have two different versions and the MetaModule doesn’t know which one you want to keep.
Or else if you see this without using wifi, then it’s a bug (it’s a new feature so maybe there are still bugs?)
Yes, several OrangeLine modules save a lot of data in the patch (32kB or more sometimes). So if you use those modules the patch file might be big.
It doesn’t make it consume more CPU, it just takes a moment longer to transfer over wifi and load.
I’ve just a sd card, so no wifi or usb transfer.
Ah, ok then that’s a bug!
I tried and did a lot in MM yesterday. But at the end, when I finished my final patch, I was not able to save the patch. I’m not sure about the exact wording, but something like “failure to save the patch”. I can try to get a picture…
It needs a couple of tries till MM save the patch also after a restart.
Aha, good find! That was a bug, not just for a Sickozell modules but for any module with a MIDI CLK or transport mapping when mapped to an input jack whose module reads the number of channels on that jack. On initial patch load, the jack would appear as unpatched. I’ll push the fix for this in the next version
Nice to hear. This fix could save some work afterwards. You can continue this topic in…
So when everything works, can I choose different clock divider in one patch or do they need same one (like transfering a patch from vcv). So how does it work finally…?
@sickozell @danngreen The latest dev version 2.0.0-dev-12.0) broke compatibility with Sickozell modules. Any idea when you can recompile?
Recompiled v0.8 with latest firmware, let me know if it works
Name needs to be changed to SickoCV-v2.0.0-dev-12.0.mmplugin
@sickozell - the sickosampler module is working great so far for playing back and mangling loops! ty for porting this! excited to play with further.
one question: im noticing that when saving the yml file from vcv, the path to the sample shows up as “E:\sounds\grain texture1.wav” whereas it needs to be “sdc:/sounds/grain texture1.wav” for it to work right off the bat on the mm via the microsd… im curious if there’s a way to have that path corrected to the mm format when saving the yml? or is that a function that needs to live within the metamodule itself? for now i can certainly edit the yml w a text file and fix it manually.
Hmm… we could try to handle this on the MM since it’s going to come up with any module that uses external files. But – the question is how to know what path the user actually wanted – ie., should E:\sounds\grain.wav be sdcard:/sounds/grain.wav or should it be usb:/sounds/grain.wav ? And what about /User/MyName/Documents/Rack/Samples/grain.wav or paths that are on a hard drive?
It’d be great to have a clean and simple way to handle this. Maybe something on the MM Hub module in VCV that lets you set up “path maps”, so you would tell it "E:\ => “sdcard:/” or “/home/me/docs/samples/ => usb:/”? And that info would live in the patch file. Still not sure about this…
1 Like
My sampler modules have the ability to store the samples in the patch file, so it could be a starting point. But I know not all the developers use this way.
personally think that’s a great idea! could be useful to have something similar to the ‘set wifi expander address’ pop up. that way each patch, if we wanted, could point to a different folder. i always try to keep life simple so storing everything inside a ‘sounds’ folder on the sdc is the way for me. perhaps if nothing is specified in the vcv mm, the hardware could default to looking inside a ‘sounds’ or ‘samples’ folder? as opposed to us having the set the path with each new patch (edit: NM on that- i see that the wifi url can be saved directly within the metamodule/vcv starter template… so a files path could obvs be saved there too)
i noticed the .vcv sizes reflected the sample file sizes. awesome. honestly i love that your modules have that ability- ty for that!! that’s been REALLY quick and useful when moving .vcv files around between my main fixed computer and remote laptop used for sketching wherever.