• Products
    • Isadora
    • Get It
    • ADD-ONS
    • IzzyCast
    • Get It
  • Forum
  • Help
  • Werkstatt
  • Newsletter
  • Impressum
  • Dsgvo
  • Press
  • Isadora
  • Get It
  • ADD-ONS
  • IzzyCast
  • Get It
  • Press
  • Dsgvo
  • Impressum

Navigation

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Popular
    • Tags

    Counter behaviour problem

    Troubleshooting and Bug Reports
    3
    4
    1891
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Fred
      Fred last edited by Fred

      I have a counter that increments by 10 in a loop in wrap mode. With a minimum of -45 and a maximum of 45. I would expect that the counter would keep on with multiples of 5 in a loop (this was the desired behaviour). However when the counter hits 45 the next number is -36. This kind of makes sense, the first value of the 10 increment is used in going over the maximum and engaging the reset. However, it would make more logical sense if the value that pushes the counter over its limit is preserved or discarded completely (or maybe I am using the wrong tool to count by 5 from -45 to 45 in a loop). 

      In my case I would like that the over signal is discarded and after the increment that passes maximum I land back on my minimum. Another logic that makes more sense to me is if the whole value was passed, so instead of using up part of the increment value on passing the maximum threshold, that the increment is preserved and in this case, (increment 10, min value -45, max value 45) the values would proceed from 45 to -35, or 45 to -45, not as they currently do 45, to -36.

      I totally understand the logic however, when this is compared with the float counter the behaviour pattern breaks. The float counter uses the whole increment every time, so the sequence goes from 45 to -35. If the behaviour was consistent I would expect the float counter go 45, -35.0000001 (or to whatever the maximum significant figures the float holds)

      I guess changing this would break some patches, but the clarity of behaviour would be good to understand and make consistent.

      As I want to chain two counters (as if iterating through a 2d array) it seems it would be useful in this case to have a loop out trigger on the counter actor when in loop mode. The way it is now, I cannot find a way to properly reproduce this behaviour for a lesson.

      I attached a simple patch as an example of the behaviour.

      Counter error.izz

      http://www.fredrodrigues.net/
      https://github.com/fred-dev
      OSX 13.6.4 (22G513) MBP 2019 16" 2.3 GHz 8-Core i9, Radeon Pro 5500M 8 GB, 32g RAM
      Windows 10 7700K, GTX 1080ti, 32g RAM, 2tb raided SSD

      1 Reply Last reply Reply Quote 0
      • DusX
        DusX Tech Staff last edited by

        Yes, this is great catch.

        I would 100% agree the behaviour of the Float Counter is what would be expected.
        Have you entered a formal bug report? I can if you haven't.

        Troikatronix Technical Support

        • New Support Ticket Link: https://support.troikatronix.com/support/tickets/new
        • My Add-ons: https://troikatronix.com/add-ons/?u=dusx
        • Profession Services: https://support.troikatronix.com/support/solutions/articles/13000109444-professional-services

        Running: Win 11 64bit, i7, M.2 PCIe SSD's, 32gb DDR4, nVidia GTX 4070 | located in Ontario Canada.

        Fred 1 Reply Last reply Reply Quote 0
        • Fred
          Fred @DusX last edited by Fred

          @DusX nope no bug report. Actually i thought that over values are all used up and it should just hit the minimum, this behaviour does not exist in either yet though. My logic is that it should be able to function as an iterator. I know that I can do this with javascript, but I am preparing lessons for beginners, with the idea that I can illustrate the principles I am talking about with Isadora and the information has another lesson built in. This is the first lesson about pixels, so javascript is a bit much.

          http://www.fredrodrigues.net/
          https://github.com/fred-dev
          OSX 13.6.4 (22G513) MBP 2019 16" 2.3 GHz 8-Core i9, Radeon Pro 5500M 8 GB, 32g RAM
          Windows 10 7700K, GTX 1080ti, 32g RAM, 2tb raided SSD

          mark 1 Reply Last reply Reply Quote 0
          • mark
            mark @Fred last edited by

            @Fred & @DusX 

            I think the Counter actor really works as it should. It's all about how on thinks about the wrapping

            For example, here's a graphic representation of a Counter with the 'min' input set to -3 and the max to +3, with the 'amount' amount set to 3.

            As you can see, if you go up by three, and if you have both -3 and +3 as part of the cycle, then it works exactly as it should. Can you see why this makes sense?

            It is true that the float counter works differently, so there is an inconsistency ,this I will admit. That's because the true upper limit is a fraction less than 'max'. For a Float Count with the 'min' input set to -3 and the max to +3, with the 'amount' amount set to 3, you get this pattern:

            In fact, you never hit +3 because the actual limit is 2.99999999999.... (Try it and you'll see it's true.) Also not so intuitive.

            Fred, if you want the Counter to work the way you want, you can set the 'max' value to the desired max value plus the amount value minus 1. So, for your case, if you set the 'min' input to -45, and the 'max' input to (45 + (5-1)) 49, you'll see that it goes 30, 35, 40, 45, -45, -40, -35, etc.

            Now, I am open to changing this – we could have an "inclusive" input which would either include or exclude the maximum value. (The Counter is currently "inclusive" while the Float Counter is currently "exclusive.")

            Do you have a different suggestion about how it should work to make it more logical? In the end, you probably want the behavior of the Float Counter in the normal, integer Counter. But then to get the results you desire, you'd have to set a range of -45 to 50. This also is not very intuitive. 

            Waiting to hear your thoughts.

            Best Wishes,
            Mark

            Media Artist & Creator of Isadora
            Macintosh SE-30, 32 Mb RAM, MacOS 7.6, Dual Floppy Drives

            1 Reply Last reply Reply Quote 0
            • First post
              Last post