I was just wondering because most of the emphasis has been on VCV compatible ones (for obvious reasons).
I’ve considered this but find too many reasons to always start with a VCV port - just easier to debug, much nicer to set up a patch in VCV first (as you make a mental connection about the controls and cables) etc.
Yeah, those are some of the “obvious reasons”.
I’ve been making a load of modules for my mm setup and honestly I’ve not found any compelling reason to make them as native. It’s so much easier to build and debug in vcv first, to make your patches and transfer them etc… the whole workflow is so great doing it that way and if your building with the MM in mind your already going to be optimising hard for cpu usage so I can’t really imagine working any other way.
I would guess most plugin developers are going to want to make their work available in vcv rack as well so I’d doubt we’ll see many purely native models popping up tbh
OK…I was just curious because there seems to be very little interest on VCV for MM. I just resurrected a thread over there that died back in Sept. I guess people don’t get the synergy between VCV Rack and MM: 4ms Meta - Rackception - #176 by auxmux - Lounge - VCV Community
I feel like in terms of development you’ll see developers making things with the MM specifically in mind, but with the added bonus that you can provide them for vcv rack as well, and have access to a really good build and debug workflow (which is definitely more complicated on pure hardware targets). I know a few people are waiting on Cycling’74 to make their bare metal RNBO engine public as well so they can start creating stuff, and that will also work in VCV on the desktop, so from a developer p.o.v I feel like it’s just a matter of time. V2 will really help with this too I’m sure, once people see they can work with samples etc…
From a user perspective I can’t really comment because as soon as I know I can write code for a module that’s what’s going to happen 
1 Like
I hope more VCV devs and hardware companies jump on the train. Embedded and MM are the future!
All the 4ms modules are native. We’re releasing a set of drum modules soon that are also native. They compile as VCV modules and as MM modules, so you still get the nice workflow of being able to test them out on VCV and the simulator before running them on hardware.
The native API offers more possibilities to optimize the code, e.g. only re-calculate filter coefficients when a knob is actually moved. You can do that in VCV modules too but you have to implement it manually.
Also, with the native API you can’t accidentally use some unsupported feature.
But neither of these benefits are really huge compelling reasons. I think it just boils down to just developer preference for which API is more comfortable.
We developed the native API first, before ever considering having Rack modules ported to the platform. So it was made with embedded systems in mind. But the Rack adapter layer does a pretty good job of keeping it efficient, too.
3 Likes