Squinky Labs Ported

Plugins
1

Everything here: VCV Library

But no compII (it’s just a polyphonic compressor so not like you can even use more than one channel on MM)

No seq, as the UI doesn’t make sense for MM

No SFZ player (TBD, this would be cool, but will take some time to compile)

This is probably one of my biggest ports yet, requiring some net new UI/UX to be built for many of the plugins. A lot of the Squinky stuff has drop down menus, which unfortunately aren’t knob assignable - you’ll have to assign those manually on the MM once you port it from VCV - but after that it should work well!

I added labels to show you what the value of those drop down menus are as well.

Definitely try Stairway filt, it sounds really good with many topologies.

cc @danngreen

6 Likes
2

welp there goes my work week!

excellent work sir, really looking fwd to digging into these (and RPJ) asap

3

TY. Do you need a coffee or a footrub? FYI dt, lfn, sub, super, tremelo & vocalfilter are looking for their faceplates.

1 Like
4

Oop - I’ll take a look when I’m back at my desk.

https://ko-fi.com/oksami - only if you feel inclined :slight_smile:

Update: @degarr they load for me. Could you make sure you’re on the latest version (1.0.3)?

If so, you might be running into another issue which is that you have too many plugins loaded, Dan is working on a fix for this I believe in 13.5

1 Like
5

Thanks for this great work! And understandable about SFZ player. I had actually ‘wishlist posted’ about this player previously over on the Modwiggler MM thread. Would be excellent to be able to access something like this in hardware… as for now the only real option is the Disting Multisample algorithm.

6

Stairway is my most used filter in VCV. It is indeed really good.

1 Like
7

It will have been the volume of plugins, removed a few from autoload, rebooted and all good, cheers.

8

@danngreen A lot of SFZ files are huge… is there any way to work with them without needing to load them all into RAM? My guess is probably not - see Orchestra - SFZ Instruments

9

I haven’t looked at how this module works, but in general you can load small bits of a file at a time instead of loading the entire thing into RAM. Sometimes this is called “pre-buffering”: you have a small buffer (say 1-8MB) and you continually load into it from disk while also reading out of it to generate the audio.
The AsyncThread class is designed exactly for this purpose (reading from disk in the background).

10

Going through all the plugins… got a few minor display issues on this one:

  • Some text missing on faceplates: LNFB, Slade aka slew4, Formants, Chopper aka Tremolo, Super aka saws, Shaper… a few others

  • Consider using the module displayName field in the plugin-mm.json to get rid of the “squinkylabs-” prefix on all modules. Also you could use the same names that appear on the faceplates and in VCV (e.g. Slade vs. slew4). We just did this for Bogaudio, and I think it makes it easier to browse the modules.

11

Investigating, and will do on the display name.

It looks like they are trying to use labels, is this supported by the MM? They don’t seem to render.

12

Ah… I never implemented draw() for Labels!

I’ll get on that!

13

OK, I implemented draw().

Interestingly, the VCV Rack implementation of Label::draw()
has a TODO about alignment not working at any font size except the default:

Looking at the Squinky, there are some manual offsets applied to labels which I imagine is done to manually compensate for the text in VCV not being perfectly aligned.

MetaModule’s font engine works well at centering text with any font or size, so it’s sort of a shame to make the MM implementation imitate the Rack implementation by manually un-aligning text. Maybe a better approach is to have MM properly align text and remove those nudge/fiddle numbers from the plugins when built for MM.

In any case, I pushed a version of it with the MM manually un-aligning text, and squinky now looks better (not perfect). I might pull those un-aligning offsets out of the firmware, in which case we’ll also need to remove them from Squinky

14

Thanks! Hmm, in terms of dev experience, it might be annoying to have to manually reset those. Off the top, wondering if we could specify some sort of global label offset flags or choose to refactor into an MMLabel or something? I just don’t want to go and figure out the right offset especially if the original dev used something like Vec(45, 27), where it’s both the offset and the true position of the label baked in, etc.

15

That’s true, it won’t always be obvious how to tweak existing numbers. I can try a bit harder to replicate how the oublendish library is calculating text widths, in order to replicate the rack::Label behavior exactly (though even being off by enough to round a pixel up or down is visible)

I was thinking that for new modules (not ports), it would be annoying to have to manually tweak values in order to center a label (of course you’d still have to do so if you want it to look good within VCV).

Maybe we can just add a new set of enum values to the alignment choices:

	enum Alignment {
		LEFT_ALIGNMENT,
		CENTER_ALIGNMENT,
		RIGHT_ALIGNMENT,
		MM_CENTER_ALIGNMENT,
		MM_RIGHT_ALIGNMENT,
	};
1 Like
16

That seems good! Thank you

17

@danngreen I pushed another update to be included in the next batch - EV3 had some text that was overlaying across the new labels.

I also updated the display names