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


weird that it got larger, but thanks for the effort :slight_smile:
But how is that even possible ?


Sometimes having two entities (say two oscillators) declared as two different variables (Osc osc_1; Osc osc_2;) rather than as two consecutive elements in an array (Osc osc[2]:wink: gives the compiler freedom to put them in non-contiguous places in memory and/or to keep things in register rather than in contiguous locations in RAM - leading to more efficient data logistics between RAM and registers.

Doing two or three things in a loop vs unrolling can also cause slow-downs (loop condition checks + breaking instruction prefetch).


Edit: Olivier has beat me to a reply, and provided a much better one in any case. That’s exactly what I was trying - putting the two instances of the Envelope class in an array.

Here’s my original reply:
Putting variables in an array means you need to index the array rather than just using the variable name directly. That adds overhead, which may account for the larger compiled size, even if the source code is shorter and neater. Also, if optimisations such as unroll-loops are enabled, then loops are converted into repeated code by the compiler anyway. But in this case, unroll-loops is disabled. On a desktop or server, the slightly larger executable doesn’t matter at all, so you would keep the neater, shorter source code. But on an embedded platform like the STM32F1 on the Braids, compiled code size (and speed) is what counts, not source code size or neatness. That said, Olivier’s use of C++ is a boon for hackers - it definitely makes understanding and modifying the code easier. Typically code for embedded platforms is written in C, or worse, assembler, in order to make things as small and efficient as possible. But with modern compilers, it seems you can have some object-oriented cake and eat it as well. I’m a bit ashamed that some of the code I have added to Bees-in-the-Trees really ought to have been implemented as classes and methods - the meta-sequencer, for instance. But I am leaving that as an exercise (for me) in Version 4, in a few months, after I learn a bit more about the intricacies of C++ classes - luckily a colleague at work also happens to lecture in C++ techniques to comp sci students, so I have asked for some lunchtime tutorials. And some instruction in C++ templates.

I must say, hacking at the Braids code to create Bees-in-the-Trees, apart from being fun, has forced me to learn a bit more about C+, and that has had a beneficial effect on the sort of things I do at work, where most of the programming I do for data analysis is in R (or, urghhh, SAS, which is as “legacy” as programming environments come. No, COBOL might be worse.). R is great, but can be a bit slow for certain things. Fortunately, there is a library for R called Rcpp, which lets you embed and/or call C+ code in or from R really easily. In the last month, I’ve started to use Rcpp in some of my code at work, to very good effect. A useful side-effect of Bees-in-the-Trees!


I found a way to save a few hundred bytes more in the compiled and linked binary image for Bees-in-the-Trees, by eliminating redundant characters in the character map. That allowed me to implement one more feature…

From the updated documentation for version 3.z:

There is a new menu item called FS+H, immediately following OCTV. FS+H stands for “frequency (i.e. pitch) sample-and-hold”. It is disabled (OFF) by default, but when enabled (ON), the pitch as set by the V/octave pitch input is sampled whenever a trigger is received on the trigger input, and then that pitch is held until the next trigger input. Note that the “hold” pitch initialises to 440Hz prior to the first trigger being received after enabling FS+H. If FS+H=OFF, then pitch sampling is disabled even if triggers are being received, and thus when you then enable FS+H, Braids will return to the last sampled pitch, at least until a new external trigger signal is received, Note: FS+H only works with external triggers, not internally generated triggers, thus if you enable FS+H, first ensure that TSRC=EXT, not AUTO. Also, although the value of FS+H is stored along with other settings, the sampled frequency is not, and thus does not persist between reboots - it is an ephemeral value.

I have sent updated links via PM to the latest WAV files to all testers who have expressed an interest to date (testers: let me know if you didn’t receive a PM with the new links).


Tested the Firmware alot the past days… working very good… i love it
Here a short video looking for some nasty Darkpsy/Hitech Lead :smiley:


@RyuX: you are certainly torturing it, but glad to see that it holds up to the, err, abuse!


So, I played Bees over the weekend. I did not torture it per se, but explored it well enough to have some impressions. First, wow, it really opens the capability of this Module….almost to the point of it being stand alone. Second, it seriously lacks the immediacy of the stock Braids firmware. This is probably inevitable given the expansion of utility. It would be really helpful I think, especially for dummies like me, to perhaps publish a list of envelop settings, both ratios and rising and falling shapes that come close to approximating the stock Braids envelops. I did not really inherently understand envelop ratio description and it takes a bit of a while, too long, in fact, to dial env settings.


I’ll add a list of Bees-in-the-Trees envelope settings that are equivalent to the original Braids envelopes (PIK, TIK, WOMP etc) to the documentation in the next day or so.

What Bees-in-the-Trees really needs is the ability to store more than one set of settings, and then recall them quickly. I think it might be feasible to add 10 user-definable presets which allow instant recall of all the settings. That would require the user to explicitly save their settings to one of the 10 preset slots. At least one oscillator model will need to be removed to make room for this though. Probably one of the noise models. But that will be in version 4, in a few months. Version 3 (the first version) is not released yet, at least not in compiled WAV form. Still aiming to do that before the end of Feb.


Love the idea of having an option to save user defined settings!
That would certainly streamline/reduce the menu diving time…


Braids saves its settings in 96 byte chunks stored in the last page (1024 bytes) of flash memory on the STM32F1 chip. Each time settings are saved, it writes a new chunk after the end of the last chunk, until the whole settings page is filled up, then it wipes them and starts at the beginning again. That’s why every 10th or 11th time you save the settings on your Braids (by clicking on WAVE to get back to the oscillator model section list), there is a slightly longer pause. Bees-in-the-Trees works in exactly the same way, although the type and positions of the data for each setting in that 96 byte chunk is different to Braids. Olivier did it like this to reduce the “wear” on the flash storage - each location in flash memory can only be erased or over-written a finite number of times, before it wears out. By rotating the locations in which settings are saved, the “wear rate” is reduced by a factor of ten. Don’t worry, apparently the flash in the STM32 chips is rated for 10,000 writes, at the very least, thus with Olivier’s rotation scheme, that means your Braids is good for at least 100,000 settings saves. But even then, the 10,000 figure is probably very conservative, and it is likely that the flash memory in your Braids is good for half a million settings saves, or more.

Anyway, my vague idea for version 4 of Bees-in-the-Trees is to save the same 96 byte chunks of settings data in ten explicit slots in that last page of flash memory. The automatic save when clicking on WAVE would be removed, and an explicit save operation in which you chose which slot to save the current settings into would be needed instead. That would also reduce the number of times settings are saved, thus the “wear” on the flash would be no worse, even if the slot locations are fixed, as long as users didn’t always save to the same slot every time. Even then, it would take a long time to “wear out” the flash storage in your Braids when running Bees-in-the-Trees (or official Braids firmware, for that matter). The only tricky bit I foresee is coping with corrupted settings. If you power off your Braids (or if the power fails) at the exact moment settings are being saved, then it is possible that the result will be a corrupted or incomplete chunk of settings in one slot. Olivier deals with this by checking a checksum to ensure the settings to be loaded at boot-up are correct and free or corruption, if not, Braids looks for the next most recent set of settings that isn’t corrupt and loads that, and if they are all corrupted, then it resets to factory defaults. Version 3 of Bees-in-the-trees does this too. Version 4 would need an equivalent strategy for handling corrupted settings.


Finally installed v3… and… wow. so much fun! Heres an excerpt from todays studio session. With Braids as the solo main voice. With kick & snare by basimilus iteritas and jupiter storm.


I’m currently enjoying v3.9, and making the most of the Turing Machine. Thank you so much BennelongBicyclist!


Alright installed beta 4.0 today, i was wondering if anyone put a document together à la for the bee in the trees menus ? Thanks in advance.


I had a stab at a modulation chart for an earlier version using GraphViz, but the results were not very clear:

So I just manually drew a simplified diagram in Keynote (for v3y, but it is still correct for v4.0, just incomplete). Unfortunately that isn’t very good either:

One problem is that Bees-in-the-Trees is a moving target, which makes it unwise to invest effort into manually laying out such a diagram, which is why I tried GraphViz, which using a declarative format to specific what you want the diagram to show, but not how to lay it out. Which is easy to maintain, but the results are not very useful in this instance. Perhaps a GraphVIz expert could help? The source for it is checked into the public repository for Bees-in-the-Trees.


Thanks, yeah i saw this. Will have to do for now, it’s helpful.

Can we report bugs here? (my fine tune knob doesn’t seem to have any effect at all right now) .

Did do a default reset after posting this and the fine tune knob definitely doesn’t work anymore.


Better to use the other thread on Bees, not this one. I respond to your question there.


cool thanks and keep up the great work