Mutable Clouds code?

Any plans for incorporating something like Clouds from Mutable Instruments? I saw that the Er-301 has that code in it and since it’s open source I thought maybe it would be cool to have it in the SSP as well? I realize just because ER-301 has it doesn’t mean SSP needs to, apples and oranges, just a thought since it’s an open source code and the SSP is so powerful.

1 Like

The SSP already has a granular module which might cover that ground. However, I remember @2disbetter and other community members (?) were interested in compiling the clouds code for the SSP (there is a VST example module here in the forum which can be a starting poing for any porting / developing / incorporating / compiling of code from other projects).

Specifically I wanted to port the Rings firmware to a VST plug-in for the SSP.

Unfortunately, the VM I was using for development suffered a power outage in the middle of an apt upgrade function, and messed it all up. I thought I had back ups of the source code I was working on, and nuked the vm to rebuild it. Turned out I nuked the source as well.

So I’m having to start things over. I’ll get there eventually.


I might look at doing Clouds , Ive already ported to axoloti and pure data, so know the code well :wink:

that said, as ive just got the SSP, I want to look at how much overlap there is with the existing GRA module.
this was why I did Rings first, as I noticed the SSP did not having any modules yet for physical modelled strings.


This is incorrect. A user made their interpretation of a Clouds-like processor using the internal stock building blocks.

1 Like

Thanks for pointing this out Neil as it is an important distinction.

Results can and do vary as a result of the implementation.

does the er301 allow loading of native code? (c++)
i know its based around lua, but perhaps that could still use a shared library (.so)

lua is ok, and could be an interesting option to create a SSP VST that allows lua code to be loaded - this would reduce the ‘barrier to entry’ for creating modules for the SSP.
would not be particularly hard to do.

Clds VST for SSP, is using the mutable code :slight_smile:

Its not 100% identical , since SSP runs at 48k, and MI Clouds at 32k, and Im not downsampling/upsampling just for ‘authenticity’ and costing cpu - especially, since I think it actually sounds better at 48 kHz.

I was playing today with a few of the alternative modes (e.g. looping delay) , and really brings alive some of the other SSP modules, really sounds beautiful to my ears.


got lost playing this quick patch for about an hour or so :heart:

1 Like

No, and there is significant work needed to get it to be able to. (However, it is planned still)

Custom modules on the ER-301 are really more like building your own custom models with legos instead of following the instructions. It is not like owning the lego factory and making custom blocks.

1 Like

Brian has said he’d release a C++ SDK someday, but his roadmap is many years long and he keeps his priorities private.

He has also said that he is likely to open source the module someday after it is finished. I suspect “finished” likely means sometime after 1.0, which could be quite a while from now.

You can think of the Lua API as a way to do the things you can do with the GUI, but in code, which of course allows for some additional flexibility.

1 Like

Yeah providing a c++ sdk is not a task to undertake lightly, it’s very easy to paint yourself into a corner - especially before your core infrastructure has matured/stabilized.

Also frankly, there aren’t that many C++ developers that will actually use it ( same with open sourcing) , even with hundreds of users, you’ll be lucky to pick up a handful of (productive) developers.

it really surprised me when I started open source dev, how few developers get involved in projects - check out commit histories , you’ll see very few devs with more that a couple of commits.

Higher level languages lower the barrier of entry, so really help, so whilst I don’t really like lua - I think it’s a smart move for the er301.

That’s said, my quick peruse of the er301 extensions, shows most were still from quite a small number of people :slight_smile:

1 Like

I really don’t want to derail this thread, but I too share your observations with regard to the open source community. I have a simple explanation for it.

As altruistic as I’d like to be, the realities of life are that I need money for food, housing, transportation, and healthcare. Statistically speaking most open source projects generate very life money, and while this shouldn’t be important for what it is open source (FOSS) is trying to accomplish, this need just can’t be divorced from the realities of daily life. I summarize my feelings on the matter here:

I support open source so long as it is not pushing closed source as evil or morally wrong.

Back on topic:

The 301 will get what is planned. I have every confidence in O|D.

My experience is it is rare to find an artistic individual with the chops also necessary to engineer things. So kudos to you again good sir.

1 Like