[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