Ideas for a MI module expander

There were some discussions about a Peaks CV expander. Olivier, are there any plans for it or are you not interested in making it? I would be super exited about CV controllable envelopes, LFOs, drums <3

I thought a bit more about it. The expander could be universal for current and upcoming modules and could have 4 CV inputs. It could be connected via the FTDI dongle connection (Would the mini JTAG connector also be a possibility?).

Peaks:
CV Control of the 4 parameters.

Streams:
CV Control of the 2x Shape + 2x Mod parameters

Clouds:
CV Control of all Blend modes at the same time

Elements:
CV Control of Contour, Bow, Blow, Strike

Edges:
CV Control of 4x Level

Braids:
Level, Meta, Rate?, Bits?, bla…

Frames:
Direct CV control of the VCAs/Levels (not sure how useful this would be)?
Or some kind of CV record?

— – - - – —— – - - – —— – - - – —

I would definitely pay 70-80€ for such a module.

Yes, back in this thread, Olivier commented:

You know, there’s this thing I sometimes think about: a 4-HP expansion panel with under the hood the scaling circuit going into the ADCs of an atmega, that could talk to Braids, Frames, Peaks and Tides, without hardware modification, just through the serial port available on each of them.

and then added:

Braids:

  • Model selection (equivalent to META mode without sacrificing the FM input).
  • Trigger switching to the next model.
  • Bit-depth.
  • Sample rate.

Peaks:

  • CV control of the 4 parameters.

Frames:

  • CV control of the 4 wave parameters in quadrature LFO mode._

However, he indicated that cost of a manufactured expansion module like this would be well north of 100 euros, and that he wasn’t interested in putting out any more designs intended for DIY.

Recently, I’ve been hacking the Braids firmware, and have added the the first and third of Olivier’s suggestions above, as well as voltage control of envelope parameters. However, the limitation is that there is only one “spare” voltage input on Braids, and that’s the FM input, so I have had to re-use that - I’ve made its purpose selectable between FM, META, internal envelope/LFO time/frequency parameters and bit-crushing level. Having four more CV inputs so that all those (and other parameters) could be voltage-controlled simultaneously would be awesome.

(Note: Edges’ output level are not controllable - these are digital, as in “logic”, not as in “samples piped to a DAC”)

I thought a bit more about this, and let’s see… For each module, I’ll have to check that the controlled parameters can withstand fast and discontinuous modulations (if not rework the code to slew-limit/interpolate/filter accordingly), and then find out whether the code change and the extra CPU load of interfacing with the expander doesn’t break anything. With projects like Braids and Yarns which are almost full, it’s going to be a challenge to make some space. Then the pain of requiring every user of the module to do the firmware updates, possibly dealing with module fried due to an incorrectly patched cable (the JTAG connector is used only by the factory staff, so it’s not protected against reverse connections).

This thing will be a massive PITA, probably more complex in terms of development time than 1.5 or 2 full-blown modules, yet people expect to pay less than 100€ for it.

And what kind of problems does it solve? Modulate the “leftover” parameters.

Let’s step back for a moment and ask the right questions… What do you want to do that cannot be done with the existing line of modules; and what kind of module would allow you to do it elegantly (rather than shoehorning it into existing modules which haven’t been designed for this)?

eg:

“I want to create very expressive drums”

“I want to record CV”

Yes, on a moment’s reflection, Olivier is of course correct. Having hacked the Braids code, it isn’t too difficult to add a new feature. What is really difficult is making sure that changes haven’t broken anything else. Not just logically broken things, but whether changes overload the processor. Writing reliable code that must wok 100% in real-time, on a relatively slow embedded processor, is much harder than writing code that runs in its own sweet time on some desktop or server with gigabytes of memory, terabytes of storage and gigahertz of speed. In particular, the Braids processor is using about 99% of its horsepower in several of the oscillator modes, and even small changes can push it over the edge into buffer under-runs, which sound like chalk being scraped on a blackboard. Due to the high dimensionality of the available parameters that end users can set or change with a pot or CV, the number of permutations to be tested is enormous. Thus testing for such problems is time consuming, tedious and, alas, very difficult or impossible to automate, so there may always be horrible edge cases lurking that someone will eventually find (and complain about). And it is agonisingly difficult to decide what code to remove from Braids to make room for any new feature.

So yes, I now have a great deal more empathy with Olivier’s take on this than I did previously. More CV inputs for Braids would be great, awesome even, but Olivier is right - they belong on… HyperBraids.

HyperBraids might have four each of V/oct and gate/trigger inputs, plus eight other CV inputs for FM, Timbre, Colour, and five other assignable parameters, such as internal envelope times, internal LFO speeds, bit-crush depth, level for each voice (i.e built-in VCA as in Tides/Sheep) etc. And four outputs, of course. Powered by an STM32F4 series MPU, running four instances of the Braids MacroOscillator class, thus four separate voices. The oscillator models would probably have to be re-written to use floating point and some of the hardware DSP instructions available in the STM32F5 (Cortex M4) chip in order to run four at once. Maybe a six or eight character display instead of just four, given that the module would be considerably larger physically. But otherwise very similar to Braids, perhaps with larger wavetables, and more room for additional code (great for hackers to add more features…). Of course, each instance of the MacroOscillator class (i.e. each voice) could run the same or different oscillator models - so it could act as a four-voice polyphonic Braids, or effectively four separate Braids, or anything in-between. It would go very well with one or more Yarns as the controller(s). I dare say the price might be double that of Braids, but you’d be getting effectively four Braids for the money, so the cost-per-Braids-voice might be half what it is now (I’m guessing…).

Braids is so 2011/2012… If I were to make a Eurorack oscillator today I would do something totally different.

I’ve said this before, and I’m happy to repeat my opinion here; the only module in the list above for which a CV expander would really make sense is to add low-rate CV control to the 4 parameters on Peaks. I’d pay €100 for just that.

Yes, OK, Braids has become a post-modern classic, and thus tribute modules are now overdue.

> Braids is so 2011/2012… If I were to make a Eurorack oscillator today I would do something totally different.

the tides, they are a-changing. :slight_smile:

Tides overlaps with Braids’ analog/waveshaping modes.

Sheep overlaps with Braids’ wavetable modes.

Elements overlaps with Braids’ physical modelling things.

Clouds overlaps with Braids’ mini granular modes.

Yarns overlaps with Braids’ chord modes.

Peaks overlaps with Braids’ drum modes.

xxxx overlaps with Braids’ FM modes.

xxxx overlaps with Braids’ noise generation modes.

xxxx overlaps with Braids’ vocal modes.

… unbraiding braids…

not to forget:
sheep … braids’ wavetable modes.

@pichenettes so what you’re saying is, Braids does everything… :wink:

a|x

Incidentally, did you just drop some heavy hints about upcoming MI modules, there?

a|x

Can’t wait for the MI ‘FM Noise Vocal’ module…

Haha, I hope it’s worse: MI Speak synth modules:
Fricatives
Plosives
Vowels
Dalek

Trains - Sonic derailer module

All good ideas!

a|x

You missed
’Consonants’
though.

Yeah, but you can hack those with Fricatives and Plosives :slight_smile: I’d also buy a dedicated Skronk and Clangor module.

I initially thought a Peaks expander would be cool but then thinking about it further - Oliver manages to fit say 4-8 (Braids doesnt count here being a macro instrument in the first place) different features into every module - all without expanders. If I look at WMD - every module has an expander! So if I dont get the inevitable expander I probably dont have access to all the features of the module - nobody wins. And id say it would become a crutch when designing "oh Ill add it in the expander"
I like Olivers way a lot more.

Will the expander need an expander? (CV attenuverter on each input, CV remapping of inputs, CV slew rate on inputs…)