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
1 Like
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
Glad to see mention of RNBO here @twhiston 
. The patching environment of Max/MSP to me presents a very attractive place to start development of something I would wish in the end to use in Eurorack via MetaModule. So RNBO C++ export to VCV Rack v2 modules sounds promising.
Hardware wise Raspberry Pi is by far the best supported at the moment, but I see Cycling74 has now proof-of-concept integration of RNBO with the Daisy eurorack module: Example of how to use RNBO code on the Daisy Audio Platform.
To get to MetaModule via VCV rack I cannot find anything more solid than this still (including on Max or VCV forums): an example of using RNBO exports in VCV Rack pluginsā VCV Rack Starter | Cycling '74. @TheTechnobear .. I saw a forum entry where it seemed youāve been trying?
I am planning to explore this more myself, but would love to find more resources. A start project might be one or two RNBO Guitar Pedals | Cycling '74 to MetaModule. Just locally for now, as licensing issues are something to bare in mind: Rack + Cycling '74 RNBO - VCV Rack
1 Like
yeah, Ive got RNBO working on the MetaModule 
C74 were kind enough to grant me access to the closed beta, so I could experiment with the bare metal (aka minimal export) thats required for using with Meta Module.
I got it working without too much hassle as a proof on concept 
also Ive been using it to play with the custom graphics on the MM.
but, I then put it on the back burner, until (new version of ) RNBO was released, which it was recently ! - so in theory ready to go now.
nowā¦ as you mention, theres 2 parts to rnbo
a) producing the underlying DSP code
b) having a means to use that code.
we need a UI, to use that DSP code, and also to āattachā it to the hardware.
C74 have a specific export for things like the rPI, VSTs etc, but they wont do this for more āniche productsā. - instead what we use is a ātemplateā (which we have to create)
C74 have created one for VCV, but itās not really suitable for the MM esp for āend usersā, theres quite a bit of extra āglueā required for non devs to use.
SO, my current plan/idea is to do what I did with the Percussa SSP (and RNBO).
which is to create a template, to try to minimise effort to get it working on the MM.
if possible, to a level where end-users can just create a rnbo patch, then āgenerateā whats needed to get a full MM module.
shouldnāt be too tricky, as Ive got the MM side working with RNBO, and the rest Ive already done for the SSP.
(Im hoping I can try to make this a bit generic, so SSP/MM share same process)
whats nice about the approach Ive taken with the SSP is that, you can take the āstandard moduleā it creates and then edit it.
so Iāve used the generation process to create some modules for prototyping purposes, and then edit them to put a āfancy UIā on them.
(e.g. I created a 4 track looper on the SSP that had pretty waveforms displayed)
its just a matter of sitting down to do this āconversionā process now.
but I live in Spain, and its pretty warm, so not really conducive to sitting down inside and coding ā¦ so, kind of waiting for it to cool down a bit.
5 Likes
@TheTechnobear.. that all sounds truly excellent! And I appreciate the level of detail in your response.
So if I caught it right, the template would be a type of pipeline to go from RNBO to MM output direct? Presumably there might still be a VCV output retrievable, to facilitate patching in VCV rack on the computer? Please anyhow keep up the great work.. when it cools down! 
Circling back to @tony10000ās original question, such a template/pipeline from Max would certainly be the catalyst someone like me needs to develop (natively) for MM. And perhaps too for others who prefer a patching environment first and foremost, with code integration where needed.
as you can imagine, the āgenericā RNBO code produced knows nothing about the hardware (or software environment e.g. vcv) .
e.g the generic code created might be a filter that has 4 inputs and 2 outputs, and 4 parameters.
BUT it doesnāt know how to connect the IO to vcv/mm etc, or how to draw these to a screen/window. as the code to do this is different for every platform.
for something like the rPI/VST , C74 have a specific āexport targetsā that can create that extra (interfacing) code. (as these are āpopularā targetsā)
for other things, 3rd party devs need to do this interfacing.
you could either do this specifically for your module, or try to do it more generically (a template).
anywaysā¦ once, Ive created my generator/template itāll all become clearer
note:
to create using RNBO you will need a Max (9?) and RNBO license.
however, to use a module (created with rnbo etc), you will not need any licenses.
4 Likes
wow having a template for mm that easily integrates with rnbo would really be quite amazing!
im assuming it would have a preset amount of knobs/buttons and ins and outs and we just define some things in rnbo that would automatically links to those?
for making personal modules(not to share) that handle certain specific tasks easily internally that otherwise would require many modules/extra cpu, i could care less how it looks! how it acts would be the important factor. of course if anybody wanted to share their creation theyād obviously need to learn a thing or two about dealing with interfaces for vcv or mm. which i think would be great to learn at some pointā¦
also i guess this template would still require building the .mmplugin via cmake (or some other way)? or by āgeneratorā are you referring to something you would add onto rnbo (like an external) that would just allow export to mm direct from rnbo?
1 Like
This is pretty exciting! Iāve been meaning to look more into RNBO
3 Likes
theres a couple of ways of doing itā¦
the way I did it on the SSP, and likely same for first go at MM is to dynamically add the controls/IO/text etc.
probably what I can do is have a few blank panels of different sizes that you can choose from (as it appears you cannot resize panel on the MM)
the goal is you wont have to code anything to get it running (other than the rnbo patch)
from there, the more adventurous can start adding custom code to customise the UI more to their liking.
I can hopefully provide some examples of this, as the āfirst stepā, custom layouts is very straightforward, from there the sky (hmm, cpu) is the limit.
build environmentā¦
youāll use the āstandardā setup that you do for MM development, that Dann has already well documented.
also the way the project is laid out (as its my workflow) is you can also build for vcv desktop. so copying over/ running on the MM is kind of the last step. ( * )
but yeah, Itāll be all documented so (with patience/following instructions etc) anyone should be able to do it.
( * ) generally the workflow I use for this is:
a) develop and test rnbo patch, using a Max patch as a ātest containerā
b) create rnbo vcv module, run/test on vcv desktop
c) compile / run on MM
for customise UI (and other things) , I iterate on b ā c
this approach leverages the speed of development in Max, and also the run / debug cycle on the desktop (macOS in my case).
means you only need to copy/fire up MM for final testing, and also for āusability testingā
4 Likes
Great to hear this @TheTechnobear, and the plan to additionally output a VCV module as an intermediate to MM. I saw the recent RNBO 1.4.1 update was still adding/fixing on minimal export to VCV rack.
Out of curiosity I also checked out your GitHub and some Percussa Forum threads on RNBO. It was fantastic to see a non-developer patching in Max/RNBO and outputting SSP modules! 
ā¦ it will be fantastic to see this start happening for MM. Bought you a āko-fiā out of appreciation for all your efforts on this.
As @offthesky says, I wouldnāt be too bothered about UI for anything locally. But if I was particularly proud of something and wished to share, it would be exactly the type of incentive needed to jump into learning/writing code for customizing UI.
1 Like
super exciting! thank you for explaining all thatā¦ and makes total sense about testing out first in vcv. again thank you much for doing this/offering to educate us all here on this. looking fwd to going through it whenever itās all ready 
2 Likes
Agree, this a great idea to lower the bar to MetaModule plugin creation. Thanks @TheTechnobear !
1 Like
thanks for your support
yeah, I found this very satisfying tooā¦
what I think is particularly interesting is, because its relatively low-effort to create a module, you can make it very specific.
e.g. if you fancy just messing with mixing some filters and oscillators to create a wacky drone module, that just has a couple of params/cv io.
then you can do thatā¦
it reminds me of some of the weird and wonder DIY physical instruments we seeā¦
it doesnāt need to be a polished thing that lots of people can/want to use, and can be something particular.
in my mind this the MM really nice, as the limited focus, means smaller UI footprintā¦
I dont know if you played with the C&G organelle and their other instruments- - but I love what C&G for this kind of reasons.
3 Likes
I am really interested in this, being a Max user i recently started looking into the daisy platform but Iām not a coder and donāt have the time to go too deep down that rabbit hole. I actually bought the MM because early on I think Dan had mentioned the eventual inclusion of Max and I am very happy that you are doing work on this.
I really love the idea of more Max users being able to bring their patches to life in eurorack and think this will be the best option.
Iām going to pickup RNBO to start learning the ins and outs of it and would be happy to help test out the system and make tutorials or manuals once the template is done. Iād love to make a clear / non dev speak walk through to lower the barrier of entry.
Please let me know if there is anything youād like me to look at doing on the non dev side.
1 Like