Worth a try, yes: it’s so weird that I’m beginning to suspect a bug in the compiler itself. But I’m using the recommended precompiled packages for OSX of the gcc-arm-embedded project (gcc v4.8.3), which is what you are using Olivier I think. If you want to give it a try, the git tag to check out is “clouds-v1.0”.
any progress happening with this alt firmware?
@risome, there will be a new version in a few days now (sometime next week), you can check out the MW thread for some details.
All right, I just released version 1.2. It features the new Resonestor mode, some improvements on the delay modes, and a few bug fixes. It’s been tested successfully by a few people. Find the complete list of changes, the full documentation and the download link as usual on this page.
I also made some (painful to watch) demos of the some of the new features. Yes, I have a strong accent smile I hope this first attempt will help nonetheless (because I renounced to a lot of pride making these public :D).
Please note that this release comes with a strong warning: as you probably know already, 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!
For the kind beta-testers: Version 1.2 is the exact same as 1.2beta1, so no need to update. I had great feedback that will be integrated later on.
Hope you enjoy it, and don’t hesitate to send me suggestions, comments, criticisms of any kind (or donate if you want to support my work).
Hmm… with my success rate in bricking stuff I guess It’s better if I wait…
@rumpelfilter, I’m totallly with you on this. I have a bricked Clouds (due to my stupidity I have to repeat) which I haven’t even tried to revive for months now
I’ve just tried to update my Clouds using the 1.2 version. I followed all instructions exactly. After the .wav finishes and the module restarts, holding the blend button to select the different modes and pressing through the 4 options with the red LED lit it never reaches a 5th option where the 1st LED is unlit and 2-4 are red… it just keeps cycling through the 1-4 … I have repeated the process and calibrated after each time. But for some reason it doesn’t appear to have changed anything? Could you suggest an obvious mistake on my part? Thanks.
If the led is red, you are just changing audio quality. Press the button longer, until the led is orange. Then you can swap modes.
Just to relay the information from Muffs, I just uploaded a new version, v1.3. This release is just a bunch of fixes and small improvements, no new mode or anything:
- it improves the sound of the Oliverb quite a bit: smoother, louder, no more infamous “swooping” or clicking artifacts when modulating size, less distortion in self-oscillation.
- it also tweaks the looping delay mode: much faster delay time changes, easier access to small delay times.
- … and more.
The full changelog and the download link can be found here as usual.
Also, importantly: if you received your Clouds this month, older versions of Parasite (<v1.3) might not work properly. So just use this one!
I guess there is no news on the mysterious bricking issue, or is there one?
I don’t know how many people have tried installing it, but I haven’t got any return for bricked Clouds over the past 8 weeks.
Yeah, I wouldn’t stake much on it, but it seems to be gone. What makes me say that is that I had none of the weird behaviors when developing like I had when bricking was happening, around v1.0. I’d bet now that it was a bug in the compiler (the software that translate the hand-written source code into machine code for the module to execute); I didn’t change compiler but somehow escaped the very rare corner case I was into at the time. At least that’s my explanation.
Latest Parasite firmware - I get the occasionally beep when changing Blend parameters quickly.
@AXXON I notice it occasionally too. It sounds to me like the CPU can’t keep up with the current computation. When I understand interrupts on the STM better I’ll see what I can do, but it’s gonna be a difficult one I think. Did it happen at all in the default firmware?
pichenettesmqtthiqs ok, I guess I’ll try now! thanks for the feedback!
@rumpelfilter cool, tell me what you think!
I didn’t spend a long time (have spent longer with Parasites) but I think it might have happened in the original software, it’s rare, but super annoying if you’re recording because it’s really out of place and noticeable
Additionally my setting are not being saved on shutdown and re-power. Blend/Dry_Wet fully off powers back on Fully On 100% wet.