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).