Superseded: Bees-in-the-Trees 3.z: the post-antepenultimate v3 release candidate


Um, some slightly premature publicity. (it wasn’t me who tipped them off!)


So, are you still taking on testers for the new firmware? I would love to play around with it.


love the word ‘antepenultimate’ in the thread title.


@mic.w, I’m an unreformed sesquipedalian, I’m afraid.

@r05c03, yes, more testers are welcome. Just send me a PM and I’ll send you links to a WAV file for the penultimate version, which is almost ready for testing, by the weekend.


I would like to give it a “go” as well.
sending the pm now.


One more minor bug to squash, and a bit more flash storage space to reclaim through minor code refactoring, and I’ll send out links to all testers for version 3z, by the start of the weekend (which is earlier here in Oz than for most of you).


@BB, if we’re at rev z, we better ship, we’ve run out of letters!


Exactly! Thus 3z will be the final release candidate for version 3.0, released by the end of Feb 2015. Version 3 is now in absolute feature freeze - only bug fixes after version 3z is ready. New ideas and suggestions still welcome, but they’ll have to be held over to version 4 in a few months. I only wish there were a test harness and the ability to write unit and functional tests etc! But that would involve a robot capable of plugging in cables, twiddling knobs and encoders, and critically listening to the output. But a team of volunteer testers - now up to 11 of them, including yourself - trying to break it over a two week period will do just as well.


I should get a bit more time with it this weekend for you, barely touched any of my gear since starting my new job. Still at the picking up the mess of a million freelancers point.

Although, since the random+meta+sweeping-the-encoder-too-fast bug was fixed I’ve still yet to have one hiccup apart from forgetting how to make it go back to working like a stock braids after it’s screamed at me for a couple of hours.


> apart from forgetting how to make it go back to working like a stock braids after it’s screamed at me for a couple of hours

Yes, it occurred to me too that a function that reset all the settings to the defaults except the calibration data would be useful, so you can get back to vanilla Braids behaviour in a single long-click… did I say “no more features”? Hmmm.


I vote yea


I also have to say it would be quite handy to have a Reset Feature to set the settings back to normal… After some hours of experimentation it can take some time to have all the LFO’s and modulations set back to standard.
I say thank you again, your firmware saved me from buying a seperate LFO Module for my portable case :smiley: big hugs


I have implemented a RST (reset) menu item, just before the version string in the menu list, with four settings: NO, DFLT (defaults), NO, and FULL. If RST=NO, then a long-click when on RST when in menu mode does nothing. If RST=DFLT, a long-click on RST in menu mode resets all the settings back to the defaults (essentially vanilla Braids behaviour, with no internal modulation etc), except for the calibration data, which is preserved. If RST=FULL, a long-click on RST in menu mode resets all the settings back to the defaults, including the calibration data. Thus, performing a settings reset is a three stage process: first navigate to the RST menu item, then short-click on it and choose DFLT or FULL, which arms the reset function, and then short-click again to return to the RST menu item, and finally long-click on RST to cause the reset to actually occur. This should make it much quicker to get back to vanilla Braids operation without losing calibration data, while still preventing accidental resets.

One other change: the menu mode is now like an Ouroboros - instead of being a linear list starting with WAVE and ending with the version string, the menu items are now in a loop, so that if you are at the version string (the end), one more forward increment on the encoder will loop you back to WAVE (the beginning). Not sure if that will be too confusing, but it should make it quicker to navigate through the now rather large number of menu items. When in oscillator model selection mode, a short-click still takes you back to WAVE, and a long-click takes you to the position you were at in the menu loop when you last used the long-click short-cut to oscillator selection mode.

I still need to update the documentation to reflect these changes, and to do a bit more testing of them, but I hope to provide links to testers for an updated WAV file for version 3z some time tomorrow (Saturday).

Those really are the final changes for the version 3 series, except for bug fixes, if required!

@RyuX: not sure about the hugs…


Super exciting!
Thank you for all the work BB!


“I have implemented a RST (reset) menu item” The Gods of RSI must detest that feature :slight_smile:

Thanks again for all the work, I’ve had a good few hours with the latest wav tonight and it’s stunning. These last few tweaks will make it damn near perfect. Short of an actual keyboard you’ve transformed Braids into a force to be reckoned with. Almost dare I say it like the workstation of the modular world.

For version 4 I’d like it if you put one Braids in the end of the rack, come back an hour later and it’s cloned itself to fill all the remaining HP left. That would be a feature and a half!


Bees-in-the-Trees is really just tinkering around the edges of Braids, but with enough tinkering, surprising things can happen.

As for Braids cloning itself, that would be a challenge, but I am intrigued by comments made by Olivier, somewhere or other, that an STM32F4 chip, as used in Clouds, Elements and Streams, could run at least two instances of a naïve port of the existing integer maths Braids code, and that four or more instances might be possible if the oscillator code were converted to floating point in order to take advantage of the Cortex M4 FPU. A collaborative effort to create such a HyperBraids would be an interesting and fun project. My rudimentary knowledge of electronics and electrical engineering is insufficient to design the hardware required for such a beast, but I could contribute to the overall design and to re-writing the firmware code. One way to really understand how some body of code works - such as Olivier’s code for the various oscillator models in Braids - is to try to re-write it. If anyone is interested in collaborating on such a project - purely on an open-source, non-commercial and relaxed-timeframe basis - please drop me a line. Maybe it could be called Plaît?


I just watched the demo video and this looks amazing! Especially the modulators. I’m PMing you about the WAV file.


All I can say is that I will be watching this space for any hyper-braids development!


I have sent links to firmware update files for Bees-in-the-Trees version 3.z to everyone who has expressed interest in testing it, to date. More testers are welcome - just PM me on this forum. The plan is to allow thorough testing of it this weekend and next (and all next week), with a view to making compiled firmware WAV files for version 3.z publicly available on or soon after 23rd February 2015 - provided there are no outstanding bugs or issues at that point. No more features will be added to the version 3 series, only bug fixes henceforth. However, further suggestions are still welcome - just post them in this thread, or send them to me by PM, and I’ll add them to the Mutated Mutables wiki for possible future implementation (if the ideas or suggestions are feasible - remember, there are severe constraints on what can actually be done).

I’ve pushed the latest source code for version 3.z to GitHub, so if you can compile your own firmware image, you are most welcome to grab it from the HEAD of the master branch.


There are several sections of code in Bees-in-the-Trees relating to modulator1 and modulator2 which are essentially identical - one is just a cut-and-paste of the other, with the names of variable changed. That’s bad programming practice, and it was bothering me, so I spent an hour last night refactoring it in a branch: putting everything in a loop, stuffing all the variables in arrays, etc. The results was about 150 lines less code in Oh great, I thought, let’s see how much smaller the compiled and linked binary image is! Oh, wait, it was larger. So, with embedded programming, less source code and good programming practices don’t always mean smaller executables. I have set that branch aside, thus no change to version 3.z.