Sickozell plugin

Hi everyone,
I have received several requests to port the Sickozell plugin to metamodule, especially for the samplers.
I started converting the more ‘simple’ modules successfully, personally I can’t do any tests because I don’t have eurorack hardware, but some friends told me that they work.

For the samplers conversion it is still early, because the filesystem libraries I use and nanovg for drawing on the panels are not supported by mm.

I will post future updates here

12 Likes

Thank you for putting in the work on this! It will be great to have your samplers and loopers once the firmware supports it.

2 Likes

awesome super excited @sickozell to have your modules on mm! definitely especially the samplers. i know it will be some time before they are fully working on mm, but seriously excited for when they do

2 Likes

Awesome! I just responded in the other thread. The v2.0-dev branch of the SDK does support nanovg calls for drawing on the panels (requires v2.0-dev firmware, of cousre)

Also, there’s a MetaModule simulator that runs on a host OS (using SDL for graphics and audio), and I recently merged in some support for running plugins. metamodule/simulator at main · 4ms/metamodule · GitHub
and
metamodule/simulator/ext-plugins.cmake at main · 4ms/metamodule · GitHub

Probably a better conversation on the other thread in Plugin Developement, but thought you might want to know!

2 Likes

This is amazing news, I find your various collection buffered modules, sickoLooper3, and sickoSampler2 to be amazing creations that open up creativity in my brain and rack!

1 Like

I ported the modules that don’t need samples, if anyone is interested in testing a beta version please send me a direct message. Thank you.

Edit:
I uploaded binary on github.
Follow this link to download:

3 Likes

Awesome! I just am trying them out now. Very cool…

1 Like

I had hoped for sampler and looper functionality even before purchasing the meta module. I had previously requested work from @sickozell through this platform, and although it is unfortunate that it is not possible yet due to issues with the SDK, I am very glad that @sickozell has personally appeared and is being proactive. Thank you for your hard work on the development.

1 Like

Some adjustment is still needed on sickoQuant and sickoQuant4 for displaying scale text with nanovg in the right place/size.

I don’t know if the other modules (tested with the v2. 0 simulator) work well on hardware with older firmware.

I’ll try porting sickoSampler2, without load/save functionality, at least to see if it works.

1 Like

Published v0.2 with sickoSampler2 added with no load/save functionalities.

I noticed that recorded waveform (nanovg) is displayed only entering in module properties, the same with sickoQuant for scales display.
@danngreen : is this behaviour correct when using nanovg?

Yeah, for now. I haven’t introduced graphic displays when in patch view yet.

Ah, I know what this is – the vgatrue.ttf font is missing from the .mmplugin file, so it uses a default font.
I untarred the Sickzell.mmplugin, added the ttf file, then tarred it back up, and the Quant modules look a lot better. If you just put the ttf file in the assets/ dir before building, the cmake script will bundle it up for you.

True, thanks. I saw that the list of parameters is in alphabetical order. Do you think it’s a good idea to rename the parameter labels with a prefix to be able to scroll through them in a more logical order?

You mean on the Module View page? The parameter and jack names should just be in the order of the VCV rack param ID number. For example, CVswitcher has:

	enum ParamId {
		THRESHOLD_PARAM,
		THRESHOLD_ATTENUV_PARAM,
		FADE_PARAM,
		PARAMS_LEN
	};

So the params are listed in that order: Threshold, Threshold CV, Fade Time.
Input jacks are listed before Output jacks, but the same ordering applies to them.

I thought about some way to make a custom ordering, since on VCV there’s no real “order”… maybe a user setting like “Top->Bottom order”, “Left->Right order”, “VCV ID order”, “Alphabetical order”

What we did with presets is we noticed the Fundamental Quantizer has all the preset files ordered with a ##_ prefix (like 01_Ionian). So we first sort them alphabetically/numerically, and then strip the leading ##_ prefix since it’s ugly and takes up space on the small screen. We could maybe do something like that for parameters, thought it would have to be something that won’t conflict with any existing names (maybe double underscore: __01__PitchCV??)

Ok, so if used something like this

enum ParamId {
   ENUMS(ADDSUB_SWITCH,8),
   ENUMS(VOLT_PARAMS,8),
   ENUMS(MODE_SWITCH,8),
   OUTMODE_SWITCH,
   PARAMS_LEN
};

in the Module View page I will always get all the ADDSUB_SWITCH before the VOLT_PARAMS.

I think it would be better this order:
ADDSUB_SWITCH+0 ,
VOLT_PARAMS+0,
MODE_SWITCH+0,
ADDSUB_SWITCH+1,
VOLT_PARAMS+1 … etc

is there a way around this problem?

I published v0.3 with sickoLooper1 sickoLooperX sickoLooper3 with no load/save functionalities

1 Like

We’d have to add something to make this work. Like a prefix to the parameter name. Right now it just takes the order that they’re in VCV.

Another way might be a function to call when registering the module, like setParameterOrder({ADDSUB_SWITCH+0, VOLT_PARAMS+0, MODE_SWITCH+0, ADDSUB_SWITCH+1, ...})

Either way you’d have to have the code be different for a MetaModule build vs VCV build, so it’s not ideal… but maybe tolerable since it’s an optional/extended feature.

1 Like

SickoLooper1 is working great for me on the dev-11.1 firmware . Getting 20% cpu at 48khz/256 in a solo patch. Thanks so much for working on porting your plugin (use Sicko modules all the time in VCVRack).

2 Likes

Hi!

I was writing a post how we NEED your plugins for accurate clocking then saw there was already a post here. Do you think you could port over the clocker so I can dial in like 120 bpm, 90 bpm! Either version of your clocker would be fine! Many music producers that make certain stems to sell on the market need a very accurate clock.

  1. Dub: 60 to 90 BPM
  2. Downtempo and Chillout: 80 to 110 BPM
  3. Hip Hop: 85 to 110 BPM
  4. Breakbeat: 110 to 150 BPM
  5. House: 115 to 130 BPM
  6. Trance: 120 to 140 BPM
  7. Techno: 120 to 140 BPM
  8. Future House: 120 to 130 BPM

So on and so forth. I don’t see a module that lets you dial in an exact BPM as a clock source in MM. All of the clocks I see for the MM seem to be dial based with no display and you hope it’s a specific clock speed. I could use my Mordax Data for the clock input as well as Ableton Live CV Tools when I record, but still would prefer an internal clock to try to shorten the slight lag time from clock input to audio or CV output to mess around without having to load up the DAW.

As an aside as this question is for 4MS, does the Gate 1 & 2 inputs on the MM have less lag then just using the CV ins? If not, then why not just have all of the inputs CV ins?

Clocker2 is already ported

I suggest you to open a new thread for gate inputs lag

Really awesome! Thank you!

1 Like