I have released Dead Man’s Catch v0.7-beta for testing by anyone interested and game enough to play with it. As far as I can determine, it works as described in the release notes, and doesn’t seem to crash or lock up the module as sometimes happened with some of the previous releases.
All the usual warnings apply! This is beta code, and although I have tested it carefully (see also discussion of re-installtion of factory Peaks firmware here and here), you install it at your own risk. That said, the risk of you bricking your Peaks by installing it is fairly small, and your Peaks can always be recovered by re-flashing firmware via the FTDI serial or JTAG/SWD interfaces - but both of those procedures require suitable programming adaptors.
Note that Olivier Gillet and Mutable Instruments does not provide support for modified firmware and do not provide an unblocking or recovery service for failed firmware installations involving modified firmware such as Dead Man’s Catch.
Full details, installation details, and downloads of the WAV audio firmware update file, can be found at https://github.com/timchurches/Mutated-Mutables/releases/tag/DMC-v0.7-beta
Reports of successful installations, and feedback are welcome in this thread. More features will be added to Dead Man’s Catch in due course.
@glitched, can you describe how you envisage the mapping of the controls in normal/expert and split modes working for your settable amplitude envelope? I can’t come up with a sensible scheme, unless the amplitude is only settable in normal/expert mode, but not split mode.
Cool! I just may have to give this a try!
“Note that Olivier Gillet and Mutable Instruments does not provide support for modified firmware and do not provide an unblocking or recovery service for failed firmware installations involving modified firmware such as Dead Man’s Catch”…
Who does? Is there anyone who could restore a module back to factory if something goes awry?
Ehm, what do you expect ?
Why should Olivier take responsibilty for someone tampering with firmware code ?
If you brick it by any means not related to his supported firmware, it is up to you to fix it…
Funny how people expect someone to be responsible if their experiments go wrong. Installed Dead Man’s Catch, works great!
Adam> Who does? Is there anyone who could restore a module back to factory if something goes awry?
Re-flashing the firmware from scratch is easy, and it is a well documented process, but requires a readily available $20 FTDI adaptor. Lots of people are or would be able to do it. One person in North American and one person in Europe (as well as me here in Australia) have agreed to offer a service to do just that, for a very modest fee, should anyone brick their Braids while install Bees-in-the-Trees modified firmware (there details are on the Bees-in-the-Trees/Mutated Mutable web page). No-one has requested those services to date. I’m sure they would be happy to offer the same service for Peaks. However, at this stage, if you don’t feel confident about refreshing your module yourself, then it might be better not to install Dead Man’s Catch. Wait a few months.
@Bennelong Fabulous - I’m going to install this tonight and have a play - been looking forward to seeing what you’d come up with for this module!
v0.2 just unlocks the bouncing ball that Olivier put in the code from the outset. v0.3 will introduce a brand new capability, though, but no timetable for it at this stage.
Fabulous! I never had the time to get to start working on that (already coding too much at work), but did some notes… maybe they are inspirational enough such that someone … uhrm … likes them enough to implement them
Anyway, here are the notes on my to do list, just curious about feedback/ a discussion:
1) @Bennelong how are you planning on making the other modes accessible? I thought about using the fun and split buttons to navigate linearly through the banks of functions (indicated by X times led blinking). Simply using fun to go forward and cycle through the functions + banks and the combo fun + split to go backwards.
2) use soft-takeover for the parameters when switching from one function/split back and forth.
3) Instead of an attenuator for the tap lfo, attenuverting may be a tad more useful
4) @Bennelong what have you planned as additional functions? On my list, apart from the boundinc ball is/was Euclid, an additional chaos source Brownian motion/Lorenz/… , something that creates
deterministic melodies, in the vein of the Future Retro Zillion Sequencer (haven’t checked on Peak’s DAC yet - but there was some discussion about it, if i remember?).
I was planning to leave the four basic functions and the means of accessing them, and the way they are indicated, untouched, so that the panel labelling and the official user manual remain valid. Likewise the four alternative functions. And then just add extra functions as fifth, sixth, seventh etc alternative modes, indicated by various patterns of two or more of the 4 function indicator LEDs being lit (blinking because you will be in alternative mode). I also thought of using binary numbers from 1 to 15, but that might be too nerdy, but is easy to try - but again, only for alternative mode.
The other thing I thought of was special-purposing the Easter egg handshake, so that the triple-long-press-on-both-buttons drops you into an extended, persistent parameter set for the current function - so adding 4 more parameters for each function, which persist. The problem is how to indicate that the extended parameter setting mode is active. Maybe by inverting the blink pattern?
I have ported the Turing Machine code which I added to Bees-in-the-Trees to Dead Man’s Catch, as the sixth alternative mode, and it works rather nicely, spitting out CVs. Those CVs aren’t quantised, and are probably subject to some thermal drift, and thus it really needs to be used in conjunction with a quantiser, or with a quantising oscillator, like Braids running standard or Bees-in-the-Trees firmware, if you want to use the CVs to play a semi-random melody. Of course, the Turing Machine feedback shift register paradigm is very simple, and only one of many ways of generating interesting melodies, but it is a good place to start, and there’s plenty of flash storage space and CPU cycles available in Peaks to allow further elaboration and experimentation. However, the very limited user interface on Peaks will limit what can be done. Implement a Triadex Muse (or FutureRetro Zillion) on Peaks might be a challenge (but the Triadex Muse is ideally suited for implementation on some other open-source eurorack platforms).
Other ideas for Peaks I have had or which others have had and which I have recorded can be found here - if you use or build on any of the ideas recorded there, please attribute them appropriately. Git pull requests for Dead Man’s Catch are also welcome - I only have limited time to work on this stuff, alas.
Question: Any risk involved in installing alternate firmwares on top of one another? Let’s say I want to go from Dead Man’s Catch to the Peaks drums firmware in the other thread or vice versa…
Is it suggested to fall back to the original Peaks firmware first and update from there or am I OK just swapping back and forth?
There’s a bit of risk of if both alternates are using the exact same changes to make their saves incompatible with the original firmware. Going back via the original probably won’t help directly until all the save pages get overwritten.
@BennelongBicyclist are you both adding zeroed padding? From the other thread it seems “best practice” is now magic number with check on load.
Just an extra 4 bytes in the settings strict at this stage. I’ll add a magic byte in the next version. If the factory code can’t find any good settings, then it re-initialise the entire setting flash page, so should be OK.
I don’t think Steve Crichton has published his drum samples code, so not sure what he is doing.
I’m not doing anything too special… I replace the sample in the numbers station, then put the hit’s sample starts into the array at the top of the file to allow the randomiser know the beat starts. Then change the modulo amount where the randomiser is called to the number of items in the array.
The rest is turning off the ringmod and distortion in numberstation. Removing the flashy sequence on the the LED’s. Then finally I removed the code that detects channel 1. It’s more a case of how much did I comment out. I’ll fire you over a zip so you can A laugh and B try to actually improve it if you wish
I do know someone who bought a peaks today on the hearing the demo today so it is maybe enough of interest to merit further exploration with the window of randomness I want to implement when work calms down again.
@BennelongBicyclist: there seems to be a pretty nasty bug in v0.2: going through all the “normal” functions (env, lfo, tap, drum), whenever I pass “drum”, the module freezes completely (instead of going back to env). I have to reboot to make it functional again.
Hmmm, I’ll check that tomorrow. I’m sure I tested that, but maybe not.
Edit: I’ve spotted where the problem is, and I may not have tested that path through the UI. Shall fix it tomorrow.
@mqtthiqs: I just arrived home and tried to replicate the bug, but I can’t, it seems to work fine on my Peaks. Can you provide a sequence of button presses from power-on to trigger the bug? What firmware was on the module before you installed DMC v0.2? Did you compile it yourself or install from the audio file?