Ali-i-truc

Is it possible to determine the number of bangs with a number box?

Attached there is an image of what I´m tryineg to do.

Is it possible to determine the number of bangs with a number box? 

how-to-set-the-number-of-bangs-with-a-number-box

 to [sel] which sends bangs out corresponding outlets.

This will do it.   [Uzi] fires a sequence numbers to [sel] which sends bangs out corresponding outlets.  

I have used your solution, but it seems that there are cold and hot outlets. Attached there is a summary.

If I select 3 outputs in the uzi object, the outlet 3 in the select object will act like hot compared with the other two. I want them to act equal. Any ideas?

I have used your solution, but it seems that there are cold and hot outlets. Attached there is a summary.
If I select 3 outputs in the uzi object, the outlet 3 in the select object will act like hot compared with the other two. I want them to act equal. Any ideas?

I don't know what you mean by "cold" and "hot" outlets. If you hang print objects onto your uzi and del you will see that uzi counts 1, 2, 3 and each output of the sel fires in turn.

I don't know what you're trying to accomplish with all the if objects, but I'd wager there's an easier way to do it.

I don't know what you mean by "cold" and "hot" outlets. If you hang print objects onto your uzi and del you will see that uzi counts 1, 2, 3 and each output of the sel fires in turn. 

I don't know what you're trying to accomplish with all the if objects, but I'd wager there's an easier way to do it.


Francesc, the issue is not hot/cold. It's the flow of data through your patch. Data leaves the sel object in order 1,2,3 - 

. You can confirm this, as Chris mentioned, by connecting a print object and viewing the results in the Max window.

You may be aware of this already.. but in case you're not... after data leaves the sel object, it travels through the cords giving preference to objects from 

, continuing down as far as it can go at which point, the next sel outlet sends data.

1. Click on all of the red message boxes to set the right inlet values for your [if] objects.

2. Set the two gray message boxes - the ones feeding values to the left inlets of the [if] objects - to 6 and 4 (it doesn't matter which).

3. Click on each message box sequentially. First L and R... then R and L.

Notice how results depend upon which message box was triggered last.

The way you have things configured, the message box on the right (feeding values to the left inlets of the lower [if] objects) is triggered by the 3rd outlet of sel 

 the left message box has already been triggered by the 2nd outlet of sel. That's why when you bang sel with uzi the results will always be biased for the values triggered by the 3rd outlet of sel.

(and to echo Chris' feedback.. there simply has to be easier way to do whatever you are trying to do...)

Francesc, the issue is not hot/cold.  It's the flow of data through your patch.   Data leaves the sel object in order 1,2,3 - left to right.  You can confirm this, as Chris mentioned, by connecting a print object and viewing the results in the Max window.   

You may be aware of this already.. but in case you're not... after data leaves the sel object, it travels through the cords giving preference to objects from right to left, continuing down as far as it can go at which point, the next sel outlet sends data.

1. Click on all of the red message boxes to set the right inlet values for your [if] objects.  

2. Set the two gray message boxes - the ones feeding values to the left inlets of the [if] objects - to 6 and 4 (it doesn't matter which). 

3. Click on each message box sequentially.   First L and R... then R and L.   

Notice how results depend upon which message box was triggered last. 

The way you have things configured, the message box on the right (feeding values to the left inlets of the lower [if] objects) is triggered by the 3rd outlet of sel after the left message box has already been triggered by the 2nd outlet of sel.  That's why when you bang sel with uzi the results will always be biased for the values triggered by the 3rd outlet of sel.

(and to echo Chris' feedback..  there simply has to be easier way to do whatever you are trying to do...)


indeed, if you want to build a decoder using [select] or [route], you must reverse the order so that the smallest digit is the (second) last outlet.

most objects are outputting from right to left, write that in your biological memory.

Chris, I´m a begginer at Max and for sure that there is an easier way to do that, but I don´t find it.

My target is to compare a serie of numbers (the gray messages boxes) with others (the red messages) at the same time, and output the coincidences.

Metamax, I Know that the problem comes from the number triggered in the sel object, and I understand what Chris and you say, but any clue for what I´m trying to do? Is there an object that ouputs at the same time, instead from right to left, Roman?

Thank you all again and sorry for my begginer´s questions. This is a great community, as far as I can see.

Chris, I´m a begginer at Max and for sure that there is an easier way to do that, but I don´t find it.
My target is to compare a serie of numbers (the gray messages boxes) with others (the red messages) at the same time, and output the coincidences.

Francesc, you can use the sel object for that too. The left inlet of sel is kinda like input 1 of [if] and the other inlets are like input 2 of [if]. Likewise, the outputs of [sel] are similar to the output 1 of [if].. and the right outlet functions like 'out2'.

Francesc, you can use the sel object for that too.  The left inlet of sel is kinda like input 1 of [if] and the other inlets are like input 2 of [if].   Likewise, the outputs of [sel] are similar to the output 1 of [if]..  and the right outlet functions like 'out2'.

Thank you Metamax, it seems that is the solution, let me check it this weekend.

Thank you Metamax, it seems that is the solution, let me check it this weekend.
Cute and elegant.


Yes, [sel] seems to be one of the cuter objects in Max.

I have been looking deeper into your patch, and I can´t make it work.

- First; It seems that (in your patch) it doesn´t matter which the ´values of match´ are; the select object, ouputs the coincidences between its own arguments (1 2 3) and the input values. Is that true?

- Second; If I try to introduce the right inlet in the sel object (to compare the values of match with the the input values) the sel object doesn´t show more than one outlet, Am I right?

Sorry if these questions are too obvious, and thank you.

- First; It seems that (in your patch) it doesn´t matter which the ´values of match´ are; the select object, ouputs the coincidences between its own arguments (1 2 3) and the input values. Is that true?
- Second; If I try to introduce the right inlet in the sel object (to compare the values of match with the the input values) the sel object doesn´t show more than one outlet, Am I right?

First : no, the 'values of match' do matter, even if the graphics in the box isn't updated they will change according to which value in received in an inlet.

Second, the sel object will show only one outlet if you give it only one argument (ie, one value to compare). If you want to compare that same value several times with your input, it's another story and objects you will want to use. But so far it is unclear what you want to do, could you describe more precisley what your inputs/outputs are ? Are you comparing two streams of numbers and expecting a bang each time the current value in each stream is the same ? Or are you comparing one list with one value, and expecting a bang for each element of the list that matches said value ? Or are you comparing two lists and expecting a bang for each position where the values in both lists are equal ? Or is it something else ?

Hey,
The sel object doesn't work that way.
First : no, the 'values of match' do matter, even if the graphics in the box isn't updated they will change according to which value in received in an inlet.
Second, the sel object will show only one outlet if you give it only one argument (ie, one value to compare). If you want to compare that same value several times with your input, it's another story and objects you will want to use. But so far it is unclear what you want to do, could you describe more precisley what your inputs/outputs are ? Are you comparing two streams of numbers and expecting a bang each time the current value in each stream is the same ? Or are you comparing one list with one value, and expecting a bang for each element of the list that matches said value ? Or are you comparing two lists and expecting a bang for each position where the values in both lists are equal ? Or is it something else ?


Francesc, I suppose it's not entirely clear what you mean by "compare a series of numbers at the same time, and output the coincidences."

Any numbers you input into the numbered inlets will be compared to the numbers you input to main inlet on the left. When there is a match, the corresponding outlet will send a bang. For example, if you set inlet 3 of sel to a value of '10', and then input '10' into the main inlet, outlet 3 will bang. However the same goes if you have 20 different number boxes all inputing '10' into the main inlet... you will still only get a single bang out of outlet 3.

If you need to keep each compared input/output distinct, then you will need separate lines (just as you tried to use separate if objects), but regardless, as far as I can see, the arguments of your if objects are functionally no different than sel objects.. so you would still benefit from the more compact configuration.

It's also my understanding that nothing happens at the "same time" in Max. Everything has a flow and a sequence, even if it looks like it's happening at the same time. So, given the logic of your patch, you need to decide which gray box gets banged first. It's not possible to bang them at once.

If I try to introduce the right inlet in the sel object (to compare the values of match with the the input values) the sel object doesn´t show more than one outlet, Am I right?

The sel object, as with most objects in Max, is first set with a value in the right inlet and then the calculation is triggered by a change in the left inlet. This is another example of right to left data flow... The same thing applies to [if].

I suspect that given your initial question about setting the number of bangs, your confusion about 'introducing values to the right inlet' and expecting a result.. as well as and your confusion regarding 'hot and cold' outlets - that this may all be part of a journey towards the trigger object. [trigger] or [t] is what is often used to keep data flowing in the right sequence to the right targets.

Here is an example of how a [t] object routes data flow. This is your original patch. The only difference is the initial sequence of bangs, but it appears to generate consistent results... so maybe this is what you need? Either way, given the apparent logic of your patch, you need make sure that the big button at the bottom isn't banged until the calculations are done.. otherwise, the calculations won't get pushed through.

And just to make my point... here is the same configuration using sel objects instead of [if].. Same logic.. same results..

Whatever you are trying to do, just remember that you need to think in terms of a sequence of events... not events that occur at the "same time"... and there are probably a hundred ways to do what you want.. so don't give up.

Any numbers you input into the numbered inlets will be compared to the numbers you input to main inlet on the left.  When there is a match, the corresponding outlet will send a bang.  For example, if you set inlet 3 of sel to a value of '10', and then input '10' into the main inlet, outlet 3 will bang.  However the same goes if you have 20 different number boxes all inputing '10' into the main inlet... you will still only get a single bang out of outlet 3. 

If you need to keep each compared input/output distinct, then you will need separate lines (just as you tried to use separate if objects), but regardless, as far as I can see, the arguments of your if objects are functionally no different than sel objects.. so you would still benefit from the more compact configuration.  

It's also my understanding that nothing happens at the "same time" in Max.  Everything has a flow and a sequence, even if it looks like it's happening at the same time.  So, given the logic of your patch, you need to decide which gray box gets banged first.  It's not possible to bang them at once.

The sel object, as with most objects in Max, is first set with a value in the right inlet and then the calculation is triggered by a change in the left inlet.  This is another example of right to left data flow...  The same thing applies to [if].   

I suspect that given your initial question about setting the number of bangs, your confusion about 'introducing values to the right inlet' and expecting a result.. as well as and your confusion regarding 'hot and cold' outlets - that this may all be part of a journey towards the trigger object.  [trigger] or [t] is what is often used to keep data flowing in the right sequence to the right targets.  

Here is an example of how a [t] object routes data flow.  This is your original patch.  The only difference is the initial sequence of bangs, but it appears to generate consistent results...  so maybe this is what you need?   Either way, given the apparent logic of your patch, you need make sure that the big button at the bottom isn't banged until the calculations are done.. otherwise, the calculations won't get pushed through.

And just to make my point...  here is the same configuration using sel objects instead of [if]..   Same logic.. same results..

Whatever you are trying to do, just remember that you need to think in terms of a sequence of events...  not events that occur at the "same time"... and there are probably a hundred ways to do what you want.. so don't give up.


Thanks for the reply. I´m stuck at this point for almost a week.

Ok. I don´t know why, but for me the metamax´s patch, doesn´t work. It says;

"jpatchline_completeconnection:index out of range". Maybe is it because I have Max 5?

- First; To select from a list, a desired number of elements. For example the first five elements from a serie of ten.

- Second; Outputs these five elements at the same time

- Third; Compare them with other numbers (that are not in a list) and if there are the same, output a bang.

But the problem is the mentioned issue with the reading priority, that doesn´t otputs the message from the element connected to the second sel output when three outputs are triggered at the uzi object.

Ok. I don´t know why, but for me the metamax´s patch, doesn´t work. It says;
"jpatchline_completeconnection:index out of range". Maybe is it because I have Max 5? 

- First; To select from a list, a desired number of elements. For example the first five elements from a serie of ten.
- Second; Outputs these five elements at the same time
- Third; Compare them with other numbers (that are not in a list) and if there are the same, output a bang.

I haven´t receive your answer when I submited my last reply. I will study it in a couple of hours, and I will let you know the result.

I haven´t receive your answer when I submited my last reply. I will study it in a couple of hours, and I will let you know the result.
I will really appreciate your help.


“jpatchline_completeconnection:index out of range”. Maybe is it because I have Max 5?

I don't get that error. Did you manually re-enter arguments into the sel objects? If so, they may have been insufficient for the number of existing connections. Keep in mind that the number of arguments is not the same as the number of an argument. In other words, the numbers in a sel object create new inlets/outlets - regardless of their value. The values of those numbers are variable and are what set the values to match.

Ok. I don´t know why, but for me the metamax´s patch, doesn´t work. It says;
“jpatchline_completeconnection:index out of range”. Maybe is it because I have Max 5?

I don't get that error.  Did you manually re-enter arguments into the sel objects?  If so, they may have been insufficient for the number of existing connections.  Keep in mind that the number of arguments is not the same as the number of an argument.  In other words, the numbers in a sel object create new inlets/outlets - regardless of their value.  The values of those numbers are variable and are what set the values to match.


the problem is the mentioned issue with the reading priority, that doesn´t otputs the message from the element connected to the second sel output when three outputs are triggered at the uzi object.

Thanks to everyone, specially to Metamax for explains everything so detailled.

I will try to summarize in which point I am and whose has been the approaches to the issue.

The problem is the mentioned aspect of the reading process, that doesn´t otputs the message from the element connected to the second sel output when three outputs are triggered at the uzi object.

- First; To select from a list, a desired number of elements. For example the first five elements from a serie of ten.
 - Second; Outputs these five elements at the same time
 - Third; Compare them with other numbers (that are not in a list) and if there are the same, output a bang.

The problem is the mentioned aspect of the reading process, that doesn´t otputs the message from the element connected to the second sel output when three outputs are triggered at the uzi object.


Metamax suggests to use the sel objects instead the if objects, but the patch doesn´t work with my Max5. I have read the explanations and indications that both Vichug and Metamax are giving, and I think that the problem is that I don´t have more than one inlet in the sel object and there are no connections between values to match´and ´sel´object. There is a picture attached.

Dealing with those problems, Metamax proposes the ´trigger´ object with. In this way I have to choose one value and then another, it can not be simuoltanious. So I have to change my strategy. Right?

Second;
Metamax suggests to use the sel objects instead the if objects, but the patch doesn´t work with my Max5. I have read the explanations and indications that both Vichug and Metamax are giving, and I think that the problem is that I don´t have more than one inlet in the sel object and there are no connections between values to match´and ´sel´object. There is a picture attached.

Third;
Dealing with those problems, Metamax proposes the ´trigger´ object with. In this way I have to choose one value and then another, it can not be simuoltanious. So I have to change my strategy. Right?

I don't see your attached picture ; anyway there is no reason why it would make the error you describe (except if maybe you have an abstraction called [sel.maxpat] somehere in your max search paths....). It's possible that you have to change your strategy... but i promise you that once you figure out how things flow in Max, it will only make sense all of a sudden... (by the way did you read/do the Max tutorial 5 ? (Message Order and Debugging) )

 for Max or MIDI to simultaneously send and receive multiple messages to and from multiple objects. The sooner you accept this fact, the sooner you will understand the flow of data and the sooner you will be able to design something that does what you want. This is a fundamental aspect of serial data. That's why we call it serial. It's a series... a sequential transmission.

When someone juggles 7 balls, they are throwing and catching 

. The effect is that they are juggling them "all at once".. but if they were to attempt to throw and catch them all at once, they would experience similar problems.

As Vichug recommended... read tutorial 5.

And forget about my advice regarding sel. It was only relevant within the context of your original patch... which seems to be based upon a fundamental misunderstanding of data flow. Until you correct that understanding, attempting to fix the problem with new objects is akin to repairing the foundation of a house by rearranging furniture.

Francesc, it is impossible for Max or MIDI to simultaneously send and receive multiple messages to and from multiple objects.  The sooner you accept this fact, the sooner you will understand the flow of data and the sooner you will be able to design something that does what you want.  This is a fundamental aspect of serial data. That's why we call it serial.  It's a series... a sequential transmission.

When someone juggles 7 balls, they are throwing and catching one ball at a time.  The effect is that they are juggling them "all at once".. but if they were to attempt to throw and catch them all at once, they would experience similar problems.

And forget about my advice regarding sel.  It was only relevant within the context of your original patch... which seems to be based upon a fundamental misunderstanding of data flow.  Until you correct that understanding, attempting to fix the problem with new objects is akin to repairing the foundation of a house by rearranging furniture.


I'd like to third the suggestion that you study the tutorials. This tries to implement your goal statement:

How to set the number of bangs with a number box