bach.> philosophy

[ernopolo]

Hi,

I'd like to test pitches if they are in a given pitch range or not. I checked if I could do it without iterating the list, started testing with ints and bach.>.
And was surprised by this result:

greater.PNG (3.86 KiB) Viewed 4488 times

As i understand, in this case this object works with logical OR - but I'd expect to use AND, since I'm sending the numbers as a list. But i understand, we can phrase the question in two ways:
- Are these elements ALL greater than x?
- Are there ANY elements greater than x in this list?

my intuition would go for the 1st one.
or it could be cool to introduce some TRINARY (or ternary) logic here! for example: 0 false 1 true 2 unknown/undecidable/both (or in balanced ternary: -1 false 0 unknown 1 true)


I also thought - turning back to the original question - that it would be nice to tell bach.clip what to do with clipped values. instead of simply mapping them to the corresponding border value, it could transpose them back in the range (if possible), possibly with a setable modulo value.

sorry if i'm writing too many FR these days but i just don't want to forget these ideas. if they are too many, you can just ignore them and get back later - or not - no problem.

Best,
Erno

[andreaagostini]

Hi.

The idea behind bach.> (and, of course, bach.<, bach.<=, bach.>=) is that it compares lists taken as a whole. Of course this requires some element-by-element comparisons, but the idea is that it compares the first elements of the two incoming lists, and if they are the same it compares the second elements, and so on, and as soon as it finds two different elements in the same position it stops and that is the value of the comparison. If you think about it, this is essentially the rationale behind the ordering of words in a dictionary, and I promise the behaviour of bach.> won't change, no matter how many FR you will submit

On the other hand, I understand that some seemingly basic list-against-element comparisons such as the ones you describe require more involuted patching than you'd want. I'll register this as a FR. Meanwhile, you may want to use something like this:
<pre><code>
----------begin_max5_patcher----------
710.3oc0WssaiBCD8YxWgEZUeJaD1lqq1G5+wpUUDvJwUfAYLcops+6KXiSI
cCTmFBJ6CwHOwXelyLywCurxxdaQCoxF7Cvu.VVurxxRZpyfU+bK673ljr3J
4xryIUUw6H1qU+mfzHj1czVJiEI6orcOvIIB0NiBc13rF.gxGnnMdsinMNfe
2+NE0hLhP7bIQ8B11G9KZpb6K1932gt5ynR7blbo1ZKr5bJqcOjfDogBmTQX
hXAsfMJbzCGNw1sRgG4dA6L91pUcCqMjiDE61kQlfPvdtRlvGKe3pGGmPnLw
o4D76GCONmHH7GHr3sJ5wwL9BtbdNLLT5rAvK1yg2TdNi7mVT8OkE2c2Djgq
imJMHvz5hwHinyrx3p4uu95T5.tnYxeCuU72swI62vIo0IDv8sGAPLYYuR.D
iT5Opn+zBgq6+cJVHXdzC0vxAYfdH9Kvcicmg2TbUHdNtyvelnHzU9JioRuH
Mkbv2Zffe1Nh.2WkDmEyyKRI.3jRs9RL62Gc8MHa6TTn2hWqMV9BZp7EcQ0k
kuLWsX3gut4KiQQP.F3NYRwvDYbvWLm.+eo9aeEwro+BuHVXnRpb2synrO1L
tzK5reL0TUTySzXT2aL3c+HkTInLYV4fE0VICfGVydZZJgMrYoTZUW+SRGz4
jwHigiAnAd7htlvIvD3fWL33Y.bB9DzjSSKKZaOpOeAF40o30+.6EcX16myP
7qy24oD9k6PQF5PPycHWnqTBOJpqH0MrukwilgjeDgqmmRrGNnPddycPehuE
sXEVGyhiilkIQNzj5pyKti7fCh6Xn+Iloh6nH30LtCMHtGtnBpPCPysi.1Yo
t+Q4H3EAOrg2EtLj0s0My9WQzn5hItr7IBupeKk.osUtGKjA1f0xoTlZJVNk
SdhpWuxRLus2MQaia0bUeUMgpujyt6yd3rZZeVR6I+1p+J6UqBD
-----------end_max5_patcher-----------
</code></pre>

As for bach.clip, what you want is some sort of bach.fold module, or a folding mode for bach.clip. Why not? Daniele, let's think about it...

Cheers,
andrea

[danieleghisi]

I'd rather go with a new bach.fold or bach.rectify. Clipping really means that one thing...

[ernopolo]

Thanks Andrea,

I see. Then the tricky point for me in understanding the behaviour is not to interpret > as "greater than" but ... maybe "after" - if we talk about dictionaries, alphabetic ordering is about INDEX, not being bigger or smaller in any way. Like, Douglas Adams is not at all "smaller" than Thomas Mann just because it's earlier in the alphabetical order of authors.

So thanks for the dual comparison patch, i find it really useful!
cheers
Erno