@lokki I now realize that the proper way to get the envelope back out of a polyphonic voice subpatch is to use patch/polyindex and a demux to multiple outputs....
↧
Subpatch inlets scaling values
↧
SRAM overflow: help making patch more efficient
there are I think quite a few topics discussing this...
the one to start with is:
perhaps the tip that is least obvious, is making sure execution is done in the right order.
the reason is simply, if you do something that is required to be executed on the next cycle,
the the previous value is stored in ram..
on a large patch, thats not kept this in mind, this can add up really quickly
(also yes, modulation sources/targets and presets can eat memory fast - so minimise these)
generally with DSP (actually most coding 
) its best to try to keep in mind 'best practice' as you go along like those above, rather than trying to come back and fix things later.
ok, you do have to avoid premature optimisation... thats why i say best practices, rather than optimise as you go along.
of course, at the end of the day Axoloti is not like your desktop, its ram/cpu is limited, thats part of the fun, seeing how much we can squeeze out of a small/inexpensive thing.
↧
↧
SRAM overflow: help making patch more efficient
EDIT - spent too long writing and technobear beat me too it!
Some things to think about with sram-
Execution order is important, especially for audio signals, make sure no output wires are going to objects above or directly to the left.
It can help to remove any unneeded inlets/dials from objects. It's coding, but pretty simple
Try alternative methods - I've found nearly everything can be implemented in different ways. There may be alternative ways of doing things in your patch, or alternative objects, that use less sram.
Changing the amount of voices in poly sub patches can help. Also, make sure anything that doesn't need to be polyphonic isn't in the subpatch. I.e. If you have an lfo in the subpatch there is an lfo per voice. So unless you need poly lfos, keep it out of the subpatch and feed it into an inlet. In my first patch I had a bunch of control scaling going on in the poly subpatch which overflowed sram, but I moved the scaling to the main patch and it was fine.
Also, maybe the patch is just too ambitious?
↧
SRAM overflow: help making patch more efficient
I hope not!
Yes I've read about these methods of optimization. I think I was pretty good at laying things out from left to right, top to bottom, but I'll go over it again and see what else I can do.
Also I've kept my LFOs outside the voice patch, but since it is mpe polyphonic, i have my envelopes and of course x, y, and z controls inside the voice.
I agree that this is part of the fun. And I like the challenge...
But I was hoping for more advanced ideas like perhaps another strategy for making a mod matrix that combines several sources to each target...
For instance: is there a way to have global variables that are exposed to all subpatch without the use of inlets and patch cords? Right now I'm using send and receives...
And perhaps it would be more efficient if my mod receive subpatch were replaced by a coded object doing the same thing?
Would love to hear your thoughts about other ways to approach this. I'm not giving up!
cheers! thanks for your help.
↧
SRAM overflow: help making patch more efficient
If you post the patch or at least a screenshot, it's going to be a lot easier to see what you have done.
Without it's pretty much like shooting in the dark.
↧
↧
SRAM overflow: help making patch more efficient
OK I'll post some hing when I get home. Thanks for the help!
↧
SRAM overflow: help making patch more efficient
yes, use a table ….
ive done this a few times, think of the table as raw data, and you can use an offset via polyindex for voices. with a bit of thought, and design, tables can be used as a way to implement alternatives to lots of things
my personal approach is if things are getting too complex is to create a custom object in c++.
as @jaffasplaffa said, its often hard to generalise optimisation, since it its highly dependent on how you have patched things and what you are trying to achieve... and 'compromise' can sometimes be part of the solution, and that requires knowing whats the important or problematics parts are.
↧
SRAM overflow: help making patch more efficient
That is an excellent idea!
I'll try this first thing tomorrow.
I don't know c++ but if it will allow me to finish this synth the way I want it, I'm willing to learn what I have to.
I'll try the table approach first and report back.
↧
Question about internal flash memory cycles
I understand your concern, but it is not an issue.
Patches (either live, from flash memory or from sdcard) are (equally) loaded into RAM to run. Otherwise there would be a performance difference between patches loaded live, sdcard or flash.
SRAM and SDRAM do not have limited write/erase cycles.
best,
Johannes
↧
↧
Axoloti release 2.0.0
It's been a long and deep process, finally I've reached the point where all changes converged into a new release. It hasn't been tested extensively yet, showstopper bugs may still exist.
The first one I noticed is that the software quits unexpectedly on Windows, immediately after initiating firmware flashing. The firmware flashing does work, but you need to re-launch the software.
USB hub support did not make it, I had it working (using the Chibios Community USB Host framework code) but noticed data drops on certain MIDI controllers. So that's rolled back to the implementation in 1.0.12.
My first priority is addressing showstopper bugs in this release, and migration from the 1.0.12 release.
From the release notes:
New in Axoloti release 2.0.0
Multiple patches can now run simultaneously
MIDI routing
Patches do not refer any more to specific MIDI devices and ports, but to virtual MIDI ports.
Physical MIDI in- and outputs are now routed to virtual ports via the "Midi Routing" dialog in the
board menu.
Midi routing settings can be stored on sdcard.
- MIDI input monitor
Shows the content of the MIDI input buffer.
MIDI Sysex support
New objects
patch/bus_mixandpatch/bus_rcv
allow to route audio across running patches
Improved undo/redo
Introducing modules
Modules are dynamically loaded libraries, loaded only once when used in multiple patches.
They require an sdcard, and are located in /lib/libraryname.elf
Compiling and uploading libraries happens automagically when running a patch.
Audio input/output level meters
Improved USB protocol handling
Axoloti Core boards upgraded to v2.0 firmware can't connect to Axoloti v1.x software.
If you need to go back to 1.x after upgrading you need to downgrade to 1.0.12 firmware via the
board menu in 2.x, or do a "rescue flash".
Changes in general behaviour:
Compiled patches now carry an .elf extension (instead of .bin)
"controller object" configuration is gone
Since multiple patches can run, one "master" patch can be used to load other patches, for example in
response to program changes. It can also contain your effects section, midi indirections, or other
"utilities" you want to keep running.
Old compiled patches do not run anymore, sorry
MIDI i/o on gpio does not work anymore
When dsp load exceeds 98%, patches are muted
No more dsp load indicator in patch window
There is a global dsp load indicator in the main window instead.
- Menubars are inside windows on Mac OSX, no useful menubar on top of the screen.
The trick that puts the menubar on top of the screen unfortunately causes some menus to stop functioning correctly.
- Patches used to run in with a directory carriying the patch' name as working directory
This is no longer the case, it conflicts with the concept of multiple running patches.
- Axoloti Runtime is no longer used, but installing gcc-arm-none-eabi manually is required.
An error message with download/installation instructions is shown at startup when missing.
- Space characters in the installation path are not allowed on Mac OSX and Linux
An error message is shown...
Yet incomplete:
- Several MI clone objects do not work anymore:
fx/lmnts/lmnts
fx/lmnts/string
fx/lmnts/tube
fx/clds/clds
fx/clds/pitchshifter
fx/rngs/chorus
fx/rngs/ensemble
fx/rngs/reverb
fx/strms/strms
fx/wrps/wrps
Those need to be adapted to use modules...
- A preliminary port of tinysoundfont library to play soundfonts need further work
Object code transitions:
- Static memory allocations to use sdram are discouraged.
Use dynamic memory allocation instead, cfr. ax_malloc in api/axoloti_memory.h
- Object init code now has an integer return value (error code).
Return value 0 means "everything OK". Predefined error codes are defined in api/error_codes.h
Other return values will cause the patch to abort and report the error code.
Return statements without an argument will cause a compiler error.
- MidiSend1(), MidiSend2(), MidiSend3() API migration
MidiSend1(dev,port,b0), MidiSend2(dev,port,b0,b1), MidiSend3(dev,port,b0,b1,b2) had a separate device
and port argument, now we only have a virtual port number.
Those calls need to be migrated to midiSend1(vport, b0), midiSend2(vport,b0,b1),
midiSend3(vport,b0,b1,b2).
Notice the lowercase m!
↧
The path towards Axoloti 2.0
Sorry, live patching did not make it into 2.0. It required to take three rather large steps at once.
One of them is dynamic loaded libraries and dynamically linking against firmware, and this made it into 2.0. The other steps are annotating dynamic loaded libraries so that they are patch-able objects, and then auto-generating and on-the-fly modifying binary glue-code that moves data and calling its functions. I wrote some test code for the latter, independent from Axoloti firmware, but still premature. The evil is in premature optimization, which I did far too much, and ran into a very hard wall. Efforts will resume after 2.0 reaches full stability.
↧
Axoloti release 2.0.0
Wow, that's exciting. Thanks for the great work, Johannes!
I installed the new software (Ubuntu) and let it update the firmware. It's necessary to restart the program to also recognise the objects in the home folder. Then I got this error for every patch that I try to load:
Generate code complete
compiling /home/j/axoloti-2.0.0/build/xpatch.cpp
/opt/Axoloti/app/env/patch.mk:110: recipe for target '/home/j/axoloti-2.0.0/build/xpatch.o' failed
/bin/sh: 1: arm-none-eabi-g++: not found
make: *** [/home/j/axoloti-2.0.0/build/xpatch.o] Error 127
Compiling patch failed
And this on startup:
error: compiler arm-none-eabi-g++ not found in path=/opt/Axoloti/app/platform_linux/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin, not installed?
Something I forgot in installation maybe? How to solve this?
↧
Axoloti release 2.0.0
Not sure about the Linux version but on windows, in the console, there is a URL to grab the toolchain needed. I'll guess you can grab it with apt.
↧
↧
Axoloti release 2.0.0
Ah. I missed this in the release notes:
There is a package that can be installed with apt, but it's an older version. I found the latest version (gcc-arm-none-eabi-9-2019-q4-major) as a tarball, but now I don't know where to unpack so Axoloti can find it. Help?
↧
Axoloti release 2.0.0
Just want to make sure that I understand it correctly:
- Does that mean that Axoloti 2.0 is not backwards compatible and no patches what we made in 10.0.12 will work in version 2.0?
↧
Axoloti release 2.0.0
Most patches should still work, but you'll have to recompile them. Patches using these objects won't work for now.
Guess I'll upgrade one of my boards for testing and leave the other ones on the previous version for now since I use some of those objects.
↧
Axoloti release 2.0.0
What do you mean by recompile a patch?
↧
↧
Axoloti release 2.0.0
just open it in the new editor and run
↧
Axoloti release 2.0.0
Ah Okay. I guess that is given then. Thought they ment something else, that I was not aware of.
↧
Question about internal flash memory cycles
Great! Nice to know that i wont wear out my precious Axoloti flash by going live 100 times a day when i explore all the different modules 
So it is the firmware updates that wear on the flash?
I will most certainly buy a few more Axoloti's before the flash wears out anyway...such a flexible machine and patcher, and great community!
Thanks a lot for the answer and for making this beast!
Have a good day
/Magnus
↧