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!!

Dear @oid,

I understand your patches as far as being a beginner, and it works perfectly here. I have to wrp m< head on some details of the patches, I guess.

My update would be to work the selected numbers message [2 5 6 7 9] more as a generic "pool" of numbers, in that respect disregarding the order from low to high.
Is there a chance that any number of that array [2 5 6 7 9] could be recognized without any order.

I would see to buil a [>=] object for every number instead of that array, It is okay for me to do it this way, but maybe there is a more elegant method to do it. .

Generally speaking: If I would send any number stream like 5-2-7-9-6, how to make it recognize any match of the array´s members [2 5 6 7 9]

Thank you!

@Moothart The list-abs library has an abstraction that will confifm that a value is a member of a list.
list-sieve.zip
David.

@Moothart If your values really are just small integers, then you could use an array to indicate whether a value is in or out of the set. In this case, n is in the set if the nth element of the array is non-zero.
set inclusion.pd

@Moothart It is just another slight variation on dripping lists, we just change the list we are dripping and how it is triggered.

This is pretty much the same as @whale-av's solution but updated to use [list store] which was not around when list-abs was made. Most of the list-abs abstractions can be made more efficient with [list store], especially those ones which drip the list.

Personally I find @jameslo's solution the best, most efficient (probably want to add in a [change] after the [int]) and cleanest. It is also a nicely circular with your misunderstanding of my initial response (assuming I understood you correctly and did not misunderstand), I have a fondness for that sort of ending up where you started path, tend to learn a lot from it despite the time spent going in circles.

@oid
Actually wrapping my head around the logic. New to [until] ...
Where does the 0 message box patch cable go (left or right inlet of [f ]?)

(The idea would be to output the particular number of the [2 5 6 7 10] in exact the moment the [line] equals one of the numbers of that list. It should be kept/shown in [int] or a number box until the next match. )

THX very much !!

@Moothart In this case it does not matter if it is the left or the right inlet and it would work the same. The general convention when something is patched as I did is that the connection does not cross inlets/outlets and is connected to the first it comes to since anything else would be ambiguous. Vast majority of those who patch like this, follow this convention.

Going to the right inlet it loads 0 into the float, than the [until] is banged sending [get 0 1( to [list store], the [until] then bangs until the [list store] gets an out of bounds get which sends a bang out of its right outlet to the left inlet of [until] which stops the [until]. Going to the left inlet the [f ] immediately outputs a zero which sends the [get 0 1( message to [list store], adds 1 to it and sends 1 to the right inlet of [f ], the [until] then starts and sends 1 out giving us [get 1 1(. Only difference between the two is that the [until] will bang one time less if you send [0( to the left inlet than it would if you send it to the right.

@Moothart @oid's patch with a different arrangement. Patch style is very personal, there is no accounting for taste.

@oid said:

@Moothart In this case it does not matter if it is the left or the right inlet and it would work the same. The general convention when something is patched as I did is that the connection does not cross inlets/outlets and is connected to the first it comes to since anything else would be ambiguous. Vast majority of those who patch like this, follow this convention.

Going to the right inlet it loads 0 into the float, than the [until] is banged sending [get 0 1( to [list store], the [until] then bangs until the [list store] gets an out of bounds get which sends a bang out of its right outlet to the left inlet of [until] which stops the [until]. Going to the left inlet the [f ] immediately outputs a zero which sends the [get 0 1( message to [list store], adds 1 to it and sends 1 to the right inlet of [f ], the [until] then starts and sends 1 out giving us [get 1 1(. Only difference between the two is that the [until] will bang one time less if you send [0( to the left inlet than it would if you send it to the right.

Good hint! THX

Is there a chance to see the change of the value in the moment, when the line passes a number of the [2 5 6 7 10]? I hope I get it right here in rebuilding the latest patch.
Maybe there is a chance to build in a number box representing the actual number for so long, until the next number from [line] is passed, being represented in that number box then. The result would be showing adjacent numbers from 2 5 6 7 10, each occuring for a specific amount of time depending on the line object passing that numbers one after another...

@Moothart The easy way will be to use [print] and you will see the value in the console even though a number box might not have time to show it.
Or you could use [sel 2 5 6 7 10] with bangs on the first 5 outlets and see the effect in the patch.
David.