Gen gate does not working!!! Is this a bug?


    Jan 08 2019 | 4:55 pm
    Hi everybody, I have a click receiving from outside the genpatch, and want that click to go in differents outlet as the counter (made with += and triggered by THAT click I receiving from outside) is growing up. I noticed that is not working properly and wanted to debug, so instead of sending the clicks, I just sent the count (1 to out1, 2 to out2, 3 to out3). NOTHING. It works for two cycles and the third is like that = 1 to out1, 2 to out2, 3 to out2!!! And it repeats like this. I think that is a real bug. The patch is very very simple, can't believe it's not working.
    Please give me an opinion. Thak you very much, Sergio

    • Jan 10 2019 | 9:24 pm
      It is indeed weird but I dont't think the problem is with the gate object. I managed to make it work with visual patching but to be honest, it was easier to include using genexpr within the codebox since you can actually control the time of the events. I included the 2 versions in the patch below :
    • Jan 11 2019 | 11:51 am
      Interesting case. It is crucial to keep in mind that the gen environment knows only one data type which is float. Or as the documentation puts it:"At the Gen patcher level, everything is a 64-bit floating point number." This means the value arriving at the left inlet of the gate operator is truncated. In your example, sometimes this value is just below three.
      Adding a half is a way to make this work. By the way, just like integers are non existent in gen, so is infinity.
    • Jan 13 2019 | 8:13 pm
      Thank you guys. I figured out which is the problem: the % oblect. Here's a patch with "wrap 0 3" replacing that. JVKR, what you said is true, but there is no reason why an integer number like 3 becomes 2.99999... or 3.0000...1. The snapshot you placed now is always showing the integer number (1,2,3) and .00000000. Why the % object is doing like that in your opinion? I agree that % object was not the perfect choice for my purpose :/ Thanks again!
    • Jan 14 2019 | 9:35 am
      Actually I don't think the problem is with the % object either. Basically you are incrementing the amplitude value of the click which is not strictly 1 and then the gate object performs an int/floor before taking the number into account. Another way you could have made sure of making it work is by sending the number to a round object just before the += in the gen patcher
    • Jan 14 2019 | 2:32 pm
      @Sergio, I think you're right, there is no reason why wrap and % should give different results (except for that they deal differently with negative input). That would lead to the conclusion that the % operator is not correctly implemented.
      Just now I remembered that recently I ran into similar precision issues using the pong object.
    • Jan 15 2019 | 11:14 am
      Could someone at Cycling74 please help us understand what is the issue? Why do the modulo operator and the wrap object lead to such different results in the patch below (I just took Sergio's original patch and copied it with the "wrap 0 3" instead of the "% 3")
      Is it a precision related issue as @jvkr suggested ?
    • Feb 03 2019 | 9:26 pm
      @Cycling74 : Any idea on what's going on in the last patch posted (I re-posted it below) and whether there is a precision issue with the gen~ % object (compared to the wrap object) ? It would be great to have an answer about it because these are the kind of objects that get used a lot in a gen~ patch ;)