Cycling 74 » Topic: Right-to-Left vs. Trigger object

Right-to-Left vs. Trigger object

heck — Mon, 08 Jun 2009 11:09:21 +0000

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?

Re: Right-to-Left vs. Trigger object

Luke Hall — Mon, 08 Jun 2009 11:24:20 +0000

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.

Re: Right-to-Left vs. Trigger object

jvkr — Mon, 08 Jun 2009 11:37:37 +0000

Quote: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.

_
johan

– Pasted Max Patch, click to expand. –

Re: Right-to-Left vs. Trigger object

heck — Mon, 08 Jun 2009 14:03:07 +0000

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)

@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.

Thanks
HEck

Re: Right-to-Left vs. Trigger object

Peter Castine — Mon, 08 Jun 2009 18:19:14 +0000

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.

Re: Right-to-Left vs. Trigger object

jvkr — Mon, 08 Jun 2009 18:37:41 +0000

Quote:

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.

_
johan

Re: Right-to-Left vs. Trigger object

Roman Thilenius — Mon, 08 Jun 2009 18:52:49 +0000

Quote:

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

Re: Right-to-Left vs. Trigger object

heck — Mon, 08 Jun 2009 21:23:23 +0000

Sorry guys,

to resemble:

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.

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

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

metro+overdrive = trigger noticeable
great statement

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.

not one.

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.

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.

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.

We have to be organized and professional.

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

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.

Thanks
Heck

Re: Right-to-Left vs. Trigger object

Nick Inhofe — Mon, 08 Jun 2009 22:00:20 +0000

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.

Maybe its really not that important.

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.

Re: Right-to-Left vs. Trigger object

jln — Mon, 08 Jun 2009 22:52:34 +0000

heck wrote on Mon, 08 June 2009 23:23

Sorry guys,

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

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 ?

Julien

Re: Right-to-Left vs. Trigger object

Roman Thilenius — Tue, 09 Jun 2009 01:25:08 +0000

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 ?

Julien

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
“trigger is noticable”?

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

or in other words: “yes”.

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.

Re: Right-to-Left vs. Trigger object

seejayjames — Tue, 09 Jun 2009 04:34:08 +0000

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…

Re: Right-to-Left vs. Trigger object

jvkr — Tue, 09 Jun 2009 09:50:11 +0000

Quote:

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

performant…

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

Quote:

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

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

_
johan

Re: Right-to-Left vs. Trigger object

mzed — Tue, 09 Jun 2009 16:05:38 +0000

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.

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.

– Pasted Max Patch, click to expand. –

Re: Right-to-Left vs. Trigger object

Roman Thilenius — Tue, 09 Jun 2009 19:57:49 +0000

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?

and how is it fast?

can i max?

help?

-110

Re: Right-to-Left vs. Trigger object

electrogear — Wed, 10 Jun 2009 00:10:17 +0000

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.

Re: Right-to-Left vs. Trigger object

heck — Wed, 10 Jun 2009 19:30:51 +0000

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.

again, i m sorry!
Heck

Re: Right-to-Left vs. Trigger object

BenCello — Fri, 12 Jun 2009 08:59:16 +0000

Hi !

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.

again, i m sorry!
Heck

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).

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.

Cheers

BenCello

– Pasted Max Patch, click to expand. –

Copy all of the following text.Then, in Max, select New From Clipboard.

----------begin_max5_patcher----------
1361.3oc4a01bahCD9y1+Jn7w6bywJoUBteH2WtoyM9ERK24.o134x0N8+9Y
DPZHMoZMBuFSRlILFSXeziVs5Y2E957YgqJdHceXvuG7mAyl804ylYOU0Il0
74Yg2s7g0aWt2dYg2tsH+vcgKp+p62ktOMubYYVQ9esKccY8sBM3MQKBjHTc
Hp4OAen4+53MHKeaZo8NBMm71h7x7k2kZsxejtayx7kOZlkkq+TV9G6XB3Il
H1ZOwyLRwgxVqHZNa1F68uX0e+dS6cu9xJ+u6Squ0UiwkkgKBBWsL+igOdGq
P39ruXuJ3nYqN62lOu5OKHxd4o+6QS2Z3xzGrilv28aAvMD4T.cyoB+3TnY1
yAmB+Hml3fSYfKKCtMb.8yLQVpV.J6A4oyIPzkmT9E29WlHicroMmM+qVtr1
DRwM3IykRF4RZg5hqoMSx4KTWGSzmPcB03IV26IDpqY.qjmuPccLQebEkhK+
x502eX81h0+CM9DLv41GswDX7oGlTJuZ3SM.0iOyYiO6ZhdwmpKOe9qG4Eha
6bFWq2tsSyZcUO3R7xykG9RVPh8GWdmp5khwmOFsqILBGLp7EXT8qxn1MhV7
8iY4LoabU0utH2ZEffPd9V52wD0L8IRtFxj6fuqeWQSChBbowyL8zi0T8Fjn
aMzS+SZSGewDUOD9Gx5nP93efSX+iV5wC+C8Us+g.Pe8OTSX+iV5wC+iQfx8
8edW4P5zDq0OorORwoyJpjwUYeFBekVVo+EvAitpikXPomkhAEiyRwLHRQZX
m9WTEbDVDfAzuwixifpIJyXLdVnCDGWE5XHCz1+RVf5wXIKFDtAjdV7AzLxK
9vfrvJNwyxHfwWtxHr5PYYQ9OkOdobcp03iP6f8jEsI+4C4fOLnMpbXaUIBh
tZVwStOQDDmb0Jdskd5u3Ug75tPIII91GQb5Jdskc5u3UgdZJQqgY7P7pvLM
YFU6yCRuEuJhmdhWaCz1ewqhjop3UEl3amyhdCHdUUWGRe5AFb4DuxkfOoR4
qfOXBK3qkd73wMSbc24CI3ofOPMcE70xN8WvGfSSYMMLiGB9fIpTXAhdJ3CL
SOAesAZ6ufOHdpJ3Sj.dJ3CRdCH3qYSZOD7IhFcB9FZAMfw21uBvUsfFsuce
Md5JmQ6auWmnaYq8tyqSSdI129tpldBYZCv5wSJ9TUGSyNydniQ7FPFShu8b
8LT0J60DtMK+4unuV7Wc9tT29hC6V2Z01tBF78wvlz8kY41GL9mdQG81BfGu
nOksYSp86iZNycYatu33LaCHdkNoRFSPGy8xXpJqBtwTDELEwFlpRdHP3ZtC
3ESQD3opW4FFm6pdeTbxSOC3iGdhOLU8.R3FSFVwzynfWYtSxKlLDhOYc5XF
St7wqdsA4FSN8mXdtiz9cLySjV2I3ESJpXhu33IDfDuQmDTXIdEOES.Q5STm
hwVwAYjt5fQoe7SbfUsGXUlHFJrhBpDKey0ZRDHyKIPpSpLxSZJXhWwVZJA8
07tQDI2IoGqGEB0PsdDTTAKe9YHEQXpjwmndLdDlnAL9vjHZ7gIdoILlPtOn
geL4ZYGh7iImK63M7NRJT.u4YfTBii7liHhTwDi0vJhRs93ctSPwGWvqTOgg
JlXjmnH+Tva7IIk5YKL7iIm93w7iIm05iWYAVUHN6ORB+XxYM1M7iImxm3MV
.Ppd17pK.nDeB3M9DXnhI91agTFm7lvIQDwXYMHfHl6RJEwbriHmUIfcD4ZC
ElyKfhiDxb53TZ.AxaD.5Xhw8cofIAu4zQ+4bgQLQoksiRDwXduTjAv7i3Bk
zdAeBWd7Cea9+CrCF3gD
-----------end_max5_patcher-----------