Code execution question

[jaffasplaffa]

Hey

I have a question about how efficient code is in the different "code windows" in Axoloti. I mean, local/init/k-rate/sample_rate windows.

I was working on a mixer where I used a lot of int32_t's from local code. Then I tried, just for the fun one if moving them to k-rate window and the DSP usage dropped 2-3%. To me this seems like it is more efficient to call int32_t(if possible of course) from k-rate code than from local code.

I know local code is only executed once and krate is update all the time. Is the reason why local code is more "expensive" that it run everything in local section form the start, so basically everything is active? Where the krate is only "activated" when used?

Was just wondering about this. Cause if it is more effective then i might as well put more there than in the local code(when possible of course).

[thetechnobear]

ive moved this from the replies to the user guide, lets keep questions away from that topic, its better to have specific questions in the dedicated category here.

ok, on to the question...

I know local code is only executed once and krate is update all the time. Is the reason why local code is more "expensive" that it run everything in local section form the start, so basically everything is active? Where the krate is only "activated" when used?

ok, you need to be more precise in your language here...
(I know your beginning, but its important to use the right terms, otherwise its really unclear what your talking about)

in axo objects we only have local data ... and init code... I'm guessing your referring to this? as opposed to k-rate and s-rate code.

you also are solely talking about int32_t which is a data type, and is a declaration , rather than 'code' par se... BUT depending upon what your doing could possible invoke initialisation code.

I know local code is only executed once and krate is update all the time. Is the reason why local code is more "expensive" that it run everything in local section form the start, so basically everything is active? Where the krate is only "activated" when used?

this is where the lack of clarity bites I cant really determine your question, and basically if I guess at it (e.g. init code , or local data initialisation is more expensive than k-rate) then your premise is just wrong. it may be perhaps the way you are measuring is wrong or that you are missing something like compiler optimisation kicking into play.
but init code is only executed once, k-rate is executed at 3khz....
I don't know what you mean by 'k-rate is only activated when used' , its always used, its called every k-rate cycle... (of course, your code might have conditional code, but that's your business )

the only other thing to be aware is vars declared in k-rate code, are locals on the stack, so initialised every time you call the k-rate dsp function, though depending on what you do, some of this can be compiler optimised.

a last thing... as your learning C/C++ if you want to understand properly what the books are teaching you about variable scope/initialisation relates to Axoloti objects, you will need to look at the xpatch.cpp that is generated... since this is the only way to see the scope of vars, and the dsp code.
... the way to do this is to create a trivial patch with just one or two objects, and then look at the code generated, once your understand this, you'll have a much better idea of whats going on.
(you don't need to do this to code objects, but frankly any discussion of 'optimisation' is going to be pretty difficult without this underlying knowledge)

[jaffasplaffa]

From Sputnki description of the diffrent code windows or dropdown menues. SOrry I dont know what you call them. There are 4 of them where you can put code in:

Coding axoloti objects

Local data

This section of the code is executed once, before inlets, outlets, params and displays are declared. You can use this section to declare variables, constants, functions etc. You can't access i/o (because i/o does still not exist, at this point), but you can access attributes.Example: table/alloc 16b

Again I just want to say I am not postulating anything or saying anything is bad.. This is just a question about what is mot efficient. Allthough now that I think of it, it could also just have been Axoloti just not showing the right DSP usage for a short second.. I have seen that a few times...

Anyway I will try to explain it a bit better... NOW after I took a course last night I will try to use th right language... Form the c++ course I think I understood that an "int" is a variable and I am assuming in32_t is the same? It wasnt mentioned in the course.

Everythin beneath here is from Axolotis editor not a code progam... So the terms I use is from the Axolotis own object editor;

What I had done that day was puttting_ in local code like this:
int32_t SUMCHANNELS;

And then in S-rate menu do this:
SUMCHANNELS = ch1+ch2+ch3;

So first declare the variable in local code and the give it a function in s-rate code.

But instead i just put this in the srate and NOTHING in local code:
int32_t SUMCHANNELS = ch1+ch2+ch3;

Both worked;
And my question was; is there any difference in efficiency in those 2 ways?

Sorry, I was not clear enough. It sounded like I was saying that doing the k-rate code was more efficient than doing it in local code. It was a question about what is more efficient. I dont know anything about it, but wanted to find out.

I don't know what you mean by 'k-rate is only activated when used' , its always used, its called every k-rate cycle... (of course, your code might have conditional code, but that's your business )

Now that I look at that statement, I understand that you dont understand it. It was just a thought; that all local data is processed when going live with a patch, is true, from what i understand from Sputnkis code thread. But if I put the int32_ X in s-rate it was only processed when it variable was used... But I understand it is not how it works. And that thought was based on what I saw.

When I moved some of the int32_t's to srate code I saw the DSP meter drop... BUT When using Axolotis editor and working on several objects in the same patch, you dont always get 100 % right feedback. SOmetimes you have to save the patch and close it and open again and then everything works as supposed. Especailly when working on more complicated stuff. And now that I think of it, I think maybe this was what happened.

(you don't need to do this to code objects, but frankly any discussion of 'optimisation' is going to be pretty difficult without this underlying knowledge)

True and that is why I am taking the courses... I have made around 50 objects from mixers to samplers to compressors to noise gates, to wavetable morph stuff... All in the last month, so I can build things even with out using the right langauge. BUt I am certain that everything can be done ALOT more efficient than what I am capable fo right now..... But to understand everything I do need to take a few steps back and take them, understanding the basics... And I am trying. So please bare with me a little while more. It is not my profession.

But I have prcaticed a bit by finding a lot of similar code onhttp://stackoverflow.com/ and tried implementing it into Axoloti. Many of the things worked and some didnt. Tried new random functions I hadnt seen used in Axolti the rand()... Axoloti uses the ()RANDOMnumberGENERATOR() version... And I understand why.. The rand() was really not random at low values... it set to a value between 1-3 i think it was, it just send out a steady 2... Not usable.. But I found some formulas to round any number into nearest power of 2 number.. These are really useful for many things. Stack overflow is nice in general for sourcing things to practice on

Allthough I am looking into signing up for a new education, Datalogi, which is very much related. Teaches you algorithms and so on. I hope I can start next year, I just need to take math level A first then I can go.

Right now I am working in public school and really freaking tired of being a puppet of the schoolsystem. They expect more and more from us and gives us less time to do out job. Working with kids this is just a lethal cocktail, that WILL end like a massacre... And I am not gonna wait around for it. To me it is just too much. Bascially they want the energy of a 20 year old, but with the knowledge of a 70 old and expect you to run like crazy.... So I dont want to work there anymore and I will quit my job soon. And start preparing for going to datalogi university next year.

a last thing... as your learning C/C++ if you want to understand properly what the books are teaching you about variable scope/initialisation relates to Axoloti objects, you will need to look at the xpatch.cpp that is generated... since this is the only way to see the scope of vars, and the dsp code.

Yeah maybe I will get back to you on that I think I need to do the first many courses before I dig into more

[thetechnobear]

yeah, learning the 'language' of programming, C, DSP all at once is tricky, but unfortunately programming is about precision, so its pretty vital ... you'll get there, the more you do/read the clearer it becomes.
also bare in mind Axoloti is deliberately hiding 'non essential' details, so that can for some subjects add more complication ... of course, for other topics, it simplifies things immensely.

ok, so local data , is a declarative section, its a good idea to get really clear in C the distinction between declaration and code.

for the purpose you are discussing the difference is, do you have to allocate the int32_t (yes its a type too, you wont find in a general C book) when allocating the object (which more correctly is a class, and your defining in local data) or when the function is called (k/s-rate). really neither is 'quicker' as the amount of memory is calculate upfront by the compiler... and even this is not quite the case, since the dsp functions are 'attempted' to be in-lined.

from a 'theoretically' (i.e. your book) from a C standpoint there is no difference, the code should execute at the same speed. (or the different would be ridiculously small)

BUT... if it is quicker, then I would say its down to the compilers optimizer.

what could happen, in the s-rate example, is that the optimizer spots that the variable is only used in one place, and so is able to allocate a register to hold the result, rather than use a memory location (slower).
(note: I say could, because theoretically the optimizer could (shoud?) be intelligent enough to do the same in both scenarios, only checking the assembly output can tell you the truth)

so here is your problem... understanding optimizers is very difficult, even for very experienced programmers... often what you think is going to happen doesn't and its quite possible to try to optimize for a compiler and make it worst! ... or even when a new version of the compiler is introduced, and your optimisation is now invalid.
( to optimize really well, you have to really a grounding in assembly, compiler technology, optimizers)

so how do most programmers 'get around this'...
well the optimizers are really very intelligent (and constantly improving) so generally you don't care about them... in most programming contexts this is enough, and there are more gains to be made in your own algorithms than squeezing the optimizer.

but my advice to programmers is simple, make your code express your intent as closely as possible, in as simple way as possible... the hope is, if its easy to understand, and in a 'common approach' then the optimizer will be more likely to recognise.

so in your example the reason you should have been declaring in s-rate and not local data is because that is where you need the data... you don't need it in a broader context, and its generally good programming practice to keep the 'scope' of variables as limited as possible (for a variety of reasons, that you can read up on )

reading this back, this seems like a really convoluted reply, but unfortunately, once you get into optimizers/in-lining, its really a whole new level... one that many C programmers with years of experience don't even venture into.
(but of course, are quite relevant to DSP programming on a CPU with very limited resources... if you did this on a PC, say for aVST, , you'd likely 'get away' with not hearing about any of this stuff)

[jaffasplaffa]

in as simple way as possible

Yes this is the core... Well, first I have to get things working and I think I got that now, so now I will go into the details of everything. Goal seems always to be keep it simple to "keep it clean". I can already now see that a lot fo the first objects I made can be optimized. I guess this is just a process of understanding it better.

So now I just think I need to get the basics and then all the compiler stuff, I can go into later. Like you say it is too complicated. But I got Xcode installed and some videos to go along that show how to work with c++ in Xcode. On top of that the tutorial from https://www.sololearn.com/Play/CPlusPlus

[thetechnobear]

yeah, concentrate on functionality.

as for the optimizer, perhaps read the wiki entry briefly to know what it is, and the kind of things its does (don't worry about the details, this varies by compiler anyway) ... its useful to know of its existence but honestly id treat it as 'out of scope'.

one last thought, be careful of a programming pitfall called 'premature optimisation' , basically trying to optimize code too soon in the dev process, its very easy to do. In this context, I refer to this, as not taking a 'pattern' you think will optimise code and generally using it 'out of habit' , as in some contexts it may actually reduce performance. (optimisation depends on a lot of different factors)

that said, in this particular example - its good programming practice to declare variables in as limited scope as possible... so the declaring the in k/s-rate vars is the 'right thing to do' anyway.

there are quite a few good books on recommend programming guideless/practices, worth reading once you have a firm grip of C/C++, they can really help beginners not fall into very common traps and bad habits.
(I don't really have any up to date recommendations, it was a long time ago for me)

[jaffasplaffa]

Thanks I will check out the wiki entry. FOr now I am mostly doing the steps to get osm ecool objects working... Latest is this sequencer that loads presets from SD-card But still very unstable. I have to find a way to store many presets in one table. But for that I would also have to be able to write to specific locations in the table. the sequencer has 4 presets and they are stored in the array:

PExParameterChange(&parent->PExch[PARAM_INDEX_attr_legal_name_p1],array[0],0xFFFD);
PExParameterChange(&parent->PExch[PARAM_INDEX_attr_legal_name_p2],array[1],0xFFFD);
PExParameterChange(&parent->PExch[PARAM_INDEX_attr_legal_name_p3],array[2],0xFFFD);
PExParameterChange(&parent->PExch[PARAM_INDEX_attr_legal_name_p4],array[3],0xFFFD);

array[0]=param_p1;
array[1]=param_p2;
array[2]=param_p3;
array[3]=param_p4;

4 presets = 4 samples(or places in the array)

so 64 samples is 4 * 16 = 16 presets

In the array:
preset 1 is 0-3
preset 2 is 4-7
preset 3 is 8-11

Have been trying to do this allday and get it working but with no luck. I did get an advice how to do it, which I think I have to read 10 times more and then try again in a few days.. And I think fo rthat method it is neede to store ALL preset to the table at once. I would like to make one preset, save it to array 0-3 then dial in next preset, then save it to 4-7... But this makes my brain hurt right now I guess it is a kind of overdub, but with data instead of audio.

Sequencer with preset, muahahaaa