the idea is to give each incoming list an ID and send only the ID to the [pipe], where the list itself is stored in some [meta-list]. after receiving the ID from [pipe], you could use it to look up the list in [meta-list]. of course you also need to delete the list from [meta-list] then.
I'm not sure what you mean by [meta-list].
I guess you mean something where you can store many lists and access them by using an integer index.
I can only think of 2 implementations of that:
- A set of N instances of an abstraction that I'll call
[meta-list-element]; a meta-list-element contain a [list append] to store the list, and a [r something-$1] where $1 is the index of the element. When you want the k-th stored list, you send a bang to "something-k" and it outputs the list by sending it to some "global" [r]..... or any variation to this kind of implementation.
ISSUE: you need as many [meta-list-element]s as the maximum number of lists you may need to store, i.e. in our case the maximum number of "piped" messages. As soon as N reaches around 1000, the patch becomes unmanageable, not because the needed memory be an issue, but because the patch will take ages to load and even more to close!!
- A [textfile] to store the lists......... oh!! Probably this was the
[textfile] that Frank mentioned in combination with the [pipe] object!!!! When you want the list with id "k", you bang the [textfile] with an [until] ... "until" you find the list with id "k".
ISSUE: retrieving a list from the metalist takes O(N) where N is the current size of the list. Probably an alternative implementation may give O(1) retrieval, but then O(N) insertion.
Well also 3) Pack the lists into one big list, and use a very similar approach to (2) but using [list split 1] banged by [until] to scan the big list (some special reserved symbol will be used as a separator for individual lists).
ISSUE: same as (2)
I've often used these approaches but the number of stored lists never was big enough to become an issue - well once it was but only in a situation where audio dropouts were acceptable.
However the pdlua approach seems promising, I'm really curious to try it out.