Thanks, @Matos. I’ve been a busy bee. So far this has been proof-of-concept hacking. Now it is on to the hard part: refinement and polishing. But I now have a clear vision of what I am trying to achieve, and whether that vision is realistic, given all the constraints of the Braids MPU and my rudimentary C++ coding skills.
I’m really enjoying this firmware update. Here’s a patch using the hacked Braids as the single sound source and just using the internal LFO as a modulation source. I have the signal multiplied throughout my system for filtering and delays.
(failed on the embed code here)
@BennelongBicyclist: I also don’t mind if you take out the marquee feature.
@weliveincities, excellent! I’ll be doing more work on Bees-in-Trees this weekend. Your track made me wonder - I’m not sure why - whether it would be useful to have a selectable mode in which a trigger on the trigger input not only reset the phase of the internal LFOs, but also alternately stopped and started them?
Hmm…I think phase reset is all that I would really want out of them. I can’t think of a reason where I would want to stop the LFOs if I’m running it via clock, I would just stop my incoming clock signal. I do like generative features though usually in the realm of increasing/decreasing note & gate lengths, modulation depth, and clock shuffle.
OK, I’ve been hacking away at the Braids source code, and my Bees-in-Trees modified firmware is now at version 3q. Many thanks to @Sneak_Thief for his input: both comments on the design of the modifications, as it has evolved, and for testing various versions of it and finding bugs.
The features are now fairly complete - there is only a little room left for any more code - so I am going to pause for a while to consider what else could or should be added. Suggestions welcome. The full list of features, and all the source code, of course, can be found in the GitHub repository for Bees-in-Trees, here - just scroll down to see the README file which describes the modifications I have made to the standard Braids firmware. But here is a little video which demonstrates how it works. Actually it is 30 minutes long. And I swear on a stack of Charlie Hebdos that I didn’t mean to mention sex toys at around the 4 minute mark.
At this stage, Bees-in-Trees is based on the Braids v1.7rc code, and thus includes the two additional triple oscillator models, and the three percussion models from Peaks which Olivier recently added to Braids. However, it does not yet include the fixes to the “sync buffer” problem which exists in Braids v1.7rc firmware, for which Olivier has developed a fix. As soon as the source code for that fix is released, I will port the changes to Bees-in-Trees. Olivier has also indicated that he intends to add some additional settings checking code to Braids, so that alternative firmware such as Bees-in-Trees doesn’t cause your Braids module to behave strangely if you re-install the official firmware - or vice-versa. I’ll also add the same setting checking code to Bees-in-Trees. At that point, it will be safe to provide audio firmware update files (in WAV format) so you can easily, and safely, try out Bees-in-Trees. In the meantime, those who are able to compile a firmware image from source code and upload it via the Braids serial FTDI interface or the miniJTAG/SWD programming interface, should feel free to do so (if you can do that, then you can readily re-flash your Braids with the factory firmware, so I am not worried about such people accidentally bricking their module). Please read the entire README file, especially the bit about encoders, though, before compiling. For everyone else, WAV firmware files should be available in a week or two. But right now, I’m off to the Freycinet peninsula on the east coast of lovely Tasmania, for a week’s holiday - and I’m not taking my modular with me.
One trigger + one Braids with Bees-in-Trees Q… no other inputs. Just modulation madness!
I highly recommend this alternative firmware.
Let me summarize the new features in my own words…
Instead of the single envelope in the original Braids, there are now 2 “modulators” which can be either an envelope or LFO.
- Here are the new menu items:
MOD1: ENV (EG) or LFO
RAT1: overall EG speed or LFO rate
⇑SH1: rising EG/LFO shape
⇓SH1: falling EG/LFO shape
⇑⇓1: Ratio of EG/LFO Attack vs. Decay
M1>T: Timbre mod amount
M1>C: Color mod amount
M1>L: Level mod amount
M1>F: Freq mod amount
M1>2: Modulator 1 to 2 cross-modulation amount
MOD2: Second EG LFO
(same as above for the rest, minus cross-mod)
META -> RATE: CV control over RAT1 & RAT2
META -> RAT1: CV control over RAT1
META -> RAT2: CV control over RAT2
META -> BIT⇓: CV control over bit crushing
RANG -> moves oscillator range into LFO territory (but not too low due to DC-blocking outputs)
QB4v: Quantize before vibrato on/off
RINV: on/off - inverts RAT1/RAT2 response
DRIFT: 0-15 - a variable application of the original drift parameter
Thanks @ Sneak_Thief. That’s a mad demo! Of course, with the modulation amounts turned down, Bees-in-Trees can do subtle as well. But I’m pleased it can also be completely insane.
Note to self: at the moment, if the ⇑⇓1 or the ⇑⇓2 ratio parameter is changed, the LFO speed also changes, because one half of the waveform is shortened, but the other half is not proportionally lengthened. Need to fix that, although it isn’t a showstopper.
These are some really nice additions. I really like having fine tuned ranges to the LFOs while still having CV control over them. Braids is even more of self-contained instrument now. Looking forward to making some nice, slow wavetable drones with both of the LFOs.
Enjoy the vacation!
I’ve been contemplating the feasibility of adding a step sequencer, since there are 52 bytes of persistent setting storage left. Maybe 16 steps of 3 bytes each: one byte for oscillator model, one byte for pitch, and one byte for clock divisor for each step. Step advance would be driven by the trigger input. If the step clock divisor is n, then it advances to the next step only when n triggers have been received. This would allow, inter alia, user-defined sequences of oscillator models, as opposed to the fixed sequence in the current META mode. With settings for loop start and end points within the 16 steps. Don’t get too excited, though - there may not be enough space left for the additional code required to implement all or any of this.
you are doing a great work BennelongBicyclist! thank you so much! when can we have the wav file of the latest version?
I’m heading home from holidays today, I hope to fold in Olivier’s bug fixes and settings check code this weekend, and will then make a WAV file available.
OK, I have finished work on Bees-in-Trees version 3u. This involved porting the fixes Olivier made to the v1.7rc Braids code - these fix the sync buffer problem and the DAC timing issue (for details of these problems, see here) - thus Bees-in-Trees is now in sync with the latest released Braids code. All the fixes seem to have worked, as far as I can determine. I have also ported the settings checking code which Olivier added - now swapping between firmware flavours and versions via the audio bootloader should be completely failsafe. I’ve also added a few new features, including negative envelopes, settable modulator and oscillator sync, and modulator 1 modulating the modulation depth of modulator 2 - so it can now do delayed or fading-in vibrato. Also VCO jitter (aka VCO drift) can now be cranked up to utter sonic destruction levels, and it is controllable via an external voltage (but bit crush no longer is), and VCO jitter is now a modulation destination for the internal modulators. See the README file (scroll down to see it) for full details. Unfortunately, I don’t think there is enough space to add the model sequencer I mooted above, unless I can squeeze the code down a bit more - the binary is currently just 600-odd bytes under the size limit. But I’d like to have the existing version tested by more people first. I have tested swapping between Bees-in-Trees v3u and the latest version of Braids v1.7 firmware (available here), via the audio bootloader only, and it seems to work perfectly - each firmware version boots up with sane settings and valid menu structures. Thus, I think it is ready for testing by others. Initially, I would prefer it if Braids users who are able to flash firmware via the FTDI or JTAG/SWD interfaces tested the audio WAV update file, via the audio bootloader update procedure described in the Braids manual. Why only such Braids users initially? Because if something does go wrong, they are able to recover their Braids by themselves. I think it is now very unlikely that you would be unable to recover your Braids via the audio updater to the latest official version of Braids v1.7, but I’d still like others to check that swapping back-and-forth between Bee-in-Trees and the official Braids firmware (latest version of v1.7) can be done successfully when only using the audio WAV file update procedure, which is all that most Braids owners have access to.
So, if you are able to flash your Braids via its FTDI or JTAG/SWD interfaces, and you are willing to test Bees-in-Trees v3u, please send me a PM on this forum, and I will send you a link to a compiled binary for it in WAV format. Or you can clone or download the code from the repo on GitHub - just use the HEAD of the master branch - and compile it yourself into a WAV file. But please test it using the audio firmware update procedure. And then test reverting back to the latest Braids v1.7 firmware also via the audio update procedure. Please let me know if it works (or not). Feedback on Bees-in-Trees v3u itself is also most welcome, of course, but I am particularly interested in establishing with high confidence that Bees-in-Trees will not brick anyone’s Braids, even if they only have access to the audio WAV file update procedure. Once a few people have confirmed that, then I will make the compiled firmware in WAV and hex formats available to all and sundry.
There’s one caveat: updating your Braids firmware to Bee-in-Trees will lose the calibration data, so you will need to be able to re-calibrate your Braids using the procedure described in the manual. Doing so is very straightforward, and takes less than a minute. Likewise, changing back to the official Braids firmware from Bees-in-Trees will also lose the calibration data, and re-calibration will be again be necessary. This is because Bees-in-Trees stores the calibration data in a different position in the persistent settings data structure.
All clear on my end.
I loaded your latest firmware (version T), then proceeded to downgrade via WAV to the latest official release candidate that I compiled from the source. No issues.
Please remind potential users to go to the final menu item and hold down the encoder to reset all settings.
Bees-in-trees has really grown on me! I can’t imagine using Braids without all these new parameters.
@Sneak_Thief: OK, many thanks. The manual reset of parameters should be unnecessary, though. As well as doing range checking on all stored parameters, both the latest Braids v1.7 firmware and B-in-T v3t or later check a “magic byte” in the settings data. That byte is “M” for official MI firmware, and “B” for Bees-in-Trees. If the magic byte in the stored settings doesn’t match what is expected, it should trigger an automatic settings reset on boot up. That’s what I have observed - that is, it seems to work as intended.
Re. Reset: I was speaking of those going back to the official firmware. I had to do a reset once when I couldn’t hear anything right after reverting to v1.7 Release Candidate.
The latest firmware update file I have posted detects if Bees in Trees has been installed, and reverts to factory settings if so (to avoid garbled settings).
Yes, I just tested reversion to the very latest Braids v1.7 firmware from Bees-in-Trees, via the audio bootloader, and it worked perfectly - an automatic settings reset occurred as expected, so that Braids v1.7 came up with factory default settings. No manual reset needed.
However, I’d be really grateful if someone else could confirm that behaviour. I don’t understand why Sneak_Thief required a manual reset after reverting to Braids v1.7 firmware, unless he installed an earlier release of version 1.7 which didn’t contain the settings checking code.
I’ve just pushed Bees-in-Trees version 3v to my GitHub repository. Version 3v adds voltage control over gain (level) via the FM CV input, thus providing Braids with a virtual VCA capability like that provided by the Level input on Tides. That’s the last feature I want to add - there is only 1k of space left for code, and the complexity of the parameters is probably already too high - here is a diagram of the modulation routing as it stands:
As soon as successful reversion to official Braids firmware via the audio bootloader has been confirmed by one or two other person, I’ll make a compiled binary in WAV format available to all god’s children. In the meantime, I’m happy to make compiled binaries available on request.