Optimized patching on Axoloti!

#1

Hey

I was wondering about a few things when patching in Axoloti, regarding best practice. I am not concluding anything here just asking a few question, cause I want to make sure I understand it correctly, so I can do the right things to optimize my patching.

  1. Objects are classes?
    Is my understanding right that when I create a new object I basically create a new class?

  2. Reusing same object/classes reuses the code and saves memory/DSP?

  3. How does the patcher differentiate objects?
    a.
    II have to identical objects, but they are embedded. In this case does the patcher regards them as separate objects/classes, since they are embedded?
    b.
    I use a NOT embedded object and loads the same exact object with same sha etc. 2 times.

Are there any difference in DSP/memory use in the 2 cases, embedded/not embedded?

I started to think about it, cause I am making an object where I need 4 of the same objects, but they all need a different offset. I could simply just make the offset as a variable, so you can set it manually. this will use the same object X times. But I thought about making the offsets inside the objects and instead save 4 different, separate objects.......

Which lead me to the question > When they are regarded as separate objects, being embedded, with their own ID, do Axoloti reuse the code cause its the same code?........ or does it reuse the code based on names or ID's?

I am wondering if there is a performance difference in those cases, embedded not embedded? Or if copying the same object with the same ID 4 times uses same memory/DSP same as creating 4 of the same object with 4 different ID's?

So I thought I'd swing it by the experts :slight_smile:

Have a nice Sunday :slight_smile:

#2

1 - Objects are indeed classes, or rather they become classes in the strict C++ sense when the patch is built (as in going live) or loaded as an already built patch from the SD card.

2 - When a patch is being built, each instance of the same axo object (sharing uuid/sha) is being built as unique C++ classes. That means there is nothing to save by using the same axo object several times in a patch, as opposed to using similar objects with different uuid/sha.

What happens is that if you have an axo object called "foo" and place two of them in a patch, the generated C++ code will have two distinct classes "instance_foo___1" and "instance_foo___2".

3 - Same for this case. Each instance of an object in a patch, whether embedded or not becomes a distinct C++ class.

You can gleam things like this by looking at build/xpatch.cpp in the Axoloti home directory after the patch is built. I'm not sure why it's done like this. Haven't really thought about it, but I bet there's a good reason. Perhaps Johannes can fill us in on that?

#3

@DrJustice
Thank you for the detailed answer, that makes a sense :slight_smile:

I'll check out that file and see if I can make any sense of it .

So not much to save on that account. Anyway, just ordered an extra Axoloti today as a birthday present for myself :slight_smile: Yay. An extra board give a little bit extra DSP "headroom", so I'll save my worries for later :slight_smile:

#4

As far as i understood, actual multiple C++ instances only appear in patchers in polyphonic mode.

#5

Ah, yes, makes sense that it happens at least on the voice level, or you'd soon run out of SRAM. It doesn't make any difference for jaffasplaffa's questions though - i.e. memory efficiency within a patch.