Hi, ive been working on a complex gem patch for creating 3d structures, the patch has a lot of parameters for changing translation , rotation, scale, color, etc. I want to make a preset system for saving the states of interesting shapes and then load them, Do anybody have tried something like this?
which is the best approach for saving a lot of parameters- variables? say 200 or more?
Do you think coll is a good idea for this? or is there a better way for doing this?
thanks
pun.
Definitely not coll. Look at sssad or mememto, or maybe pool. There
is also Mike McGonagle's sqlite object if you want a full database.
.hc
On Feb 5, 2009, at 1:29 PM, punchik punchik wrote:
Hi, ive been working on a complex gem patch for creating 3d
structures, the patch has a lot of parameters for changing
translation , rotation, scale, color, etc. I want to make a preset
system for saving the states of interesting shapes and then load
them, Do anybody have tried something like this?which is the best approach for saving a lot of parameters-
variables? say 200 or more?Do you think coll is a good idea for this? or is there a better way
for doing this?thanks
pun.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you are not part of the solution, you are part of the problem.
Hallo, punchik punchik hat gesagt: // punchik punchik wrote:
Hi, ive been working on a complex gem patch for creating 3d structures, the patch has a lot of parameters for changing translation , rotation, scale, color, etc. I want to make a preset system for saving the states of interesting shapes and then load them, Do anybody have tried something like this?
which is the best approach for saving a lot of parameters- variables? say 200 or more?
Do you think coll is a good idea for this? or is there a better way for doing this?
Generally with preset saving you face two problems:
a) collecting and distributing all the parameters to and from a central place b) storing them somehow - this is also called "persistence".
[coll] only deals with b) and as Hans wrote, there are other storage solutions like [pool] or the sqlite external or pbank etc. There also are useful builtin storage objects: [table], [textfile], message boxes or data structures.
You still will have to deal with a) which is the harder problem IMO. [sssad] was designed to solve a) in a standard way and to work with any solution to b) that you want to use, including storing into [textfile] and message boxes.
So, I would recommend [sssad] to solve a). Just "decorate" everything that you want to save with a cross-connected and uniquely named [sssad]-object, then build your persistence system for example as suggested in the help-file for sssad using [textfile]. You can group parameters like the three numbers for RGB values into lists with sssad as well, if you like.
If you want to see an advanced way of using [sssad] to manage parameters of abstractions in action, you maybe want to check the RjDj library in development here: http://trac.rjdj.me/wiki/RjLibnew
An example with lots of parameters is the [s_fm4] synthesizer, which is a 4-operator FM synth with 40 parameters. The help patch shows how these are saved into a message box, internally you see the [u_dispatch] objects that are used to manage the parameters with [sssad].
Ciao
Frank
many thanks for the explanation !
--- On Thu, 2/5/09, Frank Barknecht fbar@footils.org wrote:
From: Frank Barknecht fbar@footils.org Subject: Re: [PD] preset system for complex gem patches To: pd-list@iem.at Date: Thursday, February 5, 2009, 2:32 PM Hallo, punchik punchik hat gesagt: // punchik punchik wrote:
Hi, ive been working on a complex gem patch for
creating 3d
structures, the patch has a lot of parameters for
changing translation
, rotation, scale, color, etc. I want to make a preset
system for
saving the states of interesting shapes and then load
them, Do anybody
have tried something like this?
which is the best approach for saving a lot of
parameters- variables?
say 200 or more?
Do you think coll is a good idea for this? or is there
a better way
for doing this?
Generally with preset saving you face two problems:
a) collecting and distributing all the parameters to and from a central place b) storing them somehow - this is also called "persistence".
[coll] only deals with b) and as Hans wrote, there are other storage solutions like [pool] or the sqlite external or pbank etc. There also are useful builtin storage objects: [table], [textfile], message boxes or data structures.
You still will have to deal with a) which is the harder problem IMO. [sssad] was designed to solve a) in a standard way and to work with any solution to b) that you want to use, including storing into [textfile] and message boxes.
So, I would recommend [sssad] to solve a). Just "decorate" everything that you want to save with a cross-connected and uniquely named [sssad]-object, then build your persistence system for example as suggested in the help-file for sssad using [textfile]. You can group parameters like the three numbers for RGB values into lists with sssad as well, if you like.
If you want to see an advanced way of using [sssad] to manage parameters of abstractions in action, you maybe want to check the RjDj library in development here: http://trac.rjdj.me/wiki/RjLibnew
An example with lots of parameters is the [s_fm4] synthesizer, which is a 4-operator FM synth with 40 parameters. The help patch shows how these are saved into a message box, internally you see the [u_dispatch] objects that are used to manage the parameters with [sssad].
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Frank Barknecht -
Hans-Christoph Steiner -
punchik punchik