How would you go about getting one list from a message of comma delineated lists without rebanging the message everytime? It seems like it should be a simple task, but I can not find a solution. A list split for lists so I can just get which ever list I need, when I need it. Best I have come up with is dynamically creating arrays for each list, but I have yet to get that to actually work, not that I have not really tried very hard yet, it just seems like an overly complex solution. Working with vanilla.

Thanks.

@ingox Nice. It seems nearly all abstractions that are needed for updating (or privately replacing) the list-abs library with the newer pure data objects are floating around
I modded the abstraction as a suggestion with a toggle, so that it is possible to switch between fifo and lifo.
text-fifo-lifo.zip

this one does the same for list elements: text-element-fifo-lifo.zip if there are only numbers in the list an array could be more efficent, because it is possible to resize the array instead of copying the list.
edit: perhaps this is a simpler solution for list elements, and it looks almost like the abstraction [list-drip-slow] from list-abs element-fifo-lifo.zip

Thanks for the ideas @ingox and @Jona. I am not sure which path I will take for this abstraction yet, but I have quite a few new techniques that should prepare me for most any future need. Time to play with these and figure out the flaw in my thinking that keeps [list store] from working.

So here is where I stand at this point, ended up building off of the abstraction from @ingox, which works quite well but I also needed it to pass the first message right through so I added the [list append] and a [route]. Appreciate any pointers anyone can offer, fifo.pd

@oid Looks good. I would probably add a [b] after the second inlet to make sure that the text size can not be changed by wrongly sending a number to the inlet. Other than that, great!

@ingox I suppose the [route l b] in your abstraction would have prevented numbers going into [text size], I missed that. In the abstraction I am using this in, only bangs can reach it, but that is cheap insurance and could save me some troubleshooting as I develop the rest of the abstraction. Thanks for pointing that out.

@oid Yes, other programming languages are far more strict than Pd, where every API has to closely defined in terms of what types are expected. This is of course a great thing to prevent bugs. Pd is very loose in that regard and sometimes it is just too much hassle to take care of any circumstance, but i like the idea of abstractions being mostly save in all circumstances

@ingox @oid Back again with "old" style Vanilla......... list-fifo.zip
Mostly an old extended abstraction........ I have added a "list index select"........ "show_this_one"
You can add more to the list at any time.
You can "pop" the lists (from the first in) but you lose them forever as they are popped (.......normal behaviour).
Floats, lists, symbols no problem.
Of course it recycles the lists every time an index is asked for....... to the depth you have requested....... without sending them onward.
David.

@whale-av I hacked my previous [list] based method from that old extended abstraction, I did come across yours while digging through the forum, but it was just a mess of wires to me at that time. It is much clearer this go around and has given me a few ideas that may push me back to my [list] based solution, but first I need to finish the rest of the abstraction. Almost there.

Thanks.