Thanks! I will totally check them out. This is my first axo project and I'm almost finished the architecture for it. I now plan on trying out this basic architecture with various kinds of signal sources so I'll definitely try these in there.
How are they efficiency-wise?
This is more like a work around rather than a fix: you could just divide by 4 to scale it back?
WOW!!!!
Congratulations!
Yes that is what I did. But I was wondering why it was doing this. Is this a documented behavior?
Sorry no clue why it does it.
is it your own subpatch or one from the community? can you share the patch or a screenshot?
My own.
When I map these inlets directly to a debugging outlet, the numbers come out multiplied by 4.
What happens if you change the polyphony to 2? I don't know how you measure the values inside the subpatch, but if you put them to an outlet again, this will be multiplied by 4, once for each voice.
hehe, was about to write the same 
This is really cool!
Would love to see the patch, if you embed any objects you've customized and save the patch the custom objects will save with the patch and the patch can be shared.
Getting the objects in the library properly requires some github shenanigans.
Aha. Ok so it is the outlet, not the inlet, that is multiplying the value by the number of voices. Right?
That explains why my ADSRs were not modulating much! I was reducing my modulation by a factor of 4, thinking that it was the inputs doing this.
Thanks for the clarification.
think about it this way, how else could it behave? it basically has to add the four voices together if you have an outlet from 4 voices. as @Captain_Burek says, try decreasing the poly value to 2, the inlet should now multiply by 2.
Apologies in advance. I only want to express my gratitude and out myself as a fan-boy.
I think the Axoloti is the best invention since sliced bread. Because a lot of expensive hardware devices are close to being great but often slightly miss the mark and you can't do anything about it.
Whereas the Axoloti is completely customizable and has such a great way of building patches. I love the combination of visual/graph based editing together with being able to write C++ code. I like the choice of C++ over adding some high-level language, I guess it's common sense because of the execution speed.
It let's me create way more complex sequencers, I can glue existing Midi devices by making it process midi data in interesting ways. It's simply more bang for the buck if you are willing put some some work into it.
Thanks to all the providers of patches and objects, they are immensely useful.
At this point I am only using existing midi-controllers but I am looking forward to building my own.
By the way, are there any ready-made PCBs available for building a sequencer?
I am also looking for instructions on connecting/programming small screens (I got an 128x64 pixel OLED available for example)
Sure it makes perfect sense. I'm just used to the max msp / pure data bang event paradigm where the value that would come out would just be the last one received, not their sum. In general this is the main thing I have to get used to in axoloti. Everything is treated as a signal. All inlets and outlets are always "on". In max, when using non-signal connections, you can have several outs going into a single in, and the inlet gets updated with the last event.
No need for apologies... Axoloti is as awesome as you say
Johannes was working on creating a control unit : http://www.axoloti.com/axoloti-control/
But there is no release date for it as it's not a priority.
I guess you could get an Axocontrol from music thing modular or a hohum pcb
regarding the OLED thing. check in the forum. Tiar, Aka Smashed transistors has made some nice, easy and essential objects for it.
connecting the oled to the board is also pretty straightforward.
greetings.
I will do it next week. I was thinking about making a final object closed because it's a really complexe patch to understand with ton of objects everywhere. just a picture can be a good exemple :
But I think few people is able to understand it and modify it if they want. So I will make a final object "Open", and drop it with objects I've customized like my wavefolder and my complex-OSC.
Can you just tell me more about Github "shenanigans" ? what is that ? I've never used github to upload something...
Ha, it looks like my patches!
See here for the github stuff
Hi again.
I've hit a brick wall with the development of my first Axoloti project. I need your expert help.
I was just adding the finishing touches to my patch: a mod matrix. But have now run out of ram.
The mod matrix is essential to the design of my synth, so it would be great to get this going.
SRAM' overflowed by 38504 bytesCCMSRAM' overflowed by 26400 bytes
that's a lot!
my mod matrix is rather large, if I remove it the patch runs... I just can't map any of my modulation points.
Since it is an MPE synth, a lot of the mod targets are inside the voice subpatch. The way it works is I have "modreceive" supbatch for each modulation target inside my voice subpatch. Each of these modreceive subpatches receives ALL the mod sources, and these get multiplied together in the interface-specified amounts in order to produce one grand total mod amount for each target.
This is obviously very costly, but I'm not sure how else to implement it.
Perhaps it would be more efficient if I could hard code a modreceive object?
Any help, tips, concepts or strategies would be appreciated.
Another thing that is using up ram is the midi interface... I am using midi rotary encoders and led-lit buttons and changing the behavior of the interface in order to access every part of the synth.
I have 16b tables for recording the position of the encoders and these are currently in sram. I tried placing those tables in sdram, but that seemed to overload the dsp. I'll try again, and try to make the oscillators and effects more efficient, but I'm not sure even that would be enough.
So I just passed all my tables to sd ram and it did not help much at all. I'm getting these numbers now:
`SRAM' overflowed by 37368 bytes
`CCMSRAM' overflowed by 25408 bytes
