Just a quick update: I have provided links to Bees-in-the-Trees version 3.3 to everyone who has expressed an interest in testing it. Anyone wishing to join the test crew, just send me a private message (PM) on this forum (not at MuffWigglers, please). Everything in v3.3 seems to work as far as I can determine. Here is the change-log with respect to version 3.2:

considerable behind-the-scenes refactoring of code, based on five or six extremely helpful suggestions for improving the Bees-in-the-trees code which Olivier sent me last week. I haven’t implemented all his suggestions yet, but those which I have implemented have significantly reduced the code size and made it more efficient. More refactoring is to come in v3.4.

as a result of the code refactoring, all settings ranges are now standardised to 0 to 127, instead of some being 0 to 250 in steps of 5. Apart from simplifying the code, a lot, it provides greater resolution, albeit at the expense of more knob rotation.

the ⇑⇓1 and ⇑⇓2 settings also now use a range of 0 to 127, with 63 representing a symmetrical LFO waveform or equal duration attack and decay segments of the envelope. In practice, this works much better than the ratios I used previously.

the meta-sequencer now has 8 settable parameters, PAR1 to PAR8, one for each step. These parameters scale whatever they are directed to, and they can be directed to timbre, colour, level (gain) or combinations of those three. Thus, if timbre is set to, say, 100 via the timbre knob (and/or by an internal modulator etc), and PAR1 is set to 63 (out of 127), then the actual timbre parameter value sent to the oscillator for step 1 is approximately half (63/127) of 100, that is, about 50. Thus the meta-sequence step parameter values are fractions of 127, which are multiplied with the instantaneous value of the timbre, colour or level parameter(s) they are directed to - which is why they default to 127 (thus 127/127, that is, a scale factor of 1). A new MSPD setting allows the meta-sequencer parameter destination(s) to be selected.

I re-arranged the menu so that WAV1…WAV8 are all together, NOT1…NOT8 are all together etc. I’m not convinced this is better – opinions welcome.

Roadmap: in v3.4, apart from more behind-the-scenes code improvements, I plan to add a full Music Thing Turing Machine/Richter NoiseRing implementation. At least I hope to add that - I think it is feasible. Implementing the shift register and probabilistic bit flipping in code is almost trivial, but the Turing Machine-like display of advancing bit patterns will be rather more challenging, but I’ll see what I can do. I had hoped to de-couple the notes sequencer from the meta-sequencer, as suggested by Icaro Ferre of Spektro Audio, but I’m running out of flash storage space, as always, and it would add a lot more menu settings. I think that adding a Turing Machine is a better use of the very scarce resources in available in Braids and requires just three or four more menu settings. The intention is to make the probability of bit flipping CV controllable via the FM CV input, as well as by a menu setting. The other Turing parameters (length of the shift register, probably a choice of 8, 16 or 24 bits), and the size of the “DAC” read window will be set via the menu (and thus encoder twiddling).

@shiftr, I think I was musing about how to quantise incoming note CVs to just intonation, hence my slightly complicated algorithm. However, that’s a feature better added to something like Elements or Clouds, with their more powerful CPUs that support floating point arithmetic, so that just scales with arbitrary root notes could be calculated on-the-fly. I came to the conclusion that if you want to play in just intonation with Braids, just buy a Yarns, or use Experts Sleepers Silent way or similar.

Sunday afternoon hack-n-jam: a quick demo of the Turing Machine/Richter NoiseRing mode which I just added to the Bees-in-the-Trees v3.4 alternative firmware for the Mutable Instruments Braids module. The entire track was generated by three Braids modules auto-sequencing themselves, no external sequencer, just a Grids to provide three triggers. The sequences themselves are automatically generated by the embedded Turing Machines - it just plays itself…

I’m have yet to update the documentation, but I will release committed versions of this to testers tomorrow night, and make it available to everyone in compiled form with the week.

Specially thanks to @stevenb (aka Steven Barsky) who discovered a nasty bug in the meta-sequencer which caused a crash - now fixed in v3.4.

It occurs to me that it would be possible to add a Turing Machine to Yarns as well, except with 4 independent shift registers, one for each CV output channel…hmmm, and Peaks, which has 4 knobs, which could be used for tweaking 4 parameters of a Turing Machine.

But first I need to perfect the Turing Machine in Bees-in-the-Trees. To that end, release of v3.4 to testers will be delayed for another day or two while I re-write the code, because I now have some better ideas. It started out as a replica of the Music Thing Turing Machine, but in software, it is very easy to go beyond what was possible in a hardware implementation, without making it too complex.

For example, in the Bees-in-the-Trees implementation, the length of the shift register is continuously variable from 0 to 32 bits, and the number of bits read from the shift register to create the pseudo-note CV (in fact, a note offset in steps on the chosen scale) is variable from 1 to 4 bits (meaning the melody is chosen from between 2 notes (1 bit), 4 notes (2 bits), 8 notes (3 bits) or 16 notes (4 bits)). It also has a setting for the probability of flipping the most significant bit each time the shift register is shifted one bit position to the left, which is basically how the Turing Machine works (it flips the LSB, not the MSB, but the effect is similar). But I’d like to add the ability to flip a random bit every j iterations of the entire pattern, and also to flip a deterministically toggle the LSB every i trigger/clock ticks, or every j cycles of the entire shift register. There is also the ability to re-initialise the shift register with a fresh random word (i.e. a fresh random pattern), every k cycles of the pattern, which allows randomly generated patterns to be “auditioned” and then captured, or for the pattern to just change completely every 1 / k “bars”. Phew, that’s enough! Give me a few days…

@ben_hex, the version 3 series of Bees-in-the-Trees has been subject to weekly updates, but I think v3.5 or v3.6 will be the last updates for several months, while I fry other fish. Thus hold off until I release v3.5 or 3.6 in a few weeks, as the last in the v3 series. Current v3.4 is stable but still a work-in-progress.

I have just sent links to Bees-in-the-Trees v3.5 to everyone who has expressed an interest in testing it. Here are the changes since v3.4:

the Turing Machine implementation now works as it is supposed to! In v3.4, there were various stupid bit-twiddling errors which meant it behaved very strangely in many circumstances. Now it behaves as it should, more or less, mostly. It’s still a bit unpredictable, but in an interesting way, I hope.

the range of notes accessible to the Turing Machine has been increased to 32 (5 bit window)

the scales/modes have been rationalised a little bit

the Turing Machine PROB (probability) is now much less sensitive, so that very small probabilities of bit-flipping can be set

PROB can be put under external CV control via the FM CV input.

both positive and negative note offsets can now be set in the meta-sequencer

it is also now possible to use the FM CV input to control only the decay duration of envelopes, so that a nice sharp attack is preserved no matter how long the decay is set to via the FM CV input.

Anyone else wishing to test it should PM me on this forum.

If there are no bug reports by the end of next weekend (29th March 2015), then I will release compiled versions of v3.5 to the big wide world.

At this stage, I don’t plan on adding any new features to the Version 3 series, and thus version 3.6 will only contain minor tweaks and bug fixes, if it is required at all. There will be a pause of at least a month before version 4 is ready, possibly longer, because I have some other fish to fry (and some new modules to make).

Here is a quick and dirty demo of the much improved Turing Machine in Bees-in-the-Trees v3.5, doing its thing inside three Braids, working in conjunction with the meta-sequencer which is also available simultaneously in Bees-in-the-Trees. Grids provides the three triggers to the Three Braids, but apart from a Serge Resonant EQ filter on one of the Braids, no sequencers or other modules or post-processing is involved. All melodies/sequences generated by the Braids themselves.