[PD] [almost OT] need suggestions for an implementation
Matteo Sisti Sette
matteosistisette at gmail.com
Thu Mar 13 20:31:58 CET 2008
> 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.
More information about the Pd-list
mailing list