Clouds Parasite: an alternate firmware for Clouds feat. the Oliverb and Resonestor


cool, thanks for the heads up, i hadn’t done it yet!


Hey mqtthiqs,
Saw your presentation tonight at the synth meet in Montreal. I’m really eager for the resonator mode. :slight_smile:


For those of you who didn’t see yet (@skyon?), there’s news in the MW thread : a source of the recent bug has been found.

@pichenettes wrote: “If the serial number (last 3 digits on the sticker on the back SCP YY WW XXX) of your Clouds module is below 020, don’t attempt to upgrade and contact me to have your module upgraded.

@Shabax: was nice to see you there, thanks for the feedback, but it’s not public yet, so hush! :wink:


@mqtthiqs ok, i have 92, so i should be able to get this a try :slight_smile:


thanks mqtthiqs, I love it


hi mqtthiqs, i’ had a lot of fun with the parasite firmware until it bricked my clouds, i was on the looping delay, the number of my clouds is scp 15 16 405, so there is another bug. :frowning:


What do you mean by bricked? Does it still start in firmware update mode?


hi olivier, after clouds bug, the four leds of clouds are blocked on the orange, even if I restart my case.
i tried firmware procedure, but nothing change


So when you boot the module with the encoder pressed, nothing happens? No blinking green button?


yes, since this morning, it’s blocked like this, with encoder pressed or not


Contact me privately and send it back to me.


@Bmhot, very sorry to hear that :frowning: It looks indeed very much like the bug I had myself. Let’s wait for Olivier’s diagnostics, hopefully there will be an easy fix.


It might be a good idea to put a prominent warning on the release pages for both released versions that bricking issues are currently being investigated and that it might be better to wait before installation. It would also be worth noting there the known issue about Clouds with early serial numbers being bricked during firmware installation.You have a duty to your “customers” to keep them informed of any issues, and the GitHub release pages are the ideal place to do that. I would also recommend avoiding linking directly to the WAV files, which bypasses the release page, and maybe go back and edit your direct links to the WAV files on this forum and on MW if there are any there.

I’m not trying to tell you how to run your project, but as a fellow publisher of alternative firmware, I am concerned that alternative firmware doesn’t get a bad name amongst users. Problems happen, that’s unavoidable, but the main thing is to make reasonable efforts to let users and potential users know as soon as possible after the problems come to light.


@BennelongBicyclist thank you for the advices, it is exactly what I’m doing.

> I’m not trying to tell you how to run your project

I understand your concern, nonetheless it does indeed feel a little bit like that since the beginning: your insistance over choosing the name of the project, requesting citing for ideas, intervening systematically about this issue… I’ll be careful regarding the “bad press”, please be careful not to sound patronizing. Thank you!

> You have a duty to your “customers” […]

This is for instance what I’m talking about.


OK, I’m sorry for causing offence or for seeming to lecture or patronise you. I’ll refrain from making any further comments or suggestions regarding your projects.


mqtthiqs &BenelongBicyclist: Guys, please don’t fall out over this. However, Tim’s comments might be read, I’m sure (from what I know of him - we’ve never met, either) he didn’t mean to come across as either lecturing or patronizing. You guys are two of the few who are creating alt.firmwares for these modules and everyone here is incredibly grateful for your amazing work - it would be silly if the two of you were no longer able to offer feedback and advice on each other’s work.

@mqtthiqs - sorry to hear about this latest “bricking”, hopefully Oliver discovers the problem once he has the module, it would be a great shame if folks are in anyway discouraged from trying out your wonderful modifications and additions to the firmware because of this…

Anyway, enough “peacekeeping” - you’re both rockstars in my book.


I’ve received two Clouds bricked after the parasites install.

Both shared the same symptoms: FLASH sectors 0000 and 0001 (addresses from 0x80000000 and 0x80004000, and 0x80004000 to 0x80008000) are completely erased. The former should contain the bootloader, the later the calibration settings.

I’ve tried several cycles of firmware updates with the stock firmware + modifying settings and calibration and could not reproduce this problem. No idea what could go wrong…


Hi guys,

mqtthiqs &BenelongBicyclist : i agree with Rupertlally, you try both, pushing the functions of the modules further, thank you for your work.

@pichenettes : thank you for flashing the module, and sorry for losing time.
I must try to compile and upload by myself, if it happens again.

From what I remember, I was on parasite and I changed mode for the looping delay engine.
Yarns Start/bar trigger output to clouds trig input.
I used streams in Lorenz attractor mode to modulate position and something else.
Hope that help


pichenettes - is it possible there’s something different with mqtthiqs’s toolchain compared to yours?

What about compiling clouds parasites on your end and doing a byte-for-byte comparison of his firmware to one that you compiled?


Worth a try!