Hi all,

So, I have lists formatted as a series of varying-length strings each ending in a negative number, such as:
[this that and -32(
and
[but 35that -23(
etc
I have these coming into my patch at various times, and what I need is a way to check each list as it arrives, and to only pass it if it ends in a negative number smaller than that in any of the previous lists. There may at times be two or three such lists arriving at once, so any solution needs to dynamically compare multiple lists and output the list which ends in the smallest number. Any thoughts on how this could be achieved?

Hi,

What about this?:

lists.pd

Hope this helps. Cheers!
Gilberto

@youcloudsofdoom Maybe this?

@gsagostinho Ah I like yours better, because it work with varying length lists better. On mine I suppose you could use [pack] with a bunch of dummy spaces if you know the largest list size, but yours is more elegant!

@rjpg Yeah, [list split] is so wonderful for these type of dynamic situations when you don't know what size and what type of list is coming

Hi @gsagostinho and @rjp9

Thanks for taking the time to reply! I really appreciate it.

I don't think I explained my requirements properly, as I don't think these aren't quite what I was after. The exact situation is that each list is a set of midi info basically, ending in the negative number. Each of these lists is being sent from another software over OSC at various times. I want to only play the midi info contained in the list ending with the lowest number at any one point, which will probably involve checking incoming lists against what is already playing back, and replacing the currently playing list with the new one, if that new list has a lower negative number (by that I mean if a list ending in -32 was playing, then that would be replaced if a list with -23 was received). Is that a little clearer? It's a weird situation and an odd problem, I know!

Hmm, after reading your last message I still don't understand why this patch I posted above isn't what you are looking for. You simply need to detect when a new message is being going through the algorithm above, and then flush any previously held MIDI notes before sending the new MIDI data to be played.

@gsagostinho Ah, okay, I must have misunderstood your patch then - I've replaced inf with 1000, and it seems that only the first list I send gets through the spigot, and then anything else isn't passed, regardless of what number it ends in. What have I missed here?

[...] it seems that only the first list I send gets through the spigot, and then anything else isn't passed, regardless of what number it ends in.

Really? I tested it and it works well here. In the example above, the list in the bottom has a larger last element (-23 > -32) so it doesn't get passed -- as it's expected. This algorithm simply looks at the last element of a list of any size (the size can also change from list to list, no problems with that), and if the last received list has a smaller last element (or more negative) then it gets passed, else it's simply ignored. In the example I used, if you click first on [list but 35that -23( it gets passed, and then if you click on [list this that and -32( it will also gets passed (since -32 is smaller than -23), but the opposite is not true: if you click on the list ending with -32 first, the other one will not be passed.

Also, indeed you need to exchange that [1e+100( to [1000( or some other smaller number, since when Pd saves the file, it simply replaces that outrageously large number for [inf( causing some conflicts with the number box.

Cheers,
Gilberto

@gsagostinho ah, for some reason when I redownloaded it, the patch worked fine! Thanks so much for that, you solved some serious headscratching I was having!

Glad to hear that! Cheers, Gilberto

One last thing - if I wanted to flip it so that it output the highest number, rather than lowest, what would need to be changed? I've had a quick play and can't quite get that functionality to work.

You have to change the [<] for [>] (then if the last element is larger the lit gets passed) and also the [1000( for [-1000(, so that the first list will for sure have a last element larger than -1000. Does this make sense to you?

Hmm, yeah, that's what I thought - I've attached the patch I just edited, can you tell me if this is acting right to you?list3.pd

Hi,

I just made a small improvement in the patch; there were two patch cords coming from the middle outlet of [list split], and the order in which they were created matter for the patch to properly work. So I added a [t f f] to avoid that, and now all is good. See:

lists-corrected.pd

Cheers!
Gilberto

Ah, excellent, that does it! Thank you again!