Hi,
this is not terribly important, but it seems that [select 12 12] triggers only its leftmost outlet when it receives a 12 at its inlet. Is this intentional?
cheers, P
use
[select 12] | [t b b]
Em Qui, 17 de jan de 2019 15:04, Peter P. peterparker@fastmail.com escreveu:
Hi,
this is not terribly important, but it seems that [select 12 12] triggers only its leftmost outlet when it receives a 12 at its inlet. Is this intentional?
cheers, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Peter,
On 17/01/2019 17:04, Peter P. wrote:
Hi,
this is not terribly important, but it seems that [select 12 12] triggers only its leftmost outlet when it receives a 12 at its inlet. Is this intentional?
Changing this behaviour in the C is not totally trivial, as you would need to keep track of matches, to not send to the last "reject" outlet at the end. As it is now, it just "return"s after sending to a matching outlet.
https://github.com/pure-data/pure-data/blob/7c27aa0ad505bb4802eee3fc40886836...
I suggest
| [t a a] | | | [select 12 12] | | [t a a] rejected | | | [select 12] | | | 12 b | [select 12] | 12 a
assuming your 12 is just a placeholder for your real problem (maybe $arg stuff?)
Claude
- Claude Heiland-Allen claude@mathr.co.uk [2019-01-17 18:28]:
Hi Peter,
On 17/01/2019 17:04, Peter P. wrote:
Hi,
this is not terribly important, but it seems that [select 12 12] triggers only its leftmost outlet when it receives a 12 at its inlet. Is this intentional?
Changing this behaviour in the C is not totally trivial, as you would need to keep track of matches, to not send to the last "reject" outlet at the end. As it is now, it just "return"s after sending to a matching outlet.
https://github.com/pure-data/pure-data/blob/7c27aa0ad505bb4802eee3fc40886836...
I suggest
| [t a a] | | | [select 12 12] | | [t a a] rejected | | | [select 12] | | | 12 b | [select 12] | 12 a
assuming your 12 is just a placeholder for your real problem (maybe $arg stuff?)
Thanks Claude, I am not really facing a problem here, but some learners of Pd stumbled across this and wondered why the second outlet doesn't bang. I assumed there was a "return after first match" in the source code and it is good to hear that it is non-trivial to changet it. I feel this behavior doesn't even qualify to be mentioned in the help patch. So thanks to your kind reply it will now be documented in the mailing list archive at least!
cheers, P
Hi Peter,
On 17/01/2019 21:04, Peter P. wrote:
I assumed there was a "return after first match" in the source code and it is good to hear that it is non-trivial to changet it.
By not totally trivial I meant that it's +3-1 lines instead of a -1 line change. So totally doable, but it might break old patches, and the gain is small, so I doubt it's worth it.
BTW to clarify my example patch:
| [t a a] | | | [select $1 $2] | | [t a a] | | | [select $2] | | | [select $1] |
to keep the output order right-to-left as is usual in Pd.
Some more keywords for mailing list archive: duplicate argument
Claude
-
Claude Heiland-Allen -
José de Abreu -
Peter P.