Roman Haefeli wrote:
Some people may miss [s2l] in vanilla Pd, others miss a [pipe] for variable length lists or a multi-period [metro],
those can all be done with built-in objects already, as far as i can see (with more or less effort, though).
I can't see how you could implement a [pipe] for variable-length lists with built-in objects, no matter how much effort you put in it (with acceptable memory/cpu costs).
On Thu, 2008-03-13 at 17:40 +0100, Matteo Sisti Sette wrote:
Roman Haefeli wrote:
Some people may miss [s2l] in vanilla Pd, others miss a [pipe] for variable length lists or a multi-period [metro],
those can all be done with built-in objects already, as far as i can see (with more or less effort, though).
I can't see how you could implement a [pipe] for variable-length lists with built-in objects, no matter how much effort you put in it (with acceptable memory/cpu costs).
not that i've already done it, but i can imagine that it is possible. 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.
probably the most effort is needed to create [meta-list]. though i haven't any easily understandable example at hand, i've used such approaches in many occasions. as an example of how multiple lists can be packed in one list, have a look at [list-fifo] from franks list-abs.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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.
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:
- 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).
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
On Fri, 2008-03-14 at 00:32 +0100, Roman Haefeli wrote:
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 ;-)
haha.. yeah, sure, i read the whole book before going to bed.... i meant to say: everytime before i go sleeping i read a bit... this happens, when writing emails just before going to bed...
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Matteo Sisti Sette -
Roman Haefeli