Mutable - Any chance Grids will be converted?

#1

Hey :slight_smile:

I think this is mostly directed to @thetechnobear and @johannes:

Any chance the MI Grids also will be converted to Axoloti?

Thanks, Jaffa

#2

there is always a chance :slight_smile:

in the current software version, this would need a firmware update - so cannot happen till a new release.

in the next release, however, we will be adding a new 'modules' feature, which will move the MI functionality out of the firmware, and into modules - this will allow new (and changes to) modules without the necessity of a new firmware release.

#3

Sounds great @thetechnobear :slight_smile:

Grids can do some really cool stuff. Would love to ble able to use it with Axoloti.

Will see that the next releases brings :wink:

#4

It's relatively simple, code-wise. Should be pretty easy to turn into an Axoloti object. I've been thinking about tackling it myself for some time now.

a|x

#5

Ah, sounds great @toneburst :slight_smile:

#6

@thetechnobear

Since the internal stuff from the mutable object will be exposed to the users, will the phasevocoder from the vocoder also be available? That would be really great for audio processing stretching and so on :slight_smile:

#7

That's the Warps vocoder, I presume? I'd like to see that as a separate object, too, as I think a good, optimised vocoder is something conspicuously lacking in Axolotl-World.

a|x

#8

its already there. see fx/wrps/vocoder - I just forgot to add the params the settings it has (releasetime/formant shift) ... cant remember how much I tested/played with it, especially if I didn't spot missing params, probably something I got sidetracked on.

#9

Cool, will try that!

a|x

#10

Ahh that is why Warps is so sparse. I tried it a few times, but never really used it, cause of lack of parameters. Also looked inside it for the phasevocoder but couldnt make anything of it.

@toneburst

#11

Would be cool to have the original parameters. I might have a look myself. Is the entire object code actually exposed in the Axoloti code editor, though, @thetechnobear?

a|x

#12

Not not as it is now. All of the Mutable objects code are in the firmware. But the code will be exposed to us users in a future release, as I understand.

#13

yes, the vocoder code is available in the current firmware.

if you do this, don't put into the community library, as i will update the factory object... as its kind of a 'bug', and we dont really want duplicates of factory objects in the community library, it will just confuse users. ... you could however send me the updated object, if you do it first, and tested it, then I can put in the factory lib.
note: its trivial to add the params, the slightly time consuming bit, is to check the rest of the MI code, to determine what the range of the parameter should be (i.e. how you convert from axo type 0..64 to the float) ... usually its 0..1 but not always.

actually its the opposite of this, not ALL of the MI code is in firmware, only the part we use.
any part that has been included is available to user objects.

however, another issue is you cannot change the MI code without breaking things, which is why we needed a more complex solution for the next release.

#14

Ahh well all was overstating it. I meant that most of the Mutable objects code is in the firmware and only some in the objects itself. When I look in the code of the objects it seems like they reference to code in the firmware.

Anyway, Cant wait to try out some phasevocoding :slight_smile:

#15

yes, because if it had been moved to the objects (which would be a massive job!) it would be inlined, which would create an overflow on the code region for the patch, and even if not, would leave only a tiny amount of space for your patch code - this is why it was done this way ... we think of these things :wink:
for the next release, we are allowing compilable units within a patch, so whilst it uses a bit of patch memory, it doesnt explode, and the approach we have taken doesnt require a rewrite of all the MI code!

#16

really nice to have the vocoder! this is one the sounds I really wanted to have in my palette but didn't realize on axoloti yet :slight_smile:

although more than 90% cpu is really heavy.

#17

@thetechnobear
I really love the vocoder, works great so far.a But is there any chance to get the timbre parameter of the original?

Also some kind of decay (would be falltime of the envelope followers I guess) would be great but maybe I can achieve this by compressing the modulator signal.

#18

i'll add the release time and format control when i get time.

btw: one misunderstanding in the above thread is how warps works...
basically its got an algorithm parameter, this changes what warps does ... so basically you should be able to use wrps object to also do the vocoding and it has more functionality (like the MI modules)

on wrps - i think then density is timbre (i suspect MI changed the name on the front panel, but didnt bother changing the code), and drive 1/2, (i assume without checking the code) are the levels for in 1 and 2... given thats what the warps panel has.

the best way to get an understanding of the usage of MI modules is to go take a look at he MI manuals for the modules, usually Ive just coded up a 1:1 mapping , but as above sometimes MI has changed the 'labels' on the front panel ... compared to the code (and I've used the names in the code)

#19

@Blindsmyth , sync libraries time - Ive added formant shift and release to the vocoder

#20

This is really great opens up a lot more expression in the module.

So Ideally we would have only one axoloti object and a possibitly to change algorithms on the object like with the original module? That would be terriffic!