Built from a clean source checkout on Linux. Firmware update was detected and proceeded without issue. I didn't have to manually rescue or do anything special. Everything came up just fine after that. Libraries were all fetched normally. I haven't noticed any major issues yet.

Got this going on windows make sure to rename your existing axo folder it doesn't like being installed over the top you can use the installer for gcc 7-2018-q2 win32 but you might need to restart your pc to update parth.

@johannes "MIDI i/o on gpio does not work anymore" so i assume the way to get the axo talking to another mcu using serial midi now would be to use pads on bridge between the main board and the midi power section? i assume this change is due to the new midi routing system so the feature won't return?

Hello wonderful Axo community.

I'm new to coding. I've made a couple of variants of an object meant to encapsulate the functionality of a subpatch I was using that was too sram expensive.

The first version I made declared several variables and was not very efficient memory wise.

So I tried to put the whole thing into one equation, without declaring any variables and this saves a lot of memory (only using about half), but uses too much DSP resources and I end up overloading.

would like to know what would be the best way of approaching this.

Here is the original code with a bunch of variables, hungry for memory:

int te1 = attr_t1.array[_USAT((attrtarget),attr_t1.LENGTHPOW)]<<attr_t1.GAIN;
int te2 = attr_t2.array[_USAT((attrtarget),attr_t2.LENGTHPOW)]<<attr_t2.GAIN;
int tl1 = attr_t3.array[_USAT((attrtarget),attr_t3.LENGTHPOW)]<<attr_t3.GAIN;
int tl2 = attr_t4.array[_USAT((attrtarget),attr_t4.LENGTHPOW)]<<attr_t4.GAIN;
int tx = attr_t5.array[_USAT((attrtarget),attr_t5.LENGTHPOW)]<<attr_t5.GAIN;
int ty = attr_t6.array[_USAT((attrtarget),attr_t6.LENGTHPOW)]<<attr_t6.GAIN;
int tz = attr_t7.array[_USAT((attrtarget),attr_t7.LENGTHPOW)]<<attr_t7.GAIN;

int bpe1 = (te1-(1<<26))<<1;
int bpe2 = (te2-(1<<26))<<1;
int bpl1 = (tl1-(1<<26))<<1;
int bpl2 = (tl2-(1<<26))<<1;
int bpx = (tx-(1<<26))<<1;
int bpy = (ty-(1<<26))<<1;
int bpz = (tz-(1<<26))<<1;

int se1 = attr_ms.array[_USAT((0),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int se2 = attr_ms.array[_USAT((1),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sl1 = attr_ms.array[_USAT((2),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sl2 = attr_ms.array[_USAT((3),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sx = attr_ms.array[_USAT((4),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sy = attr_ms.array[_USAT((5),attrms.LENGTHPOW)]<<attr_ms.GAIN;
int sz = attr_ms.array[_USAT((6),attrms.LENGTHPOW)]<<attr_ms.GAIN;

int e1 = ___SMMUL(bpe1<<3,se1<<2);
int e2 = ___SMMUL(bpe2<<3,se2<<2);
int l1 = ___SMMUL(bpl1<<3,sl1<<2);
int l2 = ___SMMUL(bpl2<<3,sl2<<2);
int xt = ___SMMUL(bpx<<3,sx<<2);
int yt = ___SMMUL(bpy<<3,sy<<2);
int zt = ___SMMUL(bpz<<3,sz<<2);

outlet_total = e1 + e2 + l1 + l2 + xt + yt + zt + inlet_initial;

Here is the second one that is one equation, more memory efficient, but dsp hungry.

outlet_total =
(__SMMUL((((attrt1.array[USAT((attr_target),attr_t1.LENGTHPOW)]<<attr_t1.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((+ 0),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt2.array[USAT((attr_target),attr_t2.LENGTHPOW)]<<attr_t2.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((+ 1),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt3.array[USAT((attr_target),attr_t3.LENGTHPOW)]<<attr_t3.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((+ 2),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt4.array[USAT((attr_target),attr_t4.LENGTHPOW)]<<attr_t4.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((+ 3),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt5.array[USAT((attr_target),attr_t5.LENGTHPOW)]<<attr_t5.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((+ 4),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt6.array[USAT((attr_target),attr_t6.LENGTHPOW)]<<attr_t6.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((+ 5),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
(__SMMUL((((attrt7.array[USAT((attr_target),attr_t7.LENGTHPOW)]<<attr_t7.GAIN)-(1<<26))<<1)<<3,(attr_ms.array[USAT((+ 6),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2))+
inlet_initial;

How should I approach making this more efficient. They both work. But I need 192 of them in my patch, so they need to be as efficient as possible.

I still lack a lot of the coding concepts. Perhaps there is another assembler instruction I can use?
Any help welcome!

Ok I just discovered ___SMMLA and tried to implement the object in a third way, using accumulation.

int32_t accum = __SMMUL((((attrt1.array[USAT((attr_target),attr_t1.LENGTHPOW)]<<attr_t1.GAIN)-(1<<26))<<1)<<3, (attr_ms.array[USAT((+ 0),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2);
accum = __SMMLA((((attrt2.array[USAT((attr_target),attr_t2.LENGTHPOW)]<<attr_t2.GAIN)-(1<<26))<<1)<<3, (attr_ms.array[USAT((+ 1),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2, accum);
accum = __SMMLA((((attrt3.array[USAT((attr_target),attr_t3.LENGTHPOW)]<<attr_t3.GAIN)-(1<<26))<<1)<<3, (attr_ms.array[USAT((+ 2),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2, accum);
accum = __SMMLA((((attrt4.array[USAT((attr_target),attr_t4.LENGTHPOW)]<<attr_t4.GAIN)-(1<<26))<<1)<<3, (attr_ms.array[USAT((+ 3),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2, accum);
accum = __SMMLA((((attrt5.array[USAT((attr_target),attr_t5.LENGTHPOW)]<<attr_t5.GAIN)-(1<<26))<<1)<<3, (attr_ms.array[USAT((+ 4),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2, accum);
accum = __SMMLA((((attrt6.array[USAT((attr_target),attr_t6.LENGTHPOW)]<<attr_t6.GAIN)-(1<<26))<<1)<<3, (attr_ms.array[USAT((+ 5),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2, accum);
accum = __SMMLA((((attrt7.array[USAT((attr_target),attr_t7.LENGTHPOW)]<<attr_t7.GAIN)-(1<<26))<<1)<<3, (attr_ms.array[USAT((+ 6),attr_ms.LENGTHPOW)]<<attr_ms.GAIN)<<2, accum);
accum = inlet_initial+accum;

outlet_total = accum;

This one compiles, but does not function properly (would have to dig a bit), however there is no performance increase compared to the second version of the object above.

Is there anything I can do to make this more efficient?

the basic idea is I'm receiving data from attributed tables, converting them to bipolar, multiplying these values with data from another table, then summing the results all up with the initial value coming in the inlet.

thanks for your help!

ohh as a solder freak this turns me on <3

KYou’d be better to post the object and the patch.

For easier sharing/debugging
use an embedded custom object, in a single patch that demonstrates the issue , in context, with as little extra unrelated stuff as possible.

reason to share a single embedded patch is axoloti is able
open a single patch via a url.

The easier you make it for others to replicate your issue, the more likely they dive in an help

Edit: make sure your ‘test’ patch does an something, when it works ... as the person helping will want to know if it’s working ... doing stuff in isolation is no fun

test modreceive explicit.axp (6.5 KB)

test modreceive compact.axp (6.2 KB)

sorry, i'm new to this... here are the two first attempts...

thank you so much for your patience with me. You are a wonderful community and I am learning a lot.

It is difficult to show you a stripped down version that does something... The whole patch is highly dependent on the hardware i'm using...

But perhaps I could I explain the steps better, and someone will think of a way to improve it.

This is a mod matrix. It distributes 7 modulation sources to (ideally) 44 different destinations.

In my main patch, I have 7 tables filled with the amounts in which each mod source is applied to each mod destination.

image.png952x483 74 KB

Then, inside my voice patch, I have a 44 mod receive objects (the ones I shared above), that receive the data from these, each destination using an offset corresponding to it to access the relevant amounts of modulation. It also receives another table, specific to each voice (I have four voices), that is filled with the current modulation parameters for that voice (this is MPE, so it is different for each voice), and multiplies the amounts specified in those first 7 tables with the actual current value of those modulation sources. Then the results are added up including the "initial value" (which I specify directly with my interface knobs, etc...).

My first go at thiswas just to patch it:

image.png1046x496 44.8 KB

image.png828x959 71.8 KB

I hope this helps understand what I'm trying to achieve. This first attempt to just patch the functionality failed due to sram overflow. So I decided to code a custom object (in the two files shared above). But now it seems that I still can't get much more than Since I need so many of these, inside the voice, and there are four voices, and all this multiplication going on it eats up a lot of dsp.

honestly i don't really know what your trying to do... but it does look pretty inefficient

(also as i mentioned, the approach you are using with attributes will NOT work)

sorry, I don't have time to create a custom object to deal with what you are trying to do,
but Ive put together a quick example, of the 'singleton technique' , i described above...
and how to do it in axoloti.

you need to place the stuff in objects, into your objects directory... (*)
this creates two custom objects. single_set and single_get... (actually single_set is a bit misnamed it should be something like single_alloc)

then there is a test patch in patches/tests/singleton.axp

(*) you will need to then use reload objects, or restart axoloti editor to pick them up.

what does it do?
it defines an c++ object called singleton, that can store 100 signed ints, and allow setting and getting,
which can be used anywhere in a patch, and will always refer to the same object.

ive then created two trivial objects, which demonstrates how to use it.
single_set , actually creates the Single, and then sets one of its elements (3) (due to the create, you can only use it once in the patch )
single_get, just return the 3rd elements value.

THIS IS NOT INTENDED TO BE USEFUL - its a demo of the technique.

Ive tried to make the c++ as simple as possible, so you should be able to adapt to your needs.

how would you go forward with this?

theres a few approaches...
(listed in least efficient, but easier to implement order)

a) you could modify this, to have single_alloc, single_set , single_get axoloti objects, with inlets and outlets - so basically like the table object.

b) create custom object(s) using singleton
so actually build your functionality into some more high level objects, and just use these in their implementation

c) create custom object(s) using technique
really the idea of this is to demonstrate the technique of using singletons,
the approach could be used to handle much more complex data structures that are relevant to your problem space.

id personally go with (c), but you might find this a bit hard to do at this stage...so perhaps start with (a) and move on.

I hope this is helpful... sorry I don't really have the time to do more,
if your new to C/C++ I recommend you go search on the internet for a tutorial,
Im sure, there are some excellent ones around that can do a much better job of teaching you the basics than I can over a forum

tip: whilst its tempting to just start cut n' pasting code around, its not a good idea.
unlike visual coding , C++ has plenty of potential to bite you in the a** if you do this,
and frankly it'll get pretty frustrating if you don't have a little grounding int c/c++.

note: if you use these objects thousands of times in the patch, you will probably want to add attribute((noinline)) after the get/set methods in singleton.h ,
this reduces performance (so dont do it unless you need too), but means it generates less code.

answered on your other topic here

please can I ask that next time you do not cross-post...
its unnecessary to have multiple topics, and creates noise on the forum, and it will not get you a faster response

also, please ensure you search the forum... axoloti has been around a good amount of time, and we have helped a lot of new users, so there is a ton of good information on the forum already.

I think of this as the Arduino syndrome.

This is incredible! Thanks for taking the time to show me this...
I'll dive right in...

Also:

Actually it does work: since this way i didn't have to bury my table/reads two patcher levels deep. It works just fine accessing tables from within the mpe voice patch, just not two levels down. However, it is still inefficient. I've got 16 destinations working with this set up, but I would like to get more going.

I'll look into the singleton technique. I didn't know where to start, and this is an excellent start.

THANK YOU TECHNOBEAR!

damn... it was made with version 2.0.0.... i can't open it.

Today I updated the Axoloti bord firmware to 2.0.

But when I try to go live with a patch, I get this error. I am assuming it is related to use of tables?

Generate code complete
compiling /Users/jakobskouborg/Documents/axoloti-2.0.0/build/xpatch.cpp
/Users/jakobskouborg/Documents/axoloti-2.0.0/build/xpatch.cpp: In member function 'int rootc::instanceTable::instanceAudio::table_load()':
/Users/jakobskouborg/Documents/axoloti-2.0.0/build/xpatch.cpp:334:33: error: 'fbuff' was not declared in this scope
if( rem_sz > sizeof(fbuff) )
^~~~~
/Users/jakobskouborg/Documents/axoloti-2.0.0/build/xpatch.cpp: In member function 'void rootc::instanceTable::instanceAudio::dsp(rootc::instanceTable*, int32_t, bool, int32_t&, int32_t&, int32_t&, int32_t&, char*&, int32_t&)':
/Users/jakobskouborg/Documents/axoloti-2.0.0/build/xpatch.cpp:495:15: error: 'codec_clearbuffer' was not declared in this scope
codec_clearbuffer();
^~~~~~~~~~~~~~~~~
make: *** [/Users/jakobskouborg/Documents/axoloti-2.0.0/build/xpatch.o] Error 1
Compiling patch failed

What do I need to do to fix this issue?

Also experiencing some issue when using the midi/out/clock. If you set a tempo and turn the midi clock on, you get this error in the console:

Screen Shot 2019-12-20 at 16.46.19.png680x705 64.2 KB

It just keeps spitting out that message, "midi output overflow" until I go un-live again. Not sure if it's a big issue, the patch seems to work. I have not tried sending the midi clock out to another device, so not sure if it actually affects the midi clock out.

PS. If admin wants to move the trouble shooting posts I just made to another thread, I am fine with that

i think we will need to see the patch ...
ideally you say which (factory) object is causing it.

have you setup the output port to a device?
is that device working? e.g. with note on/off...

at a, completely, random guess id say the output device is not pulling the clock messages off the midi queue.
(the overflow message means for some reason the patch is creating midi message faster than they are being consumed)

btw: after some initially playing I will stay there are a number of things that have changed that are not listed,
so you may find custom objects may not work...particularly ones that work at the lower levels of the firmware.

(e.g. my push object no longer works as ui.h no longer exists/or is inaccessible ... i also don't know at this stage if the parameter representation in firmware has changed...so would need updating to reflect this)

so I guess we should re-iterate :

and also there are some really big changes under the covers, that may have impact on things

yeah, as i said, im focusing on 2.0.0 now... its better for me to be testing, and helping improve that... than focusing on 1.0.12. (not saying that's true for you/new users - as its not 100% stable at the moment)

I'll see if i can back port this back to 1.0.12

Here is a simplification of it. Problem is still there, so it is for sure related to table use:

Tets new Axo 2 .axp (15.1 KB)

(You have to save the table combo object as an object. It's based on table/alloc 16b sdram, so it needs to be saved).

These are not factory objects, they are embedded and edited objects. Pretty much every patch I make uses embedded/edited objects.

I was just hoping that maybe I could change a line or two of code to get it working

Check the picture for the settings I made. I also checked the midi routing, but it seems like I can't do anything in there. I can't do any settings.

Ah yes of course. I just want to tell what I am experiencing here, maybe it can be used for troubleshooting.

I am not complaining, just letting you guys know, who knows what to do about it

I still have another bord I run the old version on

oh that would be great, if you have time.

I've tried installing 2.0.0 just to take a look at it, but nothing is compiling. I'm getting this:

Generate code complete
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
Compiling patch failed

dont use 2.0 yet... its going to create too much confusion if users new to axoloti start using it,
as it'll be hard to know if something they say is 'user error' or a new bug.

ok, Ive done a 1.0.12 version

this is actually a little more logical anyway, as it has 3 objects
single/create, single/set, single/get

note: I repeat, the set/get are 'hardcoded', im not trying to create something useful here, rather demonstrate the technique.. I leave it to the 'reader' to make them useful