Dear Forum,

is there a chance to get a momentary value out of a running [line] object with a bang? Let´s say it would count to 12 in 5000ms. The bang would not always be synchronized to seconds in my case, so the values can also be floats in the moment of a bang,

a) In that respect: Rounding the floats to the next/previous integer would be nice, though.
please allow another project related question: How to check for values in an array or list like i.e. (2 4 6 7 9) is true during the run of the [line] object, when it passes particular numbers?

Thanks very much!!

@Moothart For the first question, just connect the outlet of [line] to the right inlet of [i ], bang the left inlet of [i ] when you want to sample the output. Checking for numbers is a bit more difficult since you can not be certain [line] will ever hit those numbers, it might go from 0.99 to 1.01 and never hit 1 but since you just want to know when it passes it, that is a bit easier. if the numbers in the array/list are always sequential as in your example it is pretty easy, you just need a [>=]->[sel 1] which goes into a counter that gets the next element from the list/array and dumps it into the right inlet of the [>=].

If this is not what you want, some more details about what you are trying to accomplish would help but someone else might see what you are going for.

Dear @oid,

I think, that is exactly on point, what you wrote!

Just to ask back a little:
Do I understand you right, that the value "1" might not be hit between "0.99" and "1.01" ?
It would be perfectly okay for my intention, that the [line] counts in one direction in floats as it usually does. So, would you say the value "1" does not have to occur during the run of the ramp values. I will check your generous patch in the next days and try wrapping my head more on specifics, -> IF necessary at all.

My main request is how to compare given integers from a list, that do not have to be adjacent - like [2 5 6 7 10] - being compared to the line object´s actual value. (i.e. [9 5000]-[line])
In the exact moment there is a match from any(!) of the list´s number "pool" and the running [line], that specific value should be kept in a kind of "buffer" for as long as the next match between the [list] and the [line] is found. The slope of the [line] determines how fast the list´s elements are changed in the "buffer" . - Hope this is a bit clearer....

Cheers!! and many THANKS!
M.

@Moothart In the above example the array would only contain 2 5 6 7 10, so it would work as expected as long as the number are arranged sequentially from lowest to greatest, but [array] is not so good for this since it is a fixed size, [list store] is the better option here since it resizes itself to the list you give it.

This little block of code built around the [list store] is called a list drip, this variant being the slow variety, every time it receives a bang it drips the next element of the list. The list drip is a very common and useful paradigm in pd, good one to learn and really understand since there are countless variations you can patch up for various needs. Here I am using a [s value] for the output which sets the right inlet of the [>=] and makes it easy to get the current value anywhere else in the patch through [r value] or [v value], each having their advantages and disadvantages. I also added a [s bang] which bangs after each time the value changes, which also can be useful. That [change] I added in after the [>=] is quite important and an oversight in my previous example.

One thing to be aware of when using [v ], especially when you are also using [s ] to set that [v ], creation order can bite you.

Pd sends the new value to the [r ]s and [v ]s in the order they were created and [r ]s often execute more code, if there is a [v ] in that branch of code the [r ] executes and that [v ] was created after the [r ], the [v ] will have the old value. Generally it is fairly easy to find these bugs once you understand how creation order affects [r ] and [v ], but it can be very difficult to sort out in large complex patches. The above patch also demonstrates the importance of using [trigger], it is generally wise to just use [trigger] anytime you need to connect more than one object to a single outlet, beyond being more reliable it also tends to make patches more readable and neater even in those situations where order does not matter and you can get away without using a trigger.

Very sophisticated help, dear @oid,

I will have to dig into it over the next day(s). I gave the last post a "favourite" and a count of 1 up. Hope, this is correct to do here.

Thank you very much!!