heck

just having a question sitting on my neck for a long, so. Basically

i make pretty extensive use of the trigger object. Whenever i have more than one cable connected to an outlet, and i do care about the sequence, i NEVER rely on right-to-left but instead i use a trigger object.

Just my question, is this practice less performant than depending on the left-to-right? Does anyone see a problem with this. Or maybe is anyone doing it the same way?

Ey geeks,
just having a question sitting on my neck for a long, so. Basically
i make pretty extensive use of the trigger object. Whenever i have more than one cable connected to an outlet, and i do care about the sequence, i NEVER rely on right-to-left but instead i use a trigger object.

Just my question, is this practice less performant than depending on the left-to-right? Does anyone see a problem with this. Or maybe is anyone doing it the same way?


right-to-left-vs-trigger-object

I use [trigger] this all the time and consider it good practise. If you return to a patch at a later date and edit it, moving objects around in the process, you can easily break some of this r-to-l ordering which could cause problems that are quite hard to find. Using [trigger] means this can never happen just by changing the layout of your patch, keep it up and you could be saving yourself quite a few headaches in the future.

Just my question, is this practice less performant than depending on the left-to-right?

Do you mean in terms of cpu? I was going to say: no difference, but this patch shows some interesting results. Seems a trigger is more cpu intensive then a square root. Anyhow, definitely consider it good practice.

Quote:Just my question, is this practice less performant than depending on the left-to-right?

thanks for explaining my motivation for extensive [trigger] usage. You steal the words out my mouth

if you use [trigger] (since it is an external object), i am almost sure it's using more CPU-cycles, than it would using r-to-l order, because this is kind of a "max-enginge" instruction, i assume. (Them mem-footprint of the max-enginge running the patch will most definitely be bigger as well, but this should be insignificantly minimal)

@Cycling74: if there is no doc you could point us to, would you mind giving a quick comment?

@Johan, sorry stil on max 4.6. But regarding the [sqrt] vs. [t] i would not be surprised if this really would be the case, i mean i have no idea what the [trigger] internally's doing.

to: thereishopeforus@hotmail.com
thanks for explaining my motivation for extensive [trigger] usage. You steal the words out my mouth 

But:
if you use [trigger] (since it is an external object), i am almost sure it's using more CPU-cycles, than it would using r-to-l order, because this is kind of a "max-enginge" instruction, i assume. (Them mem-footprint of the max-enginge running the patch will most definitely be bigger as well, but this should be insignificantly minimal)

Basically, don't worry about cycles until your patch starts running into performance issues.

Take that advice with some salt: an experienced Max patcher will, indeed, have preferences for certain techniques based on performance. But as a beginner, your first concern should be clean, maintainable solutions to problems. 99% of the time a few cycles here or there are not going to make an overall difference.

[trigger] is considered best practice because it makes your patches resilient against changes in topography. If you rely on r2l triggering and then sometime later make a change to your patch layout, it's all too easy to break the patch. That sucks.

@Johan: I haven't tried your patch, but the result you reports only surprise me a bit. At most. At machine level, Jump and Branch instructions are typically expensive, which translates to if statements (in C & Co.) being expensive. Depending on how trigger is implemented, there might be a lot of ifs in there. Square root is fairly expensive, but as frequently-called library function the implementation is probably highly optimized for performance.

[trigger] is considered best practice because it makes your patches resilient against changes in topography. If you rely on r2l triggering and then sometime later make a change to your patch layout, it's all too easy to break the patch. That sucks. 

@Johan: I haven't tried your patch, but the result you reports only surprise me a bit. At most. At machine level, Jump and Branch instructions are typically expensive, which translates to if statements (in C & Co.) being expensive. Depending on how trigger is implemented, there might be a lot of ifs in there. Square root is fairly expensive, but as frequently-called library function the implementation is probably highly optimized for performance.


The [t i i] appears to be even slightly more expensive then a [t f f]. Would that be because of an extra if/then, i.e. int coming after float? But indeed, I'd worry more about proper patching then a bit of performance.

Quote:@Johan: I haven't tried your patch, but the result you reports only surprise me a bit. At most. At machine level, Jump and Branch instructions are typically expensive, which translates to if statements (in C & Co.) being expensive. Depending on how trigger is implemented, there might be a lot of ifs in there. Square root is fairly expensive, but as frequently-called library function the implementation is probably highly optimized for performance.

something coming from metro while max is in overdrive 

definetly makes trigger noticeable. but like you said,

Quote:
Do you mean in terms of cpu? I was going to say: no difference, but this patch shows some interesting results. Seems a trigger is more cpu intensive then a square root. Anyhow, definitely consider it good practice.

something coming from metro while max is in overdrive 
definetly makes trigger noticeable. but like you said,
it is still good practice.


I tell i am always using [t] to control sequence.

You explained my motivation to not eat a soup with a fork.

Thank you for sharing you religious beliefs about performance impacts, yes in terms of CPU. oh god...

Thanks Peter, you assume i am a beginner... hmm. ok

In innerloops i do care about every _single_ cycle. yes i do.

then peter explained the "soup and fork problem" again, even though i really never, never ever considered to eat a soup with a fork.

something coming from metro while max is in overdrive

Please dont take it too personal, i really expect you to hate me by now, but one thing you have to admit:

Not one qualified and competent statement about the performance diff. between max internal r-to-l versus [t]-based sequencing.

So please, for the future, answer my threads is you have information.

If it stays empty. The information is missing.

after having identified missing information, we go to cycling74 and RFC on the missing part.

This way we can gather valuable information in a structured way.

We're not at philosohy, we are at software engineering.

There are no "mysteriums" or irregularities. There is only true or false. everything else is undefined, and is the worst.

I dont hope the whole board culture is kind of "what is your misterical belief, mine is that... blabla, oh really life is so exciting, it seems to be soo complex but we seem to have figured it out, we so great" like.

That's what you get in microsoft-forums. 

This is the MAX-community, dont let the closed source obsess you with the wildest theses.

In the end cycling owes us the missing information. They want us to buy the product which is closed source, and therefore needs to be documented in another way.

We have to be organized and professional.

I apologize for any potential disappointment. 

I hope not to catch myself doing the same things i just convicted. And if it would be the case, i hope you will tell me.

I tell i am always using [t] to control sequence.
i ask:
Just my question, is this practice less performant than depending on the left-to-right? 

thereishopeforus@hotmail.com
Thank you.
You explained my motivation to not eat a soup with a fork.

johan,
Thank you for sharing you religious beliefs about performance impacts, yes in terms of CPU. oh god...

Peter Castine wrote:
Take that advice with some salt: an experienced Max patcher will, indeed, have preferences for certain techniques based on performance. But as a beginner, your first concern should be clean, maintainable solutions to problems. 99% of the time a few cycles here or there are not going to make an overall difference.

Thanks Peter, you assume i am a beginner... hmm. ok
In innerloops i do care about every _single_ cycle. yes i do.

Roman Thilenius:
something coming from metro while max is in overdrive
definetly makes trigger noticeable. 

metro+overdrive = trigger noticeable
great statement

Half-knowledge is worse than none.
So please, for the future, answer my threads is you have information.

If it stays empty. The information is missing.
after having identified missing information, we go to cycling74  and RFC on the missing part.

We're not at philosohy, we are at software engineering.
There are no "mysteriums" or irregularities. There is only true or false. everything else is undefined, and is the worst.

That's what you get in microsoft-forums. 
This is the MAX-community, dont let the closed source obsess you with the wildest theses. 

Let's share facts & knowledge. 
Not beliefs.
In the end cycling owes us the missing information. They want us to buy the product which is closed source, and therefore needs to be documented in another way.

I apologize for any potential disappointment. 
But i hope you are getting my point.

Maybe you are not the center of the universe. It is possible that other people might currently be too busy to drop what they are doing and answer a question because you want them to.

I've read some very over-dramatic posts about unimportant things on this forum but this probably takes the cake. The fact that cycling 74 staff hasn't personally responded to you ON THE SAME DAY of your post does not mean a call for revolution is necessary.

Get over yourself and use the trigger object.

Maybe you are not the center of the universe. It is possible that other people might currently be too busy to drop what they are doing and answer a question because you want them to. 

I've read some very over-dramatic posts about unimportant things on this forum but this probably takes the cake. The fact that cycling 74 staff hasn't personally responded to you ON THE SAME DAY of your post does not mean a call for revolution is necessary. 

Get over yourself and use the trigger object.


If it is that offending, may I ask why don't you make a patch, run the test and see by yourself ? You know how to do it, right ?

heck wrote on Mon, 08 June 2009 23:23Sorry guys,

well he is right that none of us answered "yes" or "no".

otoh, is it do hard to tell what i mean when i admit that

it should read "more noticable" than using only a connection

or a connection through an emtpy subpatch.

one of the two reasons for this result has got something 

to do with the fact that it is 2 connections. even if trigger

wouldnt do anything, using a trigger between A and B means

for more technical details a phonecall to peter castine

jln wrote on Tue, 09 June 2009 00:52
If it is that offending, may I ask why don't you make a patch, run the test and see by yourself ? You know how to do it, right ?

otoh, is it do hard to tell what i mean when i admit that
"trigger is noticable"?

it should read "more noticable" than using only a connection
or a connection through an emtpy subpatch.

one of the two reasons for this result has got something 
to do with the fact that it is 2 connections. even if trigger
wouldnt do anything, using a trigger between A and B means
2 connections instead of one.

for more technical details a phonecall to peter castine
is the way to go.

the "jump" and "branch" info was interesting, trigger is one of those objects which delays execution depending on when its messages terminate somewhere, so it's got to have some running record of sorts about what's waiting to be sent out (and have a way to be told that its messages have stopped). and since this could happen pretty much instantly or way later, depending on where it goes, it might be really tough (or not very useful) to do comparison testing with other objects like sqrt.

For the original question, though, I would imagine right-to-left saves some cycles, but there are likely many other optimizations possible elsewhere that these would be minimal in the big picture, just speculating. Also, some instructions take more scheduler cycles than others, and some get queued rather than executed immediately, don't they? Could be tough to sort all that out regarding benchmarking, but it could yield some interesting info.

Regardless, trigger is essential in my book...

the "jump" and "branch" info was interesting, trigger is one of those objects which delays execution depending on when its messages terminate somewhere, so it's got to have some running record of sorts about what's waiting to be sent out (and have a way to be told that its messages have stopped). and since this could happen pretty much instantly or way later, depending on where it goes, it might be really tough (or not very useful) to do comparison testing with other objects like sqrt. 

Regardless, trigger is essential in my book...


is this practice less performant than depending on the left-to-right?

Even more difficult then finding the answer, is finding the question.

It appears we stumbled upon a very wise person. Please tell me more about my religious beliefs.

Quote:is this practice less performant than depending on the left-to-right?

Quote:
johan,
Thank you for sharing you religious beliefs about performance impacts, yes in terms of CPU. oh god...

There are no "mysteriums" or irregularities.

As they say on teh interweb, that was so funny I spit coffee all over my keyboard.

On the the mysteries of my faith. Johan's test patch above is flawed because it seems to also test methods of converting ints to floats. (int trigger, int add, float multiply) If you change all the [+ ] boxes to [+ 0.], the answer changes a bit (see below).

sqrt is an interesting math object, because the output is always float. (I'm glad you don't have to put [sqrt 0.] to get a float answer, although that would be more "orthodox.") I bet it is more efficient because it's changing the Uzi output from int to float only once. Trigger probably does a type check and recast for each outlet.

heck wrote on Mon, 08 June 2009 14:23
We're not at philosohy, we are at software engineering.
There are no "mysteriums" or irregularities. 

On the the mysteries of my faith.  Johan's test patch above is flawed because it seems to also test methods of converting ints to floats. (int trigger, int add, float multiply)  If you change all the [+ ] boxes to [+ 0.], the answer changes a bit (see below).

Trigger probably does a type check and recast for each outlet.

trigger does a type check? now how performoid is that? 

mzed wrote on Tue, 09 June 2009 18:05
Trigger probably does a type check and recast for each outlet.

trigger does a type check? now how performoid is that? 
more or bigger than right to left order?

Seeing as you were a complete twat to everyone that was trying to help I'm going to give a nice philosophical answer...

I think the answer is probably yes, trigger object will affect performance. My reasoning for this? Experience with graphical programming - I learnt the hard way. Any component will use a) more space (filesize) and b) more CPU. Of course if you have 1 extra connection plus another component, there's going to be more going on. Firstly, Max has to remember which component you have chosen - extra memory. Second, instead of the signal going from a to b there's another component in its way. It doesn't matter what is inside that component - even if it's straight through there's going to be extra cycles.

I started out making small projects, just trying to find my feet. I got to the stage where I was confident enough to start attempting big projects. I'm not really an audio guy at heart, that might sound a bit crazy, but I prefer logic and mechanical things, then synthesis, and "real" audio comes last. I love making sequencers and big beasty synths with millions of routing options, clever GUIs and logical functions. The first time I came across CPU problems was when I tried making a very complexed sequencer. There were 120 tiles which had to interact with eachother. I chose a modular design using sub patches saved & duplicated with front-panel arguments. To start with the synthesis was just a simple sine wave with an envelope. I got the concept working, but CPU was sky high on my dual core 2.4GHz.

The sub patch I used was duplicated 120 times, and within that subpatch there were hundreds of trigger objects and expression objects. I found another way of doing the expressions, in fact I removed them all and replaced them with integer number boxes because there was only 1 calculation required on load, and expr objects appear to use CPU all the time, even when they're not receiving a trigger. This took me days, but it was worth it - the CPU dropped by about 20%! I then went through and removed the triggers. There wasn't a huge drop, but it was in the region of 2 - 3% more efficient. Imagine if my sequencer had had 1000 tiles? That would most likely be closer to 30% CPU.

So, my answer: Yes, of course any calculation will cause, well, a calculation, which takes place in the proecssor. Any object needs to make a calculation of some sort. However, depending on how big you expect your project to be, it may not be necessary to exclude such components. Since the aforementioned project I have been more careful. In sub patches that are going to be duplicated more than a few times, I'll make sure to minimise the use of triggers. 1 trigger object on its own, or even a hundred or so is going to use such a tiny tiny chunk of CPU it's not even worth worrying about, you could pretty much disregard it. When you get into a project where you have tens of thousands of them you really ought to be looking to compromise on patch layout and use the old right > left technique.

I started out making small projects, just trying to find my feet. I got to the stage where I was confident enough to start attempting big projects. I'm not really an audio guy at heart, that might sound a bit crazy, but I prefer logic and mechanical things, then synthesis, and "real" audio comes last. I love making sequencers and big beasty synths with millions of routing options, clever GUIs and logical functions. The first time I came across CPU problems was when I tried making a very complexed sequencer. There were 120 tiles which had to interact with eachother. I chose a modular design using sub patches saved & duplicated with front-panel arguments. To start with the synthesis was just a simple sine wave with an envelope. I got the concept working, but CPU was sky high on my dual core 2.4GHz. 

So, my answer: Yes, of course any calculation will cause, well, a calculation, which takes place in the proecssor. Any object needs to make a calculation of some sort. However, depending on how big you expect your project to be, it may not be necessary to exclude such components. Since the aforementioned project I have been more careful. In sub patches that are going to be duplicated more than a few times, I'll make sure to minimise the use of triggers. 1 trigger object on its own, or even a hundred or so is going to use such a tiny tiny chunk of CPU it's not even worth worrying about, you could pretty much disregard it. When you get into a project where you have tens of thousands of them you really ought to be looking to compromise on patch layout and use the old right > left technique.


Yes my post was way too offensive. So offensive that what i wanted to say had no chance to be heard.

I do appologize guys.
Yes my post was way too offensive. So offensive that what i wanted to say had no chance to be heard.

Johan's test patch above is flawed because it seems to also test methods of converting ints to floats. (int trigger, int add, float multiply) If you change all the [+ ] boxes to [+ 0.], the answer changes a bit (see below).

I had noticed also the casting problem but I think this doesn't really change the result. But I still think this "proof patch" is flawed. And I believe there is something deeper...

Have a look to the new example below. I think, the "expensiveness" of trigger is in fact not because of what trigger does but because of the MaxAPI routines to output data from a box. So why does sqrt seem less CPU expensive even though it is a much "more complex" operation than just sequencing ? Just because it has only one outlet !

I don't have in mind a simple math object which would have 2 outlets but if you do, please test and post the result to confirm (or invalidate) my guess.

heck wrote on Wed, 10 June 2009 21:30I do appologize guys.
Yes my post was way too offensive. So offensive that what i wanted to say had no chance to be heard.

This being said...
I wanted to have 1 more remark...

mzed wrote on Tue, 09 June 2009 18:05[...]
Johan's test patch above is flawed because it seems to also test methods of converting ints to floats. (int trigger, int add, float multiply)  If you change all the [+ ] boxes to [+ 0.], the answer changes a bit (see below).

Have a look to the new example below. I think, the "expensiveness" of trigger is in fact not because of what trigger does but because of the MaxAPI routines to output data from a box. So why does sqrt seem less CPU expensive even though it is a much "more complex" operation than just sequencing ? Just because it has only one outlet !
I don't have in mind a simple math object which would have 2 outlets but if you do, please test and post the result to confirm (or invalidate) my guess.

Right-to-Left vs. Trigger object