atom feed21 messages in at.iem.pd-listRe: [PD] Re: [PD-announce] pool 0.2.0...
FromSent OnAttachments
Josh SteinerAug 10, 2004 3:29 pm 
Frank BarknechtAug 10, 2004 3:52 pm 
Thomas GrillAug 10, 2004 11:07 pm 
Frank BarknechtAug 11, 2004 12:51 am 
Josh SteinerAug 11, 2004 11:00 am 
Frank BarknechtAug 11, 2004 11:11 am 
siggmussAug 11, 2004 11:27 am 
Frank BarknechtAug 11, 2004 12:31 pm 
Josh SteinerAug 11, 2004 12:37 pm 
shift8Aug 11, 2004 12:59 pm 
Frank BarknechtAug 11, 2004 1:04 pm 
Josh SteinerAug 11, 2004 2:05 pm 
Thomas GrillAug 11, 2004 2:30 pm 
Frank BarknechtAug 11, 2004 2:48 pm 
Frank BarknechtAug 11, 2004 3:03 pm 
shift8Aug 11, 2004 3:13 pm 
siggmussAug 11, 2004 3:33 pm 
aym3ricAug 11, 2004 4:59 pm 
guenter geigerAug 11, 2004 10:17 pm 
Frank BarknechtAug 12, 2004 1:18 am 
guenter geigerAug 12, 2004 2:27 am 
Subject:Re: [PD] Re: [PD-announce] pool 0.2.0 - a hierarchical storage object
From:guenter geiger (gei@xdv.org)
Date:Aug 12, 2004 2:27:16 am
List:at.iem.pd-list

On Thu, 12 Aug 2004, Frank Barknecht wrote:

You can do this easily with state using $ arguments for your abstractions. The naming for each state file is name.state where "name" and "state" can be chosen freely.

But can I save the state(s) of a full patch which uses various levels of abstractions into a single file using [state]?

You can even generate all your envelopes with just one envelope abstraction and later handle the setting on a file system level by copying them around , duplicating, renaming and reusing in other abstraction instances.

But isn't this exactly the problem? It forces a user to depend on something like the filesystem and its tools and thus is inherently platform dependent.

Sorry, I didn't want to convince you to use state. state is dead. I was just correcting a misconception about state that you had.

You are free to use the above mentioned arguments (which are definitely valid) to demonstrate the superiority of pool.

Guenter