Frank wrote:
You could do that with the "textfile" and "pipe" solution as well. The order of lines in textfile doesn't matter, if you pipe them to "pipe".
Ohhhhhh, great! I didn't understand your proposed solution, until I had another look at the [pipe] help, which I was convinced I knew, and was convinced worked another way :$
So, it seems I don't even need any [textfile], just the pipe; and the way it "wants" the time to be specified (relative to when you insert the message) is just the way I want to specify it.
So, the only problem now (which is a big one indeed) is that the format for the messages will be fixed, while I would like to manage arbitrary-length messages with variable-type arguments. Not to mention that allowing symbols is untested. This is the first time I have a wish for the pd wishlist that is not "fix bug number xxx".
I am thinking about crazy dynamic-patching hacks to achieve this.......
Another question: do you know how the sorting of messages inside [pipe] is implemented? Will the time needed to add a message increase linearly? (I think the best achievable is logaritmically, isn't it)
And I don't know if the number of messages you can store in a "pipe" is limited or big enough
If not, I think I can work this one around by using multiple pipes, keep track of the number of stored messages, and use a [poly] to menage "available" [pipe]s
Thanks m.
Hallo, Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
So, the only problem now (which is a big one indeed) is that the format for the messages will be fixed, while I would like to manage arbitrary-length messages with variable-type arguments. Not to mention that allowing symbols is untested.
I tested it, it works. ;) Pointers also work. An approach carmen did in the past is to use list2symbol and symbol2list (the latter an external) and delay only messages with one symbol in [pipe], where the symbol is (de)constructed on demand. This may trigger Pd's memory leak with symbols when you use a lot of them, though.
Another question: do you know how the sorting of messages inside [pipe] is implemented? Will the time needed to add a message increase linearly? (I think the best achievable is logaritmically, isn't it)
Why care? There's not much you can do about it, if it's too slow, except writing a better [pipe] in C/Lua/etc. and then it doesn't matter anymore that [pipe] was too slow.
I think, a bigger problem of the [pipe] approach is that you cannot reschedule anything, once it's in the pipe. You cannot change the tempo anymore for example, and you cannot cancel single events. This makes [pipe] only useful for things that you schedule once and that you then can let run as they are, like a fixed score. For more dynamic tasks this isn't appropriate. For this, an IOI approach as in [qlist] etc. is much nicer. But I guess, you're not looking for this kind of thing anyway ...
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Matteo Sisti Sette