Yes of course, squeeze as much out of it as possible 
But adding a reverb to an all ready complicated patch is going to be hard. Reverbs takes alot of memory, as you need many all pass filters to achieve that.
Anyway, again, I hope you get it all sorted
Or else for the effects, it might be worth getting an extra Axoloti. That is what I did when I started running out of memory. Effects could easily work on a second board without too much problems 
as stated in the topic i linked on your other thread, mod sources and target are relatively expensive.
so having a huge number is going to cause issues, if i was doing it, id be probably be looking for a different way to achieve something similar but a bit less generic, and so cheaper to implement.
as @jaffasplaffa pointed out, the thing about axoloti (and will still be true of an H7 version) is that its not a general purpose computer, so building 'generic' patches is not really the best way to tackle it,
rather you'd be better off to create a number of patches perhaps with variations ...
looking at this a different way
a VST on your desktop has to supply things like mod matrix because, as an end user, you cannot modify the code... you cannot change the code to say Y axis should now go to wave shape rather than than filter cutoff. so it has to be 'soft coded' to allow this flexibility.
this is not true of axoloti, you have the ability to change the patch, to change the code!
so you can create variations that behave different.
so what might be two different presets on a VST, can be two different patches.
once you get used to this, it can become pretty liberating for a few reasons
a) you don't have to build huge complex patches, you can aim to build smaller things quicker.
b) you are not limited in your patches by some predetermined design decisions.
(b) can become quite a pain, when your patch becomes much larger... because you will keep hitting your head against various brick walls, either due to resources, or ones imposed by how you write the patch.
also... i think axoloti OS 2.0, is going to bring some interesting new approaches, given patch modularity has changed... an area I look forward to exploring
I understand this yes. But I bought the axoloti board recently after coming up with a design for a synth. I wanted to create what I had in mind. I had a roli seaboard lying around that I wasn't using, because there are too few mpe synth. I don't like using vsts... I had it hooked up to an iPad and there are some great synth in there with mpe, but I still was not using it. So I found the axoloti platform and I was blown away.
So I started off with a vision for a synth architecture/interface that allows you to quickly access lots of sounds without presets, apply modulation really quickly and intuitively and have it be really expressive. This is the synth I feel was missing from my collection and that I thought I could create myself. I must say, what I have now is almost there. I've had to take some shortcuts but I can keep tweaking it.
I am very interested in what 2.0.0 offers. As well as the urklang ot H7 board... I'm hooked!
The 2.0.0 with multiple patches is going to be awesome. I was just asking in another thread how to use controller objects to change my oscillator subpatches. It looks like 2.0.0 will make the functionality I was looking for possible. So yeah. I'm so looking forward to how this evolves. I thought I was late to the game but it looks like it is just the beginning.
Hi @thetechnobear . After having built a functional first version of my mpe synth a few weeks ago and having played and recorded with it (very satisfying experience to build and then play/ produce something with your own instrument)---
I'm now itching to make it more efficient, and have been thinking about your singleton suggestion. I was not ready to dive into it when you suggest it, and just needed to finish the version I had in mind, but I'm now ready to slowly take a plunge in this direction.
I've read up on it and have looked at the objects you sent me. But I'm having trouble figuring out how to approach this in my setup. The issue is that I have some "global" parameters, like the positions of knobs and the amounts in the mod matrix, but mostly I have "per voice" parameters (since this is mpe, the summed up values from the mod matrix need to be calculated per voice).
What would be the right way to approach this? (I'm trying to imagine what you meant by "c" in the above quote).
This is where I am conceptually:
-create a singleton for each of the "mod sources" (including anything that affects a synth parameter, such as the position of a parameter knob on the interface).
-create custom objects that set the appropriate singleton values based on what i do with the interface.
-create custom objects that update the interface LEDs based on the state of the interface by reading from the appropriate singletons
-create a custom object for each of the synth's parameters for each of the synth's voices which collects the values of these mod source singletons and processes them to get the current value of the given per-voice synth parameter.
What do you think?
Thanks for your time, you are a great help.