Context: this question relates to enhancements to the Braids firmware which I have been working on, full details in that thread, but in a nutshell, the enhancements add: a) Color as a modulation destination for the internal envelope/LFO, in addition to Level (amplitude) and Timbre; b) voltage control over the segment durations of the internal AR envelope; c) an internal LFO mode, with voltage control of LFO speed, and options for several different waveforms; d) settable depth of modulation for the internal envelope/LFO. However, in order to implement these enhancements with an optimal user interface, instead of overloading and abusing existing Braids menu options as I am currently doing, it will be necessary to remove some existing Braids features and/or oscillator models, due to the very limited firmware storage space available on the Cortex M3 processor which Braids uses. I have already removed the Braids Easter egg.
My thoughts were that first the QPSK oscillator model could be removed. I’ve never used it. Does anyone love it or need it? If so, please say so!
After that, the marquee feature could be removed. I am actually quite fond of it, but I don’t really use it very often. What do others think?
What else? It may be possible to squeeze in everything I have in mind with just these one or two feature/oscillator model deletions, but having an ordered list of other bathwaterish things which could be thrown out would be useful. I just want to ensure that no-one’s baby is on that list.
For an alternative firmware isn’t it worth changing all of them? Can always buy another Braids and run both versions.
@6581punk: I do not pretend to have the knowledge, experience in DSP or musical good taste required to come up with a completely new set of Braids oscillator models - writing DSP code for new oscillators is difficult stuff! But what I can do is make useful enhancements to the internal modulation facilities in Braids. By all means buy some more Braids, but what I am working on is intended to be an alternative firmware that tweaks the existing Braids. Thus, Bees-in-Trees is not to Braids as Sheep is to Tides.
What about the CLKN model? Does anyone use or love that? What is it’s use-case, BTW? I’ve never quite understood what it was for.
CLKN can do snares and Zelda swords. Never!
Really, MI needs to make a “rom hacking” synthesizer. Think about it. Yeah, there was that one Eurorack video game synthesizer, but I really haven’t heard anything about that. Some sort of emulator that can FSU to generate sound and trippy imagery.
i think its use is just a different flavour of noise as a sound source or modulation source.
OK, CLKN is a baby, not bathwater. Now I have to find out what a Zelda sword sounds like (sorry, I was born a decade or two too early to know such things).
Does anyone use the signature wave shaper feature in Braids? It is disabled by default. The few times I have turned it on, I couldn’t hear a great deal of difference, but perhaps I wasn’t listening to the right kind of output or listening carefully enough. It does quite a few transformations - maybe I could eliminate just one or two of the more subtle ones? Not sure which. I just need to reduce the size of the compiled code in my Bees-in-Trees modifications to Braids by just a few hundred bytes more… Anyway, if you routinely use the signature feature in your Braids, and thus presumably like it, please say so here.
PS I have explored CLKN some more, and now I really like it. It definitely stays in Bees-in-Trees! So do all the other noise oscillator models.
I listened critically to the effect of the signature wave shaper (SIGN) on various oscillator models in Braids last night, and on some it improved the sound, or made it more interesting, in a subtle way, on others it made them sound worse, and on some I struggled to hear any effect at all. It didn’t knock my socks off, but I am reluctant to remove it from Bees-in-Trees. But I wonder if it could be simplified a bit.
Which leads me to wonder about the VCO jitter/drift feature (DRFT). Again: does anyone use it much? Are there aspects of it you don’t like? It is also quite complex, simulating 50Hz mains hum, temperature drifts using (synthetic) internal and room temperatures, effects of blinking LFO LED causing a periodic voltage sag and so on, all initialised with slightly different values each time your Braids boots. I don’t want to remove it from Bees-in-Trees - especially since I have some additional uses in mind for it - but again, maybe it could be simplified?
Finally, what about the analogue VCO tuning flattening simulator (FLAT)? Does anyone use that at all? Would you miss it? It takes hardly any code to implement it, but it relies on a linear LUT which consumes at least 514 bytes of flash storage - and every byte counts in Braids.
I use the SIGN, DRFT, & FLAT features very selectively and don’t have a critical need for them. I wouldn’t complain if you took them out.
@weliveincities, in the latest Bees-in-Trees GitHub commit, I have removed SIGN and FLAT, but have made DRFT adjustable instead of just off or on - so instead of the DRFT level being either 0 or 1, you can now dial it up to 15. At 15 it sounds terrible, but around 4 or 5, it can sound rather nice on some oscillator models, and at 9 or 10 it adds lots of grungy noise to everything. I’ll make a demo of this soon.
Hey, it’s a good idea actually, to group all those settings into a single adjustable “character” setting (with some serial number seeding). Maybe I’ll do that in the main branch too. I’m currently looking at doing what FLAT does without LUT.
@audiohoarder: I guess you mean the Ming Mecca. It’s been released, and should be available from Analog Haven
@rumpelfilter: Yes, that is the one. I still think they woudl have been better to give the controller module the connector for sega/atari/commodore controllers instead of NES. There are just more options that way.