Clouds Parasite v2.01: an alternative firmware for MI Clouds

mqtthiqs · Post by **mqtthiqs** » Sat Apr 11, 2015 1:50 am

EDIT: Warning 1: Some cases of bricking (updates that leaves Clouds non-functional) have been reported with previous versions of this firmware, very roughly 1% of the time. Their causes is still unknown, but all could be repaired with a FTDI or JTAG adapter and a computer. Mutable Instruments will not support unbricking; I can do my best to help (provide detailed instructions or local help). Be aware of the risk before updating!

EDIT: Warning 2: If your module has a serial number that ends with number < 020, you should contact Mutable Instruments: your Clouds might have a faulty bootloader which could brick the unit if you try to update it.

EDIT: Warning 3: If you purchased your Clouds on or after July 2015, please use Clouds Parasite version > 1.3. Earlier versions might not work properly.

Hello all,

I already published a couple of my hacks on Mutable firmwares. Here is an official announcement for the beginning of a series: the Parasites. A parasite is an organism living in or on another, benefiting unilaterally from its host. Parasites is a series of free alternative firmwares for MI modules. Their purpose is to enhance existing features, add new function and hidden modes, retaining as much as possible factory functionality.

It now has a web page:

http://mqtthiqs.github.io/parasites/

First off is Clouds Parasite: a new and improved alternative firmware for Clouds. It adds the following features:

The (largely improved) OliVerb: a new, full-featured creative reverb mode, inspired by the Erbe Verb, with CV control over all parameters. It is modeless, unrealistic and goes far beyond your traditional reverb;
Resonestor: a polyphonic resonator processor with built-in support for your beloved Karplus-Strong synthesis.
More envelopes for your grains: the Texture knob allows to select ramp down or ramp up-shaped grains. Square-shaped grains have steeper edges for extra glitch;
Enhanced looping delay and time stretcher modes: tempo syncing with clock multiplier/divisor, support for stereo delay (ping-pong delay) and (crude) open feedback loop, much improved sound quality, faster delay time change.
Availability of much smaller grains compared to the official firmware.
Post-processing reverb on the original modes is applied after the dry/wet, so that it affects also the dry signal.
Reverse mode: play back grains in reverse direction

Some demos and tutorials of the added features:

[video][/video]
[video][/video]
[video][/video]

Version v0.9 introduced the Oliverb, and was a net improvement over the unofficial previously published version.
Version v1.0 fixed a few bugs and quirks of v0.9.
Version v1.2 provided the new Resonestor mode, improvements on the delay modes, and more bug fixes.
Version v1.3 fixes sound issues with the reverb, enhances its quality and improves the looping delay mode's reactivity.
Version v1.41 made minor tweaks to a few features (mainly to adapt it to my preferences)
Version v2.0 changes the mode-switching interface, introduces reverse grain/loop playback, improves bit depth and modulation capability of Oliverb and Resonestor, and adjusts many settings.
Version v2.01 fixes the Reverse functionality in granular mode

You can download the .wav file on the website above. Documentation is there too. It is subject to more improvements, so any suggestion, comment or criticism will be very warmly welcome.

... and if you like this work, consider donating through the page!

bennelong.bicyclist · Post by **bennelong.bicyclist** » Sat Apr 11, 2015 2:12 am

This is great, but I am rather sad that you chose the break the naming convention for alternative firmware for Mutable Instruments modules. The convention is that alternative firmware takes the name of, or alludes to, one of the games in Peter Greenaway's film Drowning by Numbers. By ignoring this convention you have missed the chance for your firmware to be immortalised by Wikipedia.

I dare say that a reference to one of Greenaway's other works would also be acceptable. Even "Luper".

I understand that you have chosen the name “parasites” ln deference to Olivier’s work, but with open source software, giants expect to have their shoulders stood upon, and a deferential, or reverential, attitude is probably unnecessary. Can you be convinced to be referential instead - to Greenaway?

Thulo · Post by **Thulo** » Sat Apr 11, 2015 4:56 am

This seems really interesting!
I have a clouds module and im just wondering.. is there any chance that i can fuck up the module by inserting this firmware?
Im not saying that your firmware is/may be corrupted but if there is anything i can do wrong with the transfer process?

I dont want to turn

into

satori · Post by **satori** » Sat Apr 11, 2015 5:18 am

Just installed this firmware and all went smooth. The new mode is great! Just been sending heaps of modulation into it and it's spitting out some wild sounds.
Works nice as a standerd reverb also, shimmer is nice.
Thanks for your work!

mskala · Post by **mskala** » Sat Apr 11, 2015 7:56 am

Thulo wrote:is there any chance that i can fuck up the module by inserting this firmware?
Im not saying that your firmware is/may be corrupted but if there is anything i can do wrong with the transfer process?

In principle a failed firmware installation (really bad firmware, or interrupted at the wrong moment during installation) can brick the module. Then it stops working at all and is unable to accept any new firmware to fix the problem, requiring hardware-level repair to be useful again. This is not a very likely scenario and I'm not sure it has actually happened to anyone with a Mutable module - the modules and the firmware are both designed to minimize the risk - but it is a risk that does exist, and that's one reason that installing third-party firmware will void the warranty.

Think of installing new firmware as being like physical "modding."

Thulo · Post by **Thulo** » Sat Apr 11, 2015 8:10 am

Ok thanks. I ran the update through my ES-3 and all went fine.
Im now wery busy wiggeling the hell out of it

bennelong.bicyclist · Post by **bennelong.bicyclist** » Sat Apr 11, 2015 8:14 am

mskala wrote:
Thulo wrote:is there any chance that i can fuck up the module by inserting this firmware?
Im not saying that your firmware is/may be corrupted but if there is anything i can do wrong with the transfer process?
In principle a failed firmware installation (really bad firmware, or interrupted at the wrong moment during installation) can brick the module. Then it stops working at all and is unable to accept any new firmware to fix the problem, requiring hardware-level repair to be useful again. This is not a very likely scenario and I'm not sure it has actually happened to anyone with a Mutable module - the modules and the firmware are both designed to minimize the risk - but it is a risk that does exist, and that's one reason that installing third-party firmware will void the warranty.

Think of installing new firmware as being like physical "modding."

No, that isn't correct. Firmware updates via the audio interface can't overwrite the audio bootloader, by design, so if a firmware update fails part way through due to a power interruption or similar, then you can just reboot into the audio bootloader again and start over. The only way the audio bootloader could be overwritten is if the firmware you load is deliberately designed to overwrite it, which is rather unlikely. Even then, no physical or hardware repairs would be needed, but firmware would need to be uploaded via the serial FTDI port or the JTAG interface, using a $20 hardware interface. Olivier provides detailed instruction for doing that, should it be necessary.

The only thing that could go wrong is if alternative firmware left persistent settings data which prevented the factory firmware from operating correctly if it is re-installed. That was a theoretical possibility in Braids, but Olivier added some extra code to guard against that in v1.7 of the Braids firmware. I'm not sure if the other modules also have these checks. It is something that anyone who makes modifications to the firmware needs to bear in mind. Careful testing of re-installation of the official firmware after installing the modified firmware needs to be done by whomever is creating it, before it is released.

ben_hex · Post by **ben_hex** » Sat Apr 11, 2015 9:24 am

mqtthiqs great work, I need to do a video for the latest firmware mode from bennelong.bicyclist "bees in the trees" for braids then I'll have to do one for your clouds firmware too. Bees in the trees moved faster than I could keep up due to other work, so I'm hoping for a solid manual for the current version and documentation for your firmware to be able to dip in quickly and get a video online. All of this will be after module overview videos I owe but I keep notes and will be sure to have something in the future to show off your work :-)

mqtthiqs · Post by **mqtthiqs** » Sat Apr 11, 2015 10:33 am

bennelong.bicyclist
Sorry, I wasn't aware of the pattern here (which is Tides and Bees-in-Trees, right?)... There is definitely deference in my naming, and deserved one, but I intended more a reference to the "biological" nature of open source, each project occupying its own ecological niche. I have to say I have a conflicted relationship with Greenaway... I haven't seen Drowning in Numbers in ten years, and remember feeling pretty strongly against it, so I'd feel a bit uneasy to name this work after his... Can't we have our own pun? Plus, seen your job, I thought you would appreciate

Ok ok, you won, I'll give Greenaway another shot soon

mskala,
I fully second bennelong.bicyclist here: nothing bad can happen while transfering the firmware, even interrupted in the middle, as it is "protected" by the bootloader. You probably remember flashing computer BIOSes in the 90s, but this is not the same. As a matter of fact, I used this exact same procedure to develop the firmware (I don't have any other hardware) so I repeated it probably 100 times without one failure. So apart from malicious firmware explicitely stating "erase the bootloader and mess up everything", you should really be fine. And then again as bennelong.bicyclist said, a 20$ USB adapter could always unbrick it.

ben_hex
That would be awesome! I was planning to do one myself, but it promised to be orders of magnitude crappier than anything you could do! Please, can you get in touch with me before shooting it? I'll send you the latest version available.

satori,Thulo
Thanks for trying it out! Any comments?

bennelong.bicyclist · Post by **bennelong.bicyclist** » Sat Apr 11, 2015 3:25 pm

mqtthiqs wrote: mskala,
I fully second bennelong.bicyclist here: nothing bad can happen while transfering the firmware, even interrupted in the middle, as it is "protected" by the bootloader. You probably remember flashing computer BIOSes in the 90s, but this is not the same. As a matter of fact, I used this exact same procedure to develop the firmware (I don't have any other hardware) so I repeated it probably 100 times without one failure. So apart from malicious firmware explicitely stating "erase the bootloader and mess up everything", you should really be fine. And then again as bennelong.bicyclist said, a 20$ USB adapter could always unbrick it.

As long as re-installation of the official firmware has been thoroughly tested. When I first started working on Bees-in-the-Trees, due to changes in the settings data which is stored in flash between boot-ups, I found that it was quite possible to get into a state in which the official firmware could be re-installed but then wouldn't work, and the module needed to be re-flashed from scratch. Olivier then added code to the latest v1.7 official firmware for Braids to prevent this situation, which is why I insist on installation of the latest v1.7 firmware before installation of Bees-in-the-Trees. It is important to check for such re-installation issues with modified firmware for other MI modules - you don't want it to be a one-way trip.

mwvm · Post by **mwvm** » Sat Apr 11, 2015 3:50 pm

bennelong.bicyclist wrote:
mqtthiqs wrote: mskala,
I fully second bennelong.bicyclist here: nothing bad can happen while transfering the firmware, even interrupted in the middle, as it is "protected" by the bootloader. You probably remember flashing computer BIOSes in the 90s, but this is not the same. As a matter of fact, I used this exact same procedure to develop the firmware (I don't have any other hardware) so I repeated it probably 100 times without one failure. So apart from malicious firmware explicitely stating "erase the bootloader and mess up everything", you should really be fine. And then again as bennelong.bicyclist said, a 20$ USB adapter could always unbrick it.
As long as re-installation of the official firmware has been thoroughly tested. When I first started working on Bees-in-the-Trees, due to changes in the settings data which is stored in flash between boot-ups, I found that it was quite possible to get into a state in which the official firmware could be re-installed but then wouldn't work, and the module needed to be re-flashed from scratch. Olivier then added code to the latest v1.7 official firmware for Braids to prevent this situation, which is why I insist on installation of the latest v1.7 firmware before installation of Bees-in-the-Trees. It is important to check for such re-installation issues with modified firmware for other MI modules - you don't want it to be a one-way trip.

On that note. How do I reinstall original firmware?

ignatius · Post by **ignatius** » Sat Apr 11, 2015 4:00 pm

mwvm wrote: On that note. How do I reinstall original firmware?

just download it from mutable site and do same process. it's an audio file you 'play' into the module..

Summa · Post by **Summa** » Sat Apr 11, 2015 4:04 pm

mwvm wrote:
bennelong.bicyclist wrote:
mqtthiqs wrote: mskala,
I fully second bennelong.bicyclist here: nothing bad can happen while transfering the firmware, even interrupted in the middle, as it is "protected" by the bootloader. You probably remember flashing computer BIOSes in the 90s, but this is not the same. As a matter of fact, I used this exact same procedure to develop the firmware (I don't have any other hardware) so I repeated it probably 100 times without one failure. So apart from malicious firmware explicitely stating "erase the bootloader and mess up everything", you should really be fine. And then again as bennelong.bicyclist said, a 20$ USB adapter could always unbrick it.
As long as re-installation of the official firmware has been thoroughly tested. When I first started working on Bees-in-the-Trees, due to changes in the settings data which is stored in flash between boot-ups, I found that it was quite possible to get into a state in which the official firmware could be re-installed but then wouldn't work, and the module needed to be re-flashed from scratch. Olivier then added code to the latest v1.7 official firmware for Braids to prevent this situation, which is why I insist on installation of the latest v1.7 firmware before installation of Bees-in-the-Trees. It is important to check for such re-installation issues with modified firmware for other MI modules - you don't want it to be a one-way trip.
On that note. How do I reinstall original firmware?

MI homepage has all the firmware you need..

mqtthiqs · Post by **mqtthiqs** » Sat Apr 11, 2015 4:15 pm

I already tested going back to the factory firmware, it works without a problem. I'll double check tonight to be sure, and also to see whether settings are kept, but it should be fine since I'm not modifying save/load routines neither the data structures that are saved.

bennelong.bicyclist · Post by **bennelong.bicyclist** » Sat Apr 11, 2015 6:24 pm

mqtthiqs wrote:I already tested going back to the factory firmware, it works without a problem. I'll double check tonight to be sure, and also to see whether settings are kept, but it should be fine since I'm not modifying save/load routines neither the data structures that are saved.

I don't (yet) have a Clouds, but presumably it saves the mode and other state it was last in so it comes up in the same mode on rebooting? And presumably your extra reverb mode is implemented by adding an extra number to an ENUM which identifies the state of the module. If that number is stored, what happens if a user selects the add-on reverb mode, powers down, and then re-installs the official Clouds firmware? The Clouds firmware will read the value from flash, but it will be outside the range of values it expects. What happens? Does it just revert to defaults, or does it crash? Those are the sorts of scenarios that needed to be thought about and tested for. As I said, Olivier added code tot he latest Braids v1.7 firmware to handle such scenarios, but Clouds firmware may not include such code. It might be a good idea for Olivier to routinely add such settings sanity-check code to the official firmware for all his modules, in due course.

mqtthiqs · Post by **mqtthiqs** » Sat Apr 11, 2015 8:35 pm

bennelong.bicyclist, thanks a lot for the heads up! I'll definitely be careful about this. I just checked though, Clouds' original code was already protected from such problems.

I also just downgraded successfully back to the factory firmware (with Reverb mode on before downgrading), so I can confirm it also works empirically.

mwvm, did you find the original firmware on the website? Where? I didn't, so I recompiled it from Olivier's source code. Tell me if you need it, I can put it online somewhere.

bennelong.bicyclist · Sat Apr 11, 2015 10:02 pm

mqtthiqs wrote:bennelong.bicyclist, thanks a lot for the heads up! I'll definitely be careful about this. I just checked though, Clouds' original code was already protected from such problems.

I also just downgraded successfully back to the factory firmware (with Reverb mode on before downgrading), so I can confirm it also works empirically.

Ah, OK, no worries than. I can't be bothered looking right now, but I imagine that Olivier has incorporated such settings checking code into all the newer modules. It does need to be born in mind for the older modules, like Frames and peaks, though.

rupertlally · Post by **rupertlally** » Sun Apr 12, 2015 12:32 am

mqthinqs could you post a .wav file of the original firmware somewhere?, I've checked all over the MI site and forum and can't find it...unless I'm being spectacularly dense (also possible) the only way is to compile it from Oliver's source code...

mqtthiqs · Post by **mqtthiqs** » Sun Apr 12, 2015 12:52 am

Sure, here it is. I looked carefully too and I think they're not there (apart from Tides)...

rupertlally · Post by **rupertlally** » Sun Apr 12, 2015 1:33 am

Thanks, There's a thread on the MI forum, with a link to a depository of the .wav firmwares but it wasn't there either...

Thulo · Post by **Thulo** » Sun Apr 12, 2015 1:52 am

Man i had massive fun with this yesterday together with bees in the trees.
Quite an IDM duo those two modules.

Thanks for makin our lives a little better!

mwvm · Post by **mwvm** » Sun Apr 12, 2015 2:02 am

I tried the reverb. And I'll be honest. I didn't think it was up to much. No real clarity in sound. Or a reverb that resembled a sound I put in it. Very wooly/muddy.

Plus side lots of weird stuff/fx going on. Can get some nice drones happening.

rupertlally · Post by **rupertlally** » Sun Apr 12, 2015 4:38 am

mqtthiqs install worked flawlessly, really enjoying this so far - though I'll admit to a little head scratching at first as to where the mod effects where coming from until I realised I had Blend parameters 3 and 4 fairly full on!

Anyway, I've uploaded a quick demo of Bees-In-Trees (in VFOF mode) going into Clouds Parasite - no pitch-shifting, internal or CV mods going on, just me adjusting the SIZE parameter by hand:

https://soundcloud.com/rupertlally/test ... -parasites

mwvm weird that you find it "muddy", depends or your own tastes, I guess...

Hari Seldon · Post by **Hari Seldon** » Sun Apr 12, 2015 5:44 am

Mostly interested in the clocking abilities. What kind of clocks does it expect? Fast ones (a la echophon) or can I clock it fairly slow?

rupertlally · Post by **rupertlally** » Sun Apr 12, 2015 6:45 am

Hari Seldon just tried it with a slow clock/LFO run through a clock divider and it seems to work pretty well...

MOD WIGGLER

MOD WIGGLER

Clouds Parasite v2.01: an alternative firmware for MI Clouds

Clouds Parasite v2.01: an alternative firmware for MI Clouds