[PD] [almost OT] need suggestions for an implementation

[Roman Haefeli]

On Thu, 2008-03-13 at 20:31 +0100, Matteo Sisti Sette wrote:
> > 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).

yo.. i couldn't stand to try it and actually i've done as you describe
it in 3). and yeah, it's questionable whether it's worth the effort to
build it as an abstraction with internals, but at least it is possible
(unlike [symbol2list]).

http://romanhaefeli.net/software/pd/varipipe.tar.gz

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

me too (though it probably takes me while to learn it. i decided to read
the 'Programming in Lua' book first before i go to bed.... and i am only
at chapter 5 ;-)

good night
roman




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de