@cfry Finally have time to get back to this. Quick question, what is the source of the sequences in the cycle abstractions? Generated, entered in manually, gotten from somewhere else. something else? Do they share a sequence and each use different parts of it? Realized I made a few assumptions on how I went about dealing with that part of your patch and it could be terribly inefficient in some cases. Think I have things mostly worked out, just need to fix a few minor things and document the commands.

@jameslo I sort of agree but honestly, thinking too hard about [text] is something I have learned to avoid doing. If memory serves I did not really devise a separator, I did a [text tolist], dripped and escaped the escapes of the commas, then [text fromlist] so my delimiter was \,. I used my list search abstraction to find the delimiters and fetch the message I was looking for. I am pretty sure that version of [l-find] can do it with ease, not yet on the new laptop and don't have time right now to dig. I probably used [l-find] to replace the commas as well. These days, I think I would just use [pdlua] and get actual tables.

Edit: actually I don't think that version of [l-find] will find all instances and output a list of their indices, so not quite easy. I can upload that later if you want it.

@jameslo In the past I just used something other than a comma (or had pd replace the commas) to separate messages so I could get the whole line, dump it into a [list store], find the appropriate delimiters and get the message I wanted. Not as efficient as your method but don't need to keep two [text]s synced. I almost made an abstraction of your way but the ugliness of automating the generation of the mask [text] sapped my motivation, the [text[ way of doing things just fights you here.

@Moothart You just need to stick a [t f f] after the [list store] so you can pass the value forward and store it. Another one of those very common idioms like list dripping which you will use a great deal.

@Moothart [expr] also has some options here, rint, round, nearbyint, ceil and floor can round out the options. Open the help for [expr], and then the subpatch that is something like [pd all functions and operations] and then into the subpatch that is something like [pd misc numeric operations] for more info, going from memory on those subpatches. [i ] often works but it always rounds down, 0.999 will be 0 which can be irritating and not at all what you want. And you can stick the division right in there, [expr round($f1)/10]. [expr] is not as efficient as the normal math objects, generally we don't need to worry about this much with modern cpus unless you are using [fexpr~] or [expr~] in a subpatch with a small blocksize, but it is good to keep in mind and not just use it because it is easy.

@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 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.

@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.

@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.

@stefano_zorzanello A copy and paste of that patch works fine for me and scanning through the text I don't see any issues, but I did not look closely. Did you save it as plain text? or just let the text editor decide the format? rtf or other fancy formats used by word processors might cause a crash. Here is the patch I get, maybe it will work if saving as plaintext does not work for you.
Untitled-1.pd