> 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: 1) 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!! 2) 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. _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
