Well, we could also use an array and check in properties "save content" Or we could use two messages boxes [set $1(---[ ( and a loadbang (like in the little bagoftricks memory) Or we could use the object [init] with using the second inlet for setting the memorized value, ect...
But if we need to store several lists of parameters, that could become very complicated, Anyway, the last patch submitted fits very well the patch I am experimenting that needs a little memory, I will submit soon a patch with this little memory in action (with hope), many other externals needs to be replaced by native objects before.
Anyone knows how could I replace [popup] or [widget menubutton]?
Thank you for this add, I never tried to use the "no init" button in slider properties.
Martin Peach martinrp@alcor.concordia.ca a écrit :
If it's just a few parameters you can make a patch with sliders and use the init function (right click on a slider, chooose Properties, click on "no init" and "apply") ...as long as you remember to save the patch every time.
Martin
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
Hallo, patco hat gesagt: // patco wrote:
Well, we could also use an array and check in properties "save content" Or we could use two messages boxes [set $1(---[ ( and a loadbang (like in the little bagoftricks memory) Or we could use the object [init] with using the second inlet for setting the memorized value, ect...
I would really recommend to take a look at [sssad]: For a simple general purpose state saving it is much more flexible than the solutions above and still only uses builtin objects (with pd 0.39).
if you use various [textfile]s to do the actual state management with sssad or if you wouldn't mind to access the harddisk with preset-switching it even allows storing different presets, not just a "snapshot" of the current state of things, which is the original motivation of [sssad]. I attached a little example how to do this.
But if we need to store several lists of parameters, that could become very complicated, Anyway, the last patch submitted fits very well the patch I am experimenting that needs a little memory,
Here I would recommend to use a [textfile] instead of the message box. It's quicker than changing the message box all the time, and the messages to [textfile] are very similar to those you send to a message box.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi, next step in my crusader for replacing externals with native objects will be about replacing memento with ssad, textfile for this stuff is obviously necessary, thank you, Frank, for this great work.
I keep on saying that using a message box is more usefull for fixed memory settings, like in the GOP menu patch submitted before, than being in need of a textfile.
Any memory used for things that doesn't need to be saved under a preset, have absolutely no reason to be in an external file, it's irrelevant.
If it's relevant, but I don't see how it is.
Anyone knows a trick for replacing zexy/drip, and ggee/concat with internal objects?
Frank Barknecht fbar@footils.org a écrit : I would really recommend to take a look at [sssad]: For a simple general purpose state saving it is much more flexible than the solutions above and still only uses builtin objects (with pd 0.39).
if you use various [textfile]s to do the actual state management with sssad or if you wouldn't mind to access the harddisk with preset-switching it even allows storing different presets, not just a "snapshot" of the current state of things, which is the original motivation of [sssad]. I attached a little example how to do this.
Here I would recommend to use a [textfile] instead of the message box. It's quicker than changing the message box all the time, and the messages to [textfile] are very similar to those you send to a message box.
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
Hallo, patco hat gesagt: // patco wrote:
next step in my crusader for replacing externals with native objects will be about replacing memento with ssad, textfile for this stuff is obviously necessary, thank you, Frank, for this great work.
I keep on saying that using a message box is more usefull for fixed memory settings, like in the GOP menu patch submitted before, than being in need of a textfile.
Any memory used for things that doesn't need to be saved under a preset, have absolutely no reason to be in an external file, it's irrelevant.
True, but they also have no need to be in a message box, if they are temporary anyway. You can just as well use a [textfile] without ever touching the "file" functionality of it: Just use it as a container for messages like you would use a message box. It's much easier to work with the textfile, because you can rewind it, get messages one by one etc. Attached is how this is done. You could also try to remove duplicates by using the "setable-route" idiom to filter out keys that already exist, but that is a bit more tricky.
Actually I'm currently using Georg's PDContainers a lot for storing and retrieving in-memory patterns and similar things. I have a feeling, that sometimes I'm just rebuilding [qlist] though, but h_multimap and h_list are just too tasty to ignore them for these purposes. A kind of "map" container is really something that is missing in core Pd IMO.
If it's relevant, but I don't see how it is.
Anyone knows a trick for replacing zexy/drip, and ggee/concat with internal objects?
[list] equals [concat] and [list]-abs is a collection of list-operations done with native objects in pd-0.39 and up. Zexy's drip is called list-drip.pd there. (The setable route from above is part of [list]-abs as well where it is called sroute.pd. In the attached patch I made it into a subpatch for simplicity.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht fbar@footils.org a écrit : patco hat gesagt: // patco wrote:
I keep on saying that using a message box is more usefull for fixed memory settings, like in the GOP menu patch submitted before, than being in need of a textfile.
Any memory used for things that doesn't need to be saved under a preset, have absolutely no reason to be in an external file, it's irrelevant.
True, but they also have no need to be in a message box, if they are temporary anyway.
Well, at least when we save the patch, the values inside the message are stored with the patch and that's exactly what it was intended to do, and without the need of an external textfile.
You can just as well use a [textfile] without ever touching the "file" functionality of it: Just use it as a container for messages like you would use a message box. It's much easier to work with the textfile, because you can rewind it, get messages one by one etc. Attached is how this is done.
okay, that exactly like we can do with a message box but it's more simple with a textfile, true, but textfile needs an external file for keeping values.
You could also try to remove duplicates by using the "setable-route" idiom to filter out keys that already exist, but that is a bit more tricky.
that's very tricky indeed, I think that a second textfile is needed for doing this stuff just as a temporary container
Actually I'm currently using Georg's PDContainers a lot for storing and retrieving in-memory patterns and similar things. I have a feeling, that sometimes I'm just rebuilding [qlist] though, but h_multimap and h_list are just too tasty to ignore them for these purposes.
Hmm, pdcontainer looks interesting, I haven't tried it yet, but will give a try...
A kind of "map" container is really something that is missing in core Pd IMO.
yeah!
If it's relevant, but I don't see how it is.
I wanted to say: "If it's relevant, I don't see how it is" but I think you've understood what I said...
Anyone knows a trick for replacing zexy/drip, and ggee/concat with internal objects?
[list] equals [concat]
[concat] is concatenating two strings and [list] just puts them together
for exemple [air( and [line( into concat would give "airline" and into list it would give "air line" unless it's possible to remove simply the space between the two strings I don't see how [list] would replace [concat]??
and [list]-abs is a collection of list-operations done with native objects in pd-0.39 and up. Zexy's drip is called list-drip.pd there. (The setable route from above is part of [list]-abs as well where it is called sroute.pd. In the attached patch I made it into a subpatch for simplicity.)
oh yes I never look enough into usefull list-abs! thank again for these abs... patco
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
Hallo, patco hat gesagt: // patco wrote:
Frank Barknecht fbar@footils.org a écrit : patco hat gesagt: // patco wrote:
You can just as well use a [textfile] without ever touching the "file" functionality of it: Just use it as a container for messages like you would use a message box. It's much easier to work with the textfile, because you can rewind it, get messages one by one etc. Attached is how this is done.
okay, that exactly like we can do with a message box but it's more simple with a textfile, true, but textfile needs an external file for keeping values.
I see this as an advantage in most situation, especially with abstractions that want to save their state and that maybe want to save different states per instance. Also with an external file you can use the same patch for playing different pieces.
[list] equals [concat]
[concat] is concatenating two strings and [list] just puts them together
for exemple [air( and [line( into concat would give "airline" and into list it would give "air line" unless it's possible to remove simply the space between the two strings I don't see how [list] would replace [concat]??
Oh, sorry, I thought concat was something else. Well, *that* concat can be emulated by [list-l2s] from [list]-abs. Just pack both strings into one list and send this through list-l2s
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, May 12, 2006 at 07:45:38AM +0200, Frank Barknecht wrote:
Hallo, patco hat gesagt: // patco wrote:
Frank Barknecht fbar@footils.org a écrit : patco hat gesagt: // patco wrote:
You can just as well use a [textfile] without ever touching the "file" functionality of it: Just use it as a container for messages like you would use a message box. It's much easier to work with the textfile, because you can rewind it, get messages one by one etc. Attached is how this is done.
okay, that exactly like we can do with a message box but it's more simple with a textfile, true, but textfile needs an external file for keeping values.
I see this as an advantage in most situation, especially with abstractions that want to save their state and that maybe want to save different states per instance. Also with an external file you can use the same patch for playing different pieces.
But it kind of sucks that those of us who would like to use abstractions, but still save our state data with our patches, have no choice in the matter. Although since sssad, saving data separately has been growing on me.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
But it kind of sucks that those of us who would like to use abstractions, but still save our state data with our patches, have no choice in the matter. Although since sssad, saving data separately has been growing on me.
But you can always save a [loadbang] ---> [load state file somehow( construct in your patch.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I can understand not wanting lots of dependencies, tho Pd-extended makes its quite easy to manage lots of deps. But it seems backwards to me to actively avoid using libraries. What we should be doing is building up librarise of useful code so that we don't have to reinvent the wheel to write a patch. I would like to see these libraries written in Pd.
But even if they are written in Pd, they will be "external" to your projects. So instead of trying to limit yourself to a small set of objects, I think we should be looking to make a complete set of primitives in C for things that can only be done in C, then everything else should be built in Pd.
These objects, which are basically the same as externals, would ideally be organized into coherent libraries so that they would be easy to use and manage.
just my two bits.
.hc
On Wed, 10 May 2006, patco wrote:
Hi, next step in my crusader for replacing externals with native objects will be about replacing memento with ssad, textfile for this stuff is obviously necessary, thank you, Frank, for this great work.
I keep on saying that using a message box is more usefull for fixed memory settings, like in the GOP menu patch submitted before, than being in need of a textfile.
Any memory used for things that doesn't need to be saved under a preset, have absolutely no reason to be in an external file, it's irrelevant.
If it's relevant, but I don't see how it is.
Anyone knows a trick for replacing zexy/drip, and ggee/concat with internal objects?
Frank Barknecht fbar@footils.org a écrit : I would really recommend to take a look at [sssad]: For a simple general purpose state saving it is much more flexible than the solutions above and still only uses builtin objects (with pd 0.39).
if you use various [textfile]s to do the actual state management with sssad or if you wouldn't mind to access the harddisk with preset-switching it even allows storing different presets, not just a "snapshot" of the current state of things, which is the original motivation of [sssad]. I attached a little example how to do this.
Here I would recommend to use a [textfile] instead of the message box. It's quicker than changing the message box all the time, and the messages to [textfile] are very similar to those you send to a message box.
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
zen
\
\
\[D[D[D[D
Yes, Frank!!! I was just wondering if this was possible with SSAD, since I want to do more of an automation/tracking thing with it, rather than just presets (although those are nice as well).
I can't look at it until I get done doing some more schoolwork (wrapping up finals week and graduating on Saturday, finally), but it sounds like what I was looking for!
~Kyle
On 5/10/06, Frank Barknecht fbar@footils.org wrote:
Hallo,
if you use various [textfile]s to do the actual state management with
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 5/10/06, Frank Barknecht fbar@footils.org wrote:
Hallo,
if you use various [textfile]s to do the actual state management with
I can't find the original mail, but that presets thing with the hradio for save and load (sssad-example.pd from a few mails ago) is the coolest thing ever. Thanks for making my life easier!
Chris.
chris@mccormick.cx http://mccormick.cx
Anyone knows how could I replace [popup] or [widget menubutton]?
The following patches shows memory with messages in action, it replaces popup menus
litememory.pd
#N canvas 274 215 434 479 10; #X obj 9 12 inlet; #X msg 214 211 addcomma; #X msg 116 170 set; #X obj 116 148 spigot 1; #X msg 123 125 0; #X obj 71 102 t b a b b b; #X msg 159 126 1; #X obj 159 103 r $1-init; #X obj 226 385 ==; #X obj 132 429 spigot; #X obj 132 450 outlet; #X obj 292 216 inlet; #X obj 129 324 list split 1; #X obj 314 47 route clear; #X obj 321 135 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 86 212 list prepend add2; #X obj 129 404 list append; #X obj 86 238 list trim; #X obj 284 252 t b b a; #X obj 129 346 t b a; #X obj 86 271 s $1-msg-in; #X obj 129 300 r $1-msg-out; #X connect 0 0 5 0; #X connect 0 0 13 0; #X connect 1 0 20 0; #X connect 2 0 20 0; #X connect 3 0 2 0; #X connect 4 0 3 1; #X connect 5 1 15 0; #X connect 5 2 4 0; #X connect 5 3 3 0; #X connect 5 4 1 0; #X connect 6 0 3 1; #X connect 7 0 6 0; #X connect 8 0 9 1; #X connect 9 0 10 0; #X connect 11 0 18 0; #X connect 12 0 19 0; #X connect 12 1 16 1; #X connect 13 0 14 0; #X connect 14 0 2 0; #X connect 15 0 17 0; #X connect 16 0 9 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 18 2 8 1; #X connect 19 0 16 0; #X connect 19 1 8 0; #X connect 21 0 12 0;
menu.pd
#N canvas 167 197 542 392 10; #X obj 0 0 cnv 15 80 20 empty $1-menu-cnv empty 30 12 1 8 -233017 -1 0; #X floatatom 2 3 2 1 99 0 - - -; #X obj 286 30 inlet; #X obj 21 230 outlet; #X obj 215 28 r $1-menu; #X obj 184 292 s $1-menu-cnv; #X msg 184 227 label $1; #X obj 286 56 list trim; #X msg 308 133 clear; #X obj 184 197 symbol; #X obj 286 89 route add index clear; #X obj 184 176 litememory $1; #X msg 346 194 label; #X connect 1 0 3 0; #X connect 1 0 11 1; #X connect 2 0 7 0; #X connect 4 0 7 0; #X connect 6 0 5 0; #X connect 7 0 10 0; #X connect 8 0 11 0; #X connect 9 0 6 0; #X connect 10 0 11 0; #X connect 10 1 1 0; #X connect 10 2 8 0; #X connect 10 2 12 0; #X connect 11 0 9 0; #X connect 12 0 5 0; #X coords 0 -1 1 1 80 20 1 0 0;
menu-test.pd
#N canvas 469 231 466 402 10; #X msg 137 31 add 1 dog , add 2 cat , add 3 test; #X floatatom 92 46 2 0 0 0 - - -; #X msg 93 75 index $1; #X msg 176 75 clear; #X text 149 14 fill the menu first; #X obj 166 194 menu test; #X text 171 57 clear the menu content; #X text 208 100 save the menu content; #N canvas 0 0 474 324 array 0; #X obj 105 32 r test-msg-in; #X obj 102 121 s test-msg-out; #X msg 107 74; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 259 197 pd array; #X obj 212 145 s pd-menu-test.pd; #X text 259 181 menu content is here; #X obj 51 165 s test-menu; #X floatatom 45 99 2 0 0 0 - - -; #X msg 46 128 index $1; #X msg 212 121 menusave; #X text 43 324 just don't forget to associate an array subpatch with the send-receive objects in the same patch , like in this example. ; #X text 175 176 menu <test>; #X text 41 262 creation arguments: menu <name of the menu>; #X text 42 291 with this method you can put several different menus in the same patch; #X connect 0 0 5 0; #X connect 1 0 2 0; #X connect 2 0 5 0; #X connect 3 0 5 0; #X connect 12 0 13 0; #X connect 13 0 11 0; #X connect 14 0 9 0;
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Cliquez ici.
Patco~
Very nice setup: it's clean and easy to understand through the modular code. I think that this is a really useful thing, even if using textfiles is easier. I'd like to see futher uses, but it will be fun to play with, now that I don't have to bother with schooling for awhile!
~Kyle
On 5/10/06, patco megalegoland@yahoo.fr wrote:
Anyone knows how could I replace [popup] or [widget menubutton]?
The following patches shows memory with messages in action, it replaces popup menus
litememory.pd
#N canvas 274 215 434 479 10;
#X obj 9 12 inlet; #X msg 214 211 addcomma; #X msg 116 170 set; #X obj 116 148 spigot 1; #X msg 123 125 0; #X obj 71 102 t b a b b b; #X msg 159 126 1; #X obj 159 103 r $1-init;
#X obj 226 385 ==; #X obj 132 429 spigot; #X obj 132 450 outlet; #X obj 292 216 inlet; #X obj 129 324 list split 1; #X obj 314 47 route clear; #X obj 321 135 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 86 212 list prepend add2;
#X obj 129 404 list append; #X obj 86 238 list trim;
#X obj 284 252 t b b a; #X obj 129 346 t b a; #X obj 86 271 s $1-msg-in; #X obj 129 300 r $1-msg-out;
#X connect 0 0 5 0; #X connect 0 0 13 0; #X connect 1 0 20 0; #X connect 2 0 20 0;
#X connect 3 0 2 0; #X connect 4 0 3 1; #X connect 5 1 15 0;
#X connect 5 2 4 0; #X connect 5 3 3 0; #X connect 5 4 1 0; #X connect 6 0 3 1;
#X connect 7 0 6 0; #X connect 8 0 9 1; #X connect 9 0 10 0; #X connect 11 0 18 0;
#X connect 12 0 19 0; #X connect 12 1 16 1; #X connect 13 0 14 0; #X connect 14 0 2 0; #X connect 15 0 17 0; #X connect 16 0 9 0;
#X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 18 2 8 1; #X connect 19 0 16 0; #X connect 19 1 8 0; #X connect 21 0 12 0;
menu.pd
#N canvas 167 197 542 392 10; #X obj 0 0 cnv 15 80 20 empty $1-menu-cnv empty 30 12 1 8 -233017 -1 0; #X floatatom 2 3 2 1 99 0 - - -; #X obj 286 30 inlet; #X obj 21 230 outlet; #X obj 215 28 r $1-menu; #X obj 184 292 s $1-menu-cnv; #X msg 184 227 label $1; #X obj 286 56 list trim; #X msg 308 133 clear; #X obj 184 197 symbol; #X obj 286 89 route add index clear; #X obj 184 176 litememory $1; #X msg 346 194 label;
#X connect 1 0 3 0; #X connect 1 0 11 1;
#X connect 2 0 7 0; #X connect 4 0 7 0; #X connect 6 0 5 0; #X connect 7 0 10 0; #X connect 8 0 11 0;
#X connect 9 0 6 0; #X connect 10 0 11 0; #X connect 10 1 1 0; #X connect 10 2 8 0; #X connect 10 2 12 0; #X connect 11 0 9 0; #X connect 12 0 5 0; #X coords 0 -1 1 1 80 20 1 0 0;
menu-test.pd
#N canvas 469 231 466 402 10; #X msg 137 31 add 1 dog , add 2 cat , add 3 test; #X floatatom 92 46 2 0 0 0 - - -; #X msg 93 75 index $1; #X msg 176 75 clear; #X text 149 14 fill the menu first; #X obj 166 194 menu test; #X text 171 57 clear the menu content; #X text 208 100 save the menu content; #N canvas 0 0 474 324 array 0; #X obj 105 32 r test-msg-in; #X obj 102 121 s test-msg-out; #X msg 107 74; #X connect 0 0 2 0;
#X connect 2 0 1 0; #X restore 259 197 pd array; #X obj 212 145 s pd-menu-test.pd; #X text 259 181 menu content is here; #X obj 51 165 s test-menu; #X floatatom 45 99 2 0 0 0 - - -; #X msg 46 128 index $1; #X msg 212 121 menusave; #X text 43 324 just don't forget to associate an array subpatch with the send-receive objects in the same patch , like in this example. ; #X text 175 176 menu <test>; #X text 41 262 creation arguments: menu <name of the menu>; #X text 42 291 with this method you can put several different menus in the same patch; #X connect 0 0 5 0; #X connect 1 0 2 0;
#X connect 2 0 5 0; #X connect 3 0 5 0; #X connect 12 0 13 0; #X connect 13 0 11 0; #X connect 14 0 9 0;
Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Cliquez ici.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
Kyle Klipowicz -
patco