How to +1 and -1 if a repeated value is being output
Hi guys,
So my patch is playing specific notes from a scale degree depending on the position of a dot in a jit object. A metro is used for outputting a note every few ms.
A problem I have is, that sometimes the same note is triggered multiple times in a row. How can I say, that if a value is repeated multiple times, it should add or subtract 1.
E.g.
If 60 is repeated 4 times, then it should output 60, 61, 60, 59. Or something similar. I will figure out how I would go about so the steps are according to a music scale.
[change], [incdec]...
@TFL thank you very much! Didn't think it would be that easy xd Sorry for the stupid question.
I understand the incdec as well. But I'm not sure how to filter out the repeated values, change them and then inputting them again. I tried working with a switch, which lets the [change] output through when it's banging something and if it doesn't, then the normal output will be let through (which would then be used with [incdec]. But it's not working properly.
Could you provide a patch so we could help more precisely please?
Of course! Here you go. This is an excerpt of the patch and I tried making it with random so I don't have to add all the jit. I hope it works:)
Something like this can work.
I placed it before the [coll] rather than after, so the newly generated note stays in your scale.
What it does is: check if incoming value is equal to last output value. If not, then just send that value. If it is the same, then randomly add or remove 1 to it and output the result.
As you can see in the console, if I keep sending '5', it will start by sending 5, then 4 or 6, then 5 again, then 4 or 6, then 5 again, and so on.
@TFL wow!! Thank you so much!
It tricks with my brain a little. I'm trying to fully understand how it works. The principle makes totally sense but I don't understand why the last output value has to be compared in the == object. Because the two numbers (the initial one at the top and the last one) are always the same. To me it would mean that == would always trigger a 1 and therefor change the value with incdec all the time. I would have thought you'd have to compare the numbers from the i-object in the middle. But then it doesn't work anymore.
I'm guessing, because of the bang from the sel object the last number has a delay of one tick maybe?
So I'm a little confused to how it works xD But you don't have to further explain if you don't want to:) Thanks so much!
Because the two numbers (the initial one at the top and the last one) are always the same
No, the purpose if the patch is to make it not the same.
Remeber that a cold inlet (the blue ones, usually the right ones) doesn't trigger an output, contrarily to hot inlets (red ones, usually on the left). Here, when a new value is received in the [==] hot inlet, it is compared to the previously output value, received in the cold inlet.
I wrote [== -1] to initialize the object with a value of -1, so that the very first number to come in will always pass through (as it is compared to a "previous" value of -1).
You open the patcher and send a 5:
is it different than -1?
yes, so output 5 and store 5 in the cold inlet of [==]
Then you send another 5:
is it different than 5?
no, so then you randomly add or remove 1 to 5. Let's say we remove 1
we output 4 and store
in the cold inlet of [==]
Then you send yet another 5:
is it different than 4?
yes, so output 5 and store 5 in the cold inlet of [==]
and so on.
Ahhaa, thank you so much for the detailed explanation! now it all makes sense. I didn't know the previous number would be stored in [==]. And the -1 also makes sense now:)
Very cool:)
when it comes to coll, one can use next, prev etc messages
to recall indexes, no matter how they are sorted,
but in order they are set in coll.
in addition, one does not need to query length of coll
(number of lines) to limit number range.
here is a patch showing what I mean,
and pointing mistakes by using inc/dec.
I removed cartpool and co, they make no sense, at least not
as set in your patch
@source audio Thank you so much for the reply! That makes sense and thank you for pointing out the problem with incdec! I guess another solution could be to just add two more indexes in coll, in order to make it not go outside of the range:)
"I guess another solution could be to just add two more indexes in coll,
in order to make it not go outside of the range:)"
and then recall what when inc/dec gets out of notes number range ?