Nah, I think your misunderstanding... I don't view it like that , and wouldn't even mind if you were (cant speak for @johannes ) , and also I should probably point out Im not trying to defend axoloti. its a normal part of the development process
When someone reports something they think doesn't work or thinks should be done differently, or a new feature, there are two critical things that must happen
- developers must understand exactly what the users are asking for (details are everything!)
- users must understand what already exists, implications etc (they may misunderstand, not know something useful)
at this point you can have a reasonable dialog and work out what needs to be done, without either the risk of confusion and misunderstanding is pretty high. (also me vocalising, also gives johannes a chance to chime in, either with his own views, or to correct me etc.)
so hopefully in this light your will see my replies (if i get the tone right, not always easy!) , really are trying to nail down the problem into the right area...
so coming back to the SRAM vs subpatch...
subpatches have functionality which can increase memory, this includes presets/modulation sources/ voices ... but we know all this, this is not a bug, its functionality, as i said....
i.e. we still need this functionality (no one is asking for mod sources to be removed), but perhaps the current defaulting implementation leads to a bit of bloat that can be removed, by altering the defaults... but in a way that means we don't cause other problems (e.g. users not knowing why it wont save presets because the patch is defaulted to zero presets)
there may be other possibilities to... e.g. perhaps some of these things don't need to be at the sub-patch level, or are defined incorrectly at 'voice level' (I'm thinking presets mainly.. but need to check we don't lose functionality)
so I repeat, Its not about criticism of axoloti or not (I think SRAM usage is always something we will hope to improve... and is likely to be a 'continual' effort, trying to eek more and more out of the board)
its about (as a developer) trying to determine where the problem really lies, and the best way to solve it, and i think its useful to discuss this in the open.
p.s. it should probably be noted, a useful/simplying feature in axoloti at present is subpatch are really just patches, making them different to top level patches could make things a bit more complex for coding.
unfortunately, it doesnt work like that...
CPU usage vs SRAM usage are not related and never will be ...
you can create a huge delay line, that will overflow SRAM, and would use 1% CPU... alternatively, you could crreate an oscillator bank that will use virtual no SRAM and be at 110% CPU...
resources are fixed, but they are not related, and depending on your project you are very likely to run out of one before the other. (there are other fixed resources, e.g. midi/usb traffic which would also become a 'sticking point')
so... the deal is over time, to optimise all these things, but there will be no 'one magic fix' , the changes could/will be all over the code base.
disappearing objects again, if you can reproduce, let us know. its worth getting rid of these kind of issues, and sometimes its not too tricky.
drag n drop subpatches ending on some good newss
Ive just checked into github (awaiting pull) a change that allows subpatches to be dropped onto patches.
Note: really you should only drop from a directory on your search patch or relative to the main patch.
as otherwise when you reload the main patch, it wont find it... this is due to the fact axoloti assumes ALL sub-patches/objects are relative to main patch OR are on search patch. this may be something we can refine BUT really its very bad practice to be linking to objects arbitrarily on your disk