Porting Mutable Instruments code

Software Development
1

Total noob here who just received my daisy :slight_smile:

Mutable Instruments is my favorite Eurorack manufacturer and I know that all of Emilie’s code is available open source on her github.

I also know that some of her modules have been ported to pure data.

Is anyone interested in integrating mutable instruments code (for example the various algorithms from braids / plaits or maybe even the sequencer / quantizer from Marbles) to a format that would be compatible with the daisy? I’m assuming it would be okay to parse out separate elements and add them to the DaisySP library but I have no idea how to go about that. It looks like there is one little limiter originally from Mutable Instruments already included in the DaisySP library so it seems like it should be totally doable.

Does anyone have any resources on how I might be able to get started on this?

5 Likes
2

Totally interested here! If you look through the code base, we’ve already started porting some of the stuff from her stmlib library.

It would be very cool to create some daisysp modules based on various mutable instruments modules.

That said, stmlib can be used with the daisy as well. And with a little bit of wrapper code it would be possible to port entire modules as daisy projects.

One thing to note is many of the processors for mutable instruments modules have flash sizes that are a bit larger (up to 1MB I believe). So some of those would either need to have some code run from the from external flash (support for this is coming soon), or be reworked to use less flash memory.

3 Likes
3

What exactly does this mean? Haha sorry! Like I said, total noob here.

4

@shensley MI modules use lots for LUTs, many of those functions can be calculated on the fly due to more powerful CPU.

Based on MI linker scripts, only STM32F4 MCUs with APPLICATION_LARGE flag in makefile use >512 flash. This is the case for Clouds, Elements, Marbles, Rings, Warps. However, I would expect that some of them won’t even use flash fully for program/data. Some sectors are reserved for module state saving (data is appended to reduce amount of page erases).

1 Like
5

@Casual_Decay no problem!

Mutable-Instruments has a C++ template library for STM32 called stmlib that has many generic, reusable components used within the eurorack modules. This includes fft, MIDI, event queues, etc.

This library can be used with the Daisy in addition to the libdaisy/DaisySP libraries.

4 Likes
6

I’ve mostly been using the arduino libraries and exploring the examples through that. Is there any easy way to make the STMlib from mutable compataible with arduino? I keep getting errors when I try.

(Edit - meant to tag @shensley)

7

@Casual_Decay I haven’t tried it personally, but one thing I’ve noticed with arduino is it tries to compile all of the files in your folder even if they’re not all being included. So you may try just pulling in specific files you’d like to use in your program.

A lot of the DSP in the mutable instruments Eurorack repos should play well with the DaisySP stuff, but its probably best to bring pieces in one at a time to see what Arduino complains about.

Feel free to post any specific errors so we can give a bit more directed advice.

1 Like
8

I haven’t been able to get any of the mutable code, even the STM library to work with Arduino so far. I just get errors every time :confused:

10

Did anyone check the VCV Rack implementations?

I think it would be a good place to start, as there is an actual implementation to look at.

I know it’s not the same as Daisy, but there is still some knowledge to gain there, I am pretty sure :slight_smile:

11

Daisy is much more similar to MI hardware than an OS and GUI running on an x86 CPU.

1 Like
12

Yeah, that’s what I was thinking too. Porting straight from mutable seems easier than doing it from somewhere else. Unfortunately that’s not something I’m capable of doing yet with my skill set ¯_(ツ)_/¯

13

I guess it depends on who you are. I checked the code for VCV and it made sense to me. The original code didn’t make a lot of sense.

1 Like
14

Hmm interesting. Worth taking a look at then. I haven’t yet

15

I wont be able to do the port atm. either.

I think I need to learn more about implementation first.

16
17

???

Looks like you’ve just posted your forked branch of Emilie’s git with zero context??

18

I’ve had a crack at porting Plaits as an excercise. Got it to a reasonable working state but still some work to do:

  • currently chord mode and wavetable mode as disabled, as they can’t fit on FLASH (Plaits HW is 256k, patch.init() 128k I think)?
    • could look at calculating the wavetable values on the fly (or loading from SD card) - any pointers here welcome
  • it’s not possible to detect if inputs are patched, so I’ve added a bit of a bodge (using the toggle to signal “trigger is patched” yes/no)
  • LPG params can’t currently be edited, but maybe I can do hold toggle and turn (like on OG plaits)
  • general testing / comparison with VCV version

Any feedback / comments welcome :slight_smile:

3 Likes
19

Hey that’s great work! I will take a look, have thought about porting this an exercise as well.

20

I just checked this and you are correct.

Patch uses stm32H750
1mb of RAM
480Mhz
128kb flash program size

, while Plaits uses STM32F373CCT6
32kb of RAM
72Mhz
256kb flash program size

Do you the wavetables can be loaded from SD card and kept in RAM, it looks like it has to spare.

Braids uses STM32F103CBT6 with 128kb flash also. That should be able to be ported as is right? I think I might have a crack at it, following your port.

22

Hello people. I revive the topic to see if there is anyone who has been able to make progress on this topic?