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.

@oid You can put the lists into [text] and access them any time.

@ingox I had tried [text] but I must have had a flaw in my logic since it did not work for some reason. Just tried it again, seems to be working and the [text sequence] object will be very useful.. Still interested in other paths, [text sequence] makes [text] the likely solution for my current needs, but it is always nice to know other tricks.

Thanks.

I would also say [text] is the best solution. You can use [text get] instead of [text sequence] depending on your needs...
Also check out [list store], but it is less flexible...

[text] seems to be working fairly well, figured out my use of [text sequence]'s left outlet, bang on done, was the cause of my problems, needed a [t b b b] to make certain the bangs happened in the proper order too reset everything without error. Things are still not quite working how I think they should, starting to suspect that it is a flaw in my basic approach and I need to just post the patch and ask how I should deal with it, but I am not quite ready to give up on figuring out this puzzle on my own.

@Jona I can not seem to figure out [list store] at all, at best it just stores the last list in the message, what is the trick that I am missing?

Thanks.

@oid yes, posting your patch is a good idea if you have a specific question (then it is much easier to help, because we do not have to guess). take a look at the help file from [list store], the functionality is explained quite well.

@Jona this question was about just parsing messages of comma seperated lists, which I could find nothing about. The problems I am having with my abstraction are another thing, I was just thinking out loud. I still can not figure out [list store] in this regard, but it may make more sense after sleep. I have been digging through the abstractions in list=abs and [list-fifo] inspired this simpler, single purpose version which seems to work very well.

@oid @ingox already told you the solution to your question actually you do not need list store for that but you were asking for another path, and now it seems you found another path by yourself
but, be careful with iterating lists (it can get slow with large lists, and cause a stack overflow in the worst case)...

@oid This is a list-fifo with text. It has the benefit that the length of the lists can be arbitrary: text-fifo.pd

Also as abstraction: text-fifo.zip

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