Sorry in advance for my english. I hope, it will be understandable...

I've been working a lot with genexpr these days...

Calculations and variable evaluations seem to be done for each sample, as soon as Params are involved, whether they are changing or not...

As soon as you put your variables in "if" blocks with a change in Param value as a trigger for the the block to be evaluated, it works and your CPU is happy...

The drawback is : for this to work, you must declare your variables as Histories for data persistence over time...

I think I read somewhere in the forum that the compiler was already optimized for this purpose (that is, only evaluating variables on data change).

Could it be possible for the compiler to do the stuff for us (I know memory is cheap but, hey... I have to ask)??

Anyway, I'd appreciate clarifications on this matter.

Sorry in advance for my english. I hope, it will be understandable...
So...
I've been working a lot with genexpr these days...
Calculations and variable evaluations seem to be done for each sample, as soon as Params are involved, whether they are changing or not...
As soon as you put your variables in "if" blocks with a change in Param value  as a trigger for the the block to be evaluated, it works and your CPU is happy...
The drawback is : for this to work, you must declare your variables as Histories for data persistence over time...

I think I read somewhere in the forum that the compiler was already optimized for this purpose (that is, only evaluating variables on data change).
Could it be possible for the compiler to do the stuff for us  (I know memory is cheap but, hey... I have to ask)??
Anyway, I'd appreciate clarifications on this matter.

Thx!
version : Max 7.0.6 (32 bit)
system win 7


calculations-in-gen-and-optimizations

Bump from a while ago. I'm also curious how gen~ handles per sample vs per vector processing. I found this in the gen~ references, but I'm curious if there are other values/variables that can be declared as lower priority.

The compilation process for gen~ Gen patchers and GenExprs includes an optimization that takes into account the update rate of each operator, so that any calculations that do not need to occur at sample-rate (such as arithmetic on the outputs of param operators) instead process at a slower ‘control-rate’ for efficiency.

Bump from a while ago. I'm also curious how gen~ handles per sample vs per vector processing.  I found this in the gen~ references, but I'm curious if there are other values/variables that can be declared as lower priority. 

only place where it’s per-vector is at the ‘param’ level - params come from event-messages in the outside max-world, similar to how you lock the event-rate to the start of each audio-vector using ‘in audio interrupt’ and ‘overdrive’ settings within the AudioOptions of Max-Proper, in order to sync/lock the event-rate to the audio-rate in a certain way, ’params’ within gen~ are automatically setup to work in this way. the rest of gen~ is sample-by-sample processing.

someone can correct me if wrong, but since gen~ is all audio, there’s nothing within gen~ that’s actually lower-priority, it’s all the same priority within gen~(the params poll from the outside at a different ‘rate’ not ‘priority’; you could say that because events come from the outside world at a different priority, within this overall chain utilizing gen~ within it, gen~ receives the message with a lower priority, but within gen~ the calculation is sample-by-sample so the overall priority even in parts of the chain which are not required to be sample-by-sample will still run at the same priority - priority is more often a term used to refer to threading, within gen~ i’m pretty sure everything runs in the same audio-thread).

if you have a param connected to other ops that don’t require a sample-by-sample update(for example, connect a param, to ops that are all in a chain but only receiving input from the param like so: 

[param]->[* 2]->[/ samplerate]->…[the rest of your gen~ patch which actually needs to run sample-by-sample]…)… everything up to the point that does require a sample-by-sample update will only get polled/calculated at vector-rate(just a reminder: ‘control-rate’ can be thought of as the same as ‘vector-rate’; in the example above: [param]->[* 2]->[/ samplerate] all get calculated/polled at the ‘control-rate’ mentioned in that passage from the docs you quoted. the rest of it after that, will be calculated sample-by-sample… the reason is the [* 2] doesn’t require any sample-rate level of changing data, neither does the [/ samplerate] op, they both only need to update when the param feeding them input updates(or when the entire system changes by editing or setting a different sample-rate)… i’m sure they’re all still in the same thread/priority though because otherwise, the rest of the gen~ patch will suffer from timing/sync probs if data must be shifted to a different thread at this late point… i could be wrong: now that i think about it, ‘priority‘/‘threading’ is not really spoken about in the docs i’ve read so far - i think that’s because gen~ is all audio-thread only(same priority throughout))

the only other area of confusion i imagine someone might have is with History ops but where you might send the history op a message from outside(hey Cycling74, i’m pretty good at this! y’all should hire me for help on anticipating what will confuse users in your help docs, haha! XD)

most people probably won’t want to send a History op a message from outside… this is more for resetting a specific History(you can also send the ‘reset’ message from outside, so you don’t really need this history-specific messaging in a user-specific situation, it’s more for debugging a specific part of your chain with that ’history’ op in it) but if you have a history op named ‘gimme’, and you sent the message from Max-proper “gimme $1” then this message is an event message coming in at ‘control-rate’ from Max, therefore the History op within would be updated at ‘control-rate’ technically speaking, but since history ops have to be ready to process other input within gen~ at sample-rate, they will still calculate/poll for input at sample-rate.

and if you’re wondering how i come up with some of this as it’s not that specific in the docs, it’s because this is similar to how discussion of the AudioOptions settings(‘overdrive’ and ‘in audio interrupt’) has worked(described on these forums for years, eventually also further elaborated in the docs), and then i’ve also programmed a couple externals in C for MSP, so i can see the gen~ pattern is very similar(the ‘control-rate’ messaging to an MSP object is handled differently than the sample-rate perform-method and you can see when you program an external on your own how these are divided among threads(the ‘perform-method’ written in C code within an MSP external is like gen~, the rest of the MSP external is a bit more like Max in general), etc.), and finally! because this book helps alot:

(it doesn’t go into much more detail than what i did, but it describes it with much better, more technically-proficient semantics, haha, and then it goes into more on what will make gen~ most efficient for you which is often to be found in some basic design at the core of your algorithms which is different from this data-formatting/routing stuff, but this stuff is still important to know, no doubt! :) )

(damn, i rambled on and on and on and on and on and on here… :D… i’m not even sure i cleared anything up… ah well, makes more sense to me now at least, hahahaha XD)

also curious how gen~ handles per sample vs per vector processing

curious if there are other values/variables that can be declared as lower priority

someone can correct me if wrong, but since gen~ is all audio, there’s nothing within gen~ that’s actually lower-priority, it’s all the same priority within gen~(the params poll from the outside at a different ‘rate’ not ‘priority’; you could say that because events come from the outside world at a different priority, within this overall chain utilizing gen~ within it, gen~ receives the message with a lower priority, but within gen~ the calculation is sample-by-sample so the overall priority even in parts of the chain which are not required to be sample-by-sample will still run at the same priority - priority is more often a term used to refer to threading, within gen~ i’m pretty sure everything runs in the same audio-thread).
if you have a param connected to other ops that don’t require a sample-by-sample update(for example, connect a param, to ops that are all in a chain but only receiving input from the param like so: 
[param]->[* 2]->[/ samplerate]->…[the rest of your gen~ patch which actually needs to run sample-by-sample]…)… everything up to the point that does require a sample-by-sample update will only get polled/calculated at vector-rate(just a reminder: ‘control-rate’ can be thought of as the same as ‘vector-rate’; in the example above: [param]->[* 2]->[/ samplerate] all get calculated/polled at the ‘control-rate’ mentioned in that passage from the docs you quoted. the rest of it after that, will be calculated sample-by-sample… the reason is the [* 2] doesn’t require any sample-rate level of changing data, neither does the [/ samplerate] op, they both only need to update when the param feeding them input updates(or when the entire system changes by editing or setting a different sample-rate)… i’m sure they’re all still in the same thread/priority though because otherwise, the rest of the gen~ patch will suffer from timing/sync probs if data must be shifted to a different thread at this late point… i could be wrong: now that i think about it, ‘priority‘/‘threading’ is not really spoken about in the docs i’ve read so far - i think that’s because gen~ is all audio-thread only(same priority throughout))

the only other area of confusion i imagine someone might have is with History ops but where you might send the history op a message from outside(hey Cycling74, i’m pretty good at this! y’all should hire me for help on anticipating what will confuse users in your help docs, haha! XD)
most people probably won’t want to send a History op a message from outside… this is more for resetting a specific History(you can also send the ‘reset’ message from outside, so you don’t really need this history-specific messaging in a user-specific situation, it’s more for debugging a specific part of your chain with that ’history’ op in it) but if you have a history op named ‘gimme’, and you sent the message from Max-proper “gimme $1” then this message is an event message coming in at ‘control-rate’ from Max, therefore the History op within would be updated at ‘control-rate’ technically speaking, but since history ops have to be ready to process other input within gen~ at sample-rate, they will still calculate/poll for input at sample-rate.

and if you’re wondering how i come up with some of this as it’s not that specific in the docs, it’s because this is similar to how discussion of the AudioOptions settings(‘overdrive’ and ‘in audio interrupt’) has worked(described on these forums for years, eventually also further elaborated in the docs), and then i’ve also programmed a couple externals in C for MSP, so i can see the gen~ pattern is very similar(the ‘control-rate’ messaging to an MSP object is handled differently than the sample-rate perform-method and you can see when you program an external on your own how these are divided among threads(the ‘perform-method’ written in C code within an MSP external is like gen~, the rest of the MSP external is a bit more like Max in general), etc.), and finally! because this book helps alot:
https://cycling74.com/books/go 
(it doesn’t go into much more detail than what i did, but it describes it with much better, more technically-proficient semantics, haha, and then it goes into more on what will make gen~ most efficient for you which is often to be found in some basic design at the core of your algorithms which is different from this data-formatting/routing stuff, but this stuff is still important to know, no doubt! :) )


(damn, i rambled on and on and on and on and on and on here… :D… i’m not even sure i cleared anything up… ah well, makes more sense to me now at least, hahahaha XD)

Calculations in gen and optimizations