Mutable Models Impressions

#1

I've been playing around with the Mutable Instruments models from the library for Braids, Elements and Clouds. Here are some observations.

Braids - some good results from most of the models but a few missing also like the Casio 'Z' models and triple saw and square.

Elements - the complete model would not compile giving the error message 'Patch start taking too long, disconnecting'. The Tube and String sections don't work, the Diffuser gives a slight metallic character to the sound. Reverb works.

Rings the elements provided (Chorus, Ensemble and Reverb) work but there's no overall model for the device.

Clouds - works with some glitching on the controls.

There are some good demonstrations of these modules on Youtube on https://www.youtube.com/user/DivKidVideo/videos

Overall a great effort which could be excellent with a few tweaks!

Has anyone else found the same results?

#2

Clds granular actually sounds much better than clouds.

I've compared them side by side. Clouds is smeary and slurs where as clds has edginess, clarity and a sharpness.

I'm going to spend Sunday comparing braids. However, a quick play a week ago or so with brds was a little disappointing - the wavetable osc had aliasing when scanning the wavetable.

#3

My favourite Braids models are the Casio 'digital filter' ones. I guess I'll have to convert those myself.

a|x

#4

Clouds , have you done a sync libraries recently , I improved it a bit.

Elements , I was playing with this quite a bit yesterday.
Lmnts compiles fine for me, does the help file not compile for you?
As I mentioned in the other thread, it's very sensitive to parameters being in the 'right' positions and also that your giving it the correct audio inputs.
This is also true for the models, which will basically not do anything if not setup correct,
If I get time I'll see if in can do some more examples or tighten it up a bit
(Difficult since every time I try I instead caught up just playing with it for fun :slight_smile: )

Till then I advise to just experiment I can assure you it all works for me :grinning:

#5

@thetechnobear

I did try a sync on the libraries but must admit didn't connect the lmnts to inputs and outputs but just tried a 'raw' compilation to see how much usage it took. I shall try appropriate connections asap.

Will there be a similar model for Rings? I couldn't see one in the library.

Thanks for your patience with a relative beginner!

#6

yeah these are not the simplest of objects to use, they could do with some work to help find the sweet spots.

rings, a slightly different approach was taken, since essentially its a cut down elements, so only the fx were exposed.
it wasn't will after release that I took a deeper look and realised it had a couple of extra modes.
to add the 'rings module' unfortunately, requires a new firmware version, as part of the code is not available - so wont be included till the next release.
(Ive talked with Johannes, and we are hoping to move the MI modules out of the firmware for the next release, so things will be a bit more flexible)

#7

Progress.

I got lmnts to compile and run (about 55% DSP load) but it does drop out with some control changes. N example is when the Strike Mallet control is taken down to zero.

@thetechnobear I like your example with the Bastl Kastle - I've just ordered some ATtiny devices to do some programming ;o)

#8

Im working on lmnts (and related objects) at the moment, the new version hopefully will clean things up a bit, and also the help patch will given guidance on applicable ranges etc.

many of the problems ive seen are down to CPU load, which can be affected by all sorts of combinations of parameters,
this is not helped by the fact we run at 48k sample rate, where as the eurorack module runs at 32k, so this is 30% extra cpu... it also looks like they are using larger sample buffers to, again, our smaller buffers mean higher cpu.

#9

This is my first post so apologies for asking dumb things.

I was looking for the brds port in the github factory repo but could not find it. Is it located somewhere else ?

Also, while individual version of the oscillator is a good idea for optimisation when you want to stick to a model, if you think of it as base oscillator for a synth, the vast amount of sonic range available from a small set of controls makes the macro version totally worthwhile. I'd be happy to contribute to this if needed.

Grids is also very interesting and easy to compile to other platforms (I've done a vst version in no time).

#10

Sorry, the axoloti-factory was still defaulting to the 1.0.11 branch, changed that to 1.0.12 now.
Here are the brds objects.
The reason I didn't wrap the macro oscillator code is that those always wrap 3 "analog" oscillators and 1 "digital" oscillator, whether used or not in a particular mode, this would consume more memory than required.
Also note that there are changes upcoming (work-in-progress in the experimental branch) that will allow to link libraries to a patch, that will affect the coding style, avoiding the mega-header-file approach, so if you'd do that now it will probably need restyling for the next release.

#11

Good to know, thanks. In a first instance, I willl need to get aquainted to the system and will hold any major work until the system is changed. I've looked at some trivial modules like the vca and it seems all understandable. I've got a few dsp algorithm I'd be interested to try to port and my first goal will be to look if I can run some double precision fixed point arithmetics I've got when higher precision is needed (for distorted filters for examples).

To come back to braids, I completely understand why you did this. however if you'd want to emulate the flexibility of Braids with the current system, you would need to run every model simultaneously which would waste a lot of resources too. Having both would give the whole panel of possibilities.

#12

both approaches have merits/uses...
with elements I kind of did both, lmnts is the whole module, but I also exposed the diffuser/tube/string separately.
but even then I ran into some limitations with this approach, as for the lower level code you would want to change it, in ways that would break the higher level (module) code.
this is why we want to move the code out of firmware, and to then be able to have variations for different objects, this way you will be able to have objects which represent the entire module, and also objects which represent only part of the module.

#13

I'm getting permanent errors for 'brds/feedbackfm' ::

C:\Users\rbrt\DOCUME~1\axoloti/build/xpatch.cpp:517:1: error: 'braids_deriv' does not name a type
braids_deriv::FeedbackFm osc;
^
C:\Users\rbrt\DOCUME~1\axoloti/build/xpatch.cpp: In member function 'void rootc::instancefeedbackfm__1::Init(rootc*)':
C:\Users\rbrt\DOCUME~1\axoloti/build/xpatch.cpp:529:1: error: 'osc' was not declared in this scope
osc.Init();
^
C:\Users\rbrt\DOCUME~1\axoloti/build/xpatch.cpp: In member function 'void rootc::instancefeedbackfm__1::dsp(int32_t, int32_t, int32_t, int32_t (&)[16], int, int, int)':
C:\Users\rbrt\DOCUME~1\axoloti/build/xpatch.cpp:540:1: error: 'osc' was not declared in this scope
osc.set_parameters(USAT((inlet_timbre+param_timbre)>>12,15),USAT((inlet_color+param_color)>>12,15));
^
make: *** [C:\Users\rbrt\DOCUME~1\axoloti/build/xpatch.bin] Error 1
shell task failed, exit value: 1
Compiling patch failed ( C:\Users\rbrt\Documents\axoloti\patches\101_new_1.axp )

#14

Fixed, sync libraries time :slight_smile:

let me know if you come across others in brds that dont compile, sorry i dont have time to go thru them all myself.

Mark

#15

the braids/plucked has a weird CPU usage - it periodically ramps up/down, but maybe that's normal? I haven't yet looked at the code closer.

#16

Find problem with this models of Braids. Open manual for Braids and look to Axo modules. There few models not find, few models have same name and info, as understand - need to recognize this moduls and make new build with corrected names.

I can write later concret duplicated modules, not at home now. But you can find them if look in info of modules and their names.
Now try to build patch wth all Braids models, and set them as them placed in Braids Manual.

Need to recognize models to Braids from manual: 2-7 positions..
2. /\/|-- Variable waveshape
3. /|/|-- Classic saw
4. SYNC - 2 square VCOs with hardsync
5. FOLD Sine/triangle into wavefolder

  1. _|_|_|_ 2 detuned harmonic combs
  2. /|/| x3 - Triple saw and triple square

also TwinPeaks module - its TWNQ?

Very hard to recognize some models of braids there..

#17

the axo names used, are named from the mutable instruments braids code.
no attempt has been made to name them as they are in the manual/front panel.

its better to think of these objects as similar to the MI modules, rather than replicas, there are differences for a variety of reasons, the most obvious of which is the MI module would use an entire CPU / axo for one object!
axo allows you to use many, in different combinations which is pretty unique unless you spend 1000's $ on MI modules :wink:

#18

Yes, understand it, but have interest into original MI modules, not have them on hands and can't recognise this OSC models from manual.
Must say, that BRAIDS on MI site in overview / in site manual / in PDF manual - have different positions.
Not understand why, may be - there various firmware versions with some sing changes that we can view in manual on site, in PDF and in overview..?

#19

The only way to correlate the modules panel display and the names used by axo would be to check the source code ... it's likely in UI.cpp but I'd have to check.

#20

View code form github not help. There text errors on few models.
Need to recognise few models form Axoloti to Braids osc.

SYNC : int PDF its 2 Square or Saw VCO with Hardsync, I find Square and can sum 2 squares.. About 2 Saw - find VSAW - in scope, its doubleSaw. As understand - in axoloti this 2 modules can be used as SYNC. No ready module. Ok.

  • VSAW - can understand it as only part of SYNC module (may be not true)

  • Digitalmodulation - digital modem sounds or mobile phone..and its QPSK .

  • BUZZ, пthink that its - _|_|_|_|_ - This digital synthesis algorithm generates a smooth sequence of waveforms, transitioning from a sine wave to a Dirac comb.

  • QuestionMark (its not QPSK noise). Don't know whats it!!!???

  • Not find Variable waveshape (a-la Voyager osc - triangle to sawtooth to square to pulse), there not ready module, need to use mix of TRI/SAW/SQUARE/SQ+pulse.

  • Triple Saw/Sq/Tri/Sine. Not ready module, need to triple sum of Sw/Sq/Tri/Sine

Other modules already recognised!

All Braids osc models with details on Braids manual page..
Bigg question to recognize QuestionMark.. not find anything same in video examples of Braids.