Re: [PD] self-modifying and dynamic patching
I have an old patch called nm-grainer that used an earlier version of nqpoly to do granular synthesis using a self modifying patch to do variable polyphony. http://soundsorange.net/cmsimple/index.php?projects:nm-grainer_granular_synthesis_patch_for_Pd http://puredata.info/Members/nmariette/nm-grainer-description/?searchterm=nm-grainer Nick On Mar 11, 2009, at 6:55 PM, Derek Holzer wrote: Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 163: "Turn it upside down" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
i received this rationale from miller not too long ago for the hesitation in including iohannes' methods: "Anyhow, I'm trying to think of a better mechanism for allowing abstractions to have variable numbers of inlets/outlets, so I'm hoping initbang won't be necessary in the long run. closebang, though, will probably be needed in some form or other." so it's obviously still a work in progress, regardless initbang/closebang are at least fairly consistent with constructor/destructor methods in other languages. we'll see where this goes. cheers, dmotd IOhannes m zmölnig wrote: > Charles Henry wrote: > > There is a way to write the code for a "new" or "create" routine in > > your class via [loadbang], > > where did you get that impression from? > [loadbang] does _not_ work as a constructor (it's too late). > that's why i had written [initbang], which unfortunately never made it > into Pd. > > > so you need a way to code a "free" or > > "delete" routine as well. > > that's why i had written [closebang], which (surprise!) never made it > into Pd either > > > mfga.s > IOhannes > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Sat, 14 Mar 2009, IOhannes m zmölnig wrote: where did you get that impression from? [loadbang] does _not_ work as a constructor (it's too late). that's why i had written [initbang], which unfortunately never made it into Pd. so you need a way to code a "free" or "delete" routine as well. that's why i had written [closebang], which (surprise!) never made it into Pd either Well, you could start a fund for this feature on paypal, the Miller-SourceForge Bug Ticket Denial-of-Service Attack Fund (MSFBTDoSAF). Because if someone doesn't understand, then maybe the message has to be repeated. kidding, of course. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Charles Henry wrote: > > There is a way to write the code for a "new" or "create" routine in > your class via [loadbang], where did you get that impression from? [loadbang] does _not_ work as a constructor (it's too late). that's why i had written [initbang], which unfortunately never made it into Pd. > so you need a way to code a "free" or > "delete" routine as well. that's why i had written [closebang], which (surprise!) never made it into Pd either mfga.s IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Thu, Mar 12, 2009 at 6:21 PM, Luke Iannini wrote: > Yes, the better solution methinks would be a vanilla* "savebang" to > clear out the dynamic subpatch just before save. But I suppose that > requires acknowledging dynamic patching. > > lxi > > *the [tot]-based method just does not work reliably To mention programming languages, here (I wouldn't propose to open this can of worms, but to look at the options for a more complete programming style in Pd) I think this makes sense from a programming languages point of view. If you're creating a dynamic-based abstraction, it should be analogous to writing a class. There is a way to write the code for a "new" or "create" routine in your class via [loadbang], so you need a way to code a "free" or "delete" routine as well. A selective-save feature would be a more pragmatic approach for Pd users. I think of data-structures in C, where you add a pointer in your struct. You can later dynamically allocate memory for an array and set the pointer, but the structure itself does not include the dynamically created array. However, I think that coding a new method would be expensive and problematic. What set of operations is necessary to be able to create dynamic patching capability? Do you think there's a top-down design based approach to outline the necessary principles for it? Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
See also [panN~] in xjimmies for an example of simple dynamically built abstraction that adapts to the number of channels you need for panning. ./MiS ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Thu, 12 Mar 2009, IOhannes m zmoelnig wrote: however, my experiences with abcde were the main reason i s did not touch self-modifying patches for years and years. the lesson i learned was: never do self-modification in patches that other people will ever have to regularily use. (the original phrase would have been "never do self-modification in patches that other people will ever have to maintain"; however, this might give the impression that chances are low that somebody else will really have to "maintain" a patch); in practice you pass maintainership to somebody as soon as you give them your patch: they will eventually start to modify it. Because self-modifying patches are more tricky and complicated than most other things, it's especially important to aggressively abstract them. If you can, you abstract them in a way that each self-modifying abstraction represents an elementary pattern that no-one will want to modify, because it's too basic and fundamental, and so there's nothing that one could possibly want to customise about them. Therefore all the aspects that make sense to customise will be in abstractions that themselves are not self-modifying, because they use elementary self-modifying abstractions instead. But that's not always easy to do or feasible. This concept can also be useful with lots more things than just self-modifying patches, but it's with self-modifying patches that there is the most payoff. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Yeah, parazit was one of them! Thx! D. Hans-Christoph Steiner wrote: Perhaps you are thinking of parazit and pure. parazit is an object included in Pd-extended. And you can get Gerard Van Dongen's pure here: http://itp.nyu.edu/dataflow/uploads/tgb-pure.tar.gz .hc On Mar 12, 2009, at 8:47 AM, Derek Holzer wrote: Hi all and thanks for chiming in on this thread. There was once, long ago, a simple mixer which dynamically created the busses and channels. If anyone can remember that one, it must have been 5 years ago, and was the first dynamic patch I had ever seen. Also fun, non-utilitarian ones, like once someone sent some kind of "card" to the list which just made a huge self-generating GUI art-mess on the screen. I wish I could remember who wrote it. Lastly, IOhannes showed a very nice self-modifying patch at Piksel last December using iemguts. best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 130: "Question the heroic" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 63: "Don't break the silence" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
hey derek.. attached is the dynamic GOP abstraction [mtx_tog], used as an extension to iemmatrix lib. it's a viewer/editor for simple binary matrices. it may be useful in your presentation as it uses [namecanvas] to edit the top level GOP. the actual code should be fairly readable and straight forward, although the logic is a little complex. i have attached the help file and a little example that generates a 16x4 step sequencer. obviously it requires the iemmatrix library to function (although it should still render the grid without). i haven't relied on this too heavily in the past so it may be buggy.. as with all dynamic patching (especially GOP/namecanvas) use with caution! cheers, dmotd On Thursday 12 March 2009 03:55:21 Derek Holzer wrote: > Would like to show some examples of dynamic and self-modifying Pd > patches during a workshop here in Berlin. I know there are some in the > archives (and maybe on people's HDs) somewhere, but damned if I can find > them. Links to previkous posts or new examples welcome! > > best! > Derek #N canvas 99 276 450 300 10; #X floatatom 241 79 4 0 0 0 - - -; #X msg 242 98 column \$1; #X msg 66 82 matrix 2 2 1 1 1 1; #X obj 149 241 unpack 0 0 0 0; #X obj 150 265 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 173 267 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 205 268 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 241 266 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 64 210 route matrix; #X floatatom 241 35 5 0 0 0 - - -; #X obj 64 133 mtx_tog 4 16; #N canvas 0 0 450 300 count[16] 0; #X obj 77 129 metro 100; #X obj 78 161 f; #X obj 111 158 + 1; #X obj 139 174 >= 16; #X msg 140 214 0; #X obj 140 194 sel 1; #X obj 176 98 inlet; #X obj 92 35 inlet; #X obj 94 61 moses 0; #X msg 101 84 1; #X floatatom 149 14 5 0 0 0 - - -; #X msg 93 104 0; #X obj 71 200 outlet; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 1 1; #X connect 2 0 3 0; #X connect 2 0 12 0; #X connect 3 0 5 0; #X connect 4 0 1 1; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 7 0 8 0; #X connect 8 0 11 0; #X connect 8 1 9 0; #X connect 8 1 0 1; #X connect 9 0 0 0; #X connect 10 0 8 0; #X connect 11 0 0 0; #X restore 240 56 pd count[16]; #X text 282 34 <- step (msec); #X connect 0 0 1 0; #X connect 1 0 10 0; #X connect 2 0 10 0; #X connect 3 0 4 0; #X connect 3 1 5 0; #X connect 3 2 6 0; #X connect 3 3 7 0; #X connect 8 1 3 0; #X connect 9 0 11 0; #X connect 10 0 8 0; #X connect 11 0 0 0; #N canvas 129 0 450 326 10; #X obj 324 251 mtx_print; #X obj 324 229 matrix; #X obj 45 110 mtx_eye 8; #X obj 46 89 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 323 207 spigot; #X obj 374 188 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 244 48 print 1; #X msg 256 67 print 0; #X text 263 86 print (including \$0 arg); #X text 34 283 warning! can choke pd when building larger matrices ; #X text 33 9 [mtx_tog] is a binary viewer/editor abs for iemmatrix ; #X text 292 299 (c) 2006 dmotd; #X obj 244 177 mtx_tog 2 2; #X obj 241 105 mtx_tog 4 4; #X obj 46 138 mtx_tog 8 8; #X obj 246 220 mtx_tog 3 1; #X obj 212 176 mtx_tog 3 1; #X text 65 28 usage: [mtx_tog m n]; #X text 65 46 where m = rows; #X text 79 65 and n = columns; #X connect 1 0 0 0; #X connect 2 0 14 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 5 0 4 1; #X connect 6 0 13 0; #X connect 7 0 13 0; #X connect 12 0 4 0; #X connect 12 0 15 0; #X connect 13 0 12 0; #X connect 13 0 16 0; #N canvas 100 82 373 383 10; #N canvas 317 180 450 300 \$0-subpatch 0; #X obj 0 0 tgl 15 0 1011_1_1_send 1011_1_1_receive empty 17 7 0 10 -262144 -1 -1 0 1; #X coords 0 -1 1 1 15 15 2 0 0; #X restore 0 50 pd \$0-subpatch; #N canvas 167 102 450 300 edit_mtx 0; #X obj 41 46 r \$0-matrix; #X obj 72 236 outlet; #X obj 286 174 spigot; #X obj 322 128 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 320 99 inlet; #X obj 166 24 inlet; #X obj 178 115 mtx_check; #N canvas 67 97 523 386 mtx_set 0; #N canvas 18 295 450 300 doit 0; #X obj 88 62 until; #X obj 88 90 f; #X obj 119 92 + 1; #X obj 163 92 sel 0; #X obj 117 119 mod 5; #X obj 90 32 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 161 343 450 300 count 0; #X obj 85 15 inlet; #X obj 219 108 f; #X obj 276 104 + 1; #X msg 194 75 bang; #X floatatom 277 138 5 0 0 0 - - -; #X msg 263 77 0; #X obj 212 181 select 1; #X obj 230 147 < 5; #X obj 278 4 inlet; #X obj 299 43 int; #X obj 197 242 outlet; #X obj 300 263 outlet; #X obj 211 208 del 10; #X obj 269 207 del 11; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 1 1; #X connect 2 0 4 0; #X connect 2 0 7 0; #X connect 2 0 10 0; #X connect 3 0 1 0; #X connect 5 0 1 1; #X connect 6 0 12 0; #X connect 6 1 13 0; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 9 0 7 1; #X connect 12 0 1 0; #X connect 13 0 5 0; #X connect 13 0 11 0; #X restore 159 -23 pd count; #X obj 157 -47 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatato
Re: [PD] self-modifying and dynamic patching
ah, forgot, a very simple one: dacm~, also in /jmmmp (in a recent night build) Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Perhaps you are thinking of parazit and pure. parazit is an object included in Pd-extended. And you can get Gerard Van Dongen's pure here: http://itp.nyu.edu/dataflow/uploads/tgb-pure.tar.gz .hc On Mar 12, 2009, at 8:47 AM, Derek Holzer wrote: Hi all and thanks for chiming in on this thread. There was once, long ago, a simple mixer which dynamically created the busses and channels. If anyone can remember that one, it must have been 5 years ago, and was the first dynamic patch I had ever seen. Also fun, non-utilitarian ones, like once someone sent some kind of "card" to the list which just made a huge self-generating GUI art- mess on the screen. I wish I could remember who wrote it. Lastly, IOhannes showed a very nice self-modifying patch at Piksel last December using iemguts. best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 130: "Question the heroic" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Mar 11, 2009, at 8:26 PM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: polypoly and nqpoly4 are good examples. nqpoly4 is in Pd-extended, you can get polypoly here: http://itp.nyu.edu/dataflow/uploads/polypoly.zip Isn't polypoly also in pd-extended? Anyway the reference location is the pd subversion in: /trunk/abstractions/footils/foo/ polypoly is not included in Pd-extended. Newbies find downloading from svn daunting so I provided the zip. It would be even better if there was an official release. .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Thu, Mar 12, 2009 at 12:03 PM, Mathieu Bouchard wrote: > On Thu, 12 Mar 2009, Frank Barknecht wrote: > >> A loadbanged [; pd-subpatch clear( IMO is mandatory for dynamic patching >> in >> abstractions. Even if it's saved with old content that will be removed on >> the >> next load. > > It's not sufficient because you could be getting error messages from > dynamically patched abstractions, or other strange behaviour. For example, > if I make an [#out window], or an [#out] to which I send "open window", then > on next load of any [#out] you will see a window open, and on any [#out > window] you will see a window open, close, and open again. In other > circumstances, I could get a "no such directory" error everytime I load, > because I saved [#out] while it was writing a movie, and the directory has > been renamed or removed or it's just a different machine... Yes, the better solution methinks would be a vanilla* "savebang" to clear out the dynamic subpatch just before save. But I suppose that requires acknowledging dynamic patching. lxi *the [tot]-based method just does not work reliably > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Thu, 12 Mar 2009, Frank Barknecht wrote: A loadbanged [; pd-subpatch clear( IMO is mandatory for dynamic patching in abstractions. Even if it's saved with old content that will be removed on the next load. It's not sufficient because you could be getting error messages from dynamically patched abstractions, or other strange behaviour. For example, if I make an [#out window], or an [#out] to which I send "open window", then on next load of any [#out] you will see a window open, and on any [#out window] you will see a window open, close, and open again. In other circumstances, I could get a "no such directory" error everytime I load, because I saved [#out] while it was writing a movie, and the directory has been renamed or removed or it's just a different machine... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Hallo, Phil Stone hat gesagt: // Phil Stone wrote: > I may not be thinking this through correctly, but how do you handle > broken connections with inlets/outlets in the cleared subpatch? I.e., > the containing patch will lose its patch connections to the > inlets/outlets of the subpatch if the sbupatch is cleared. Just don't use any inlets and outlets! ;) I use [r $0-inlet] and [s $0-outlet] in the subpatch instead. See polypoly for an example of this "fake xlet" approach. Ciao -- Frnak ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
I may not be thinking this through correctly, but how do you handle broken connections with inlets/outlets in the cleared subpatch? I.e., the containing patch will lose its patch connections to the inlets/outlets of the subpatch if the sbupatch is cleared. Phil With certain clean patching habits it's not that bad. For example the original nqpoly4 was rather messy because it did the dynamic patching in the abstraction itself, used namcanvas for it and thus relied on a certain initial state. What I changed was to remove namcanvas, do the dynamic patching inside of a subpatch and started with clearing that patch from a loadbang. A loadbanged [; pd-subpatch clear( IMO is mandatory for dynamic patching in abstractions. Even if it's saved with old content that will be removed on the next load. Another use for dynamic patching is automatically creating parts of static patches. For example my piece "Frost" on the GOSUB10 netlabel release uses 60 resonant bandpass filters driven by noise bursts. Of course I didn't patch all of these manually and changed their arguments, instead I used dynamic patching to generate the filter bank once, which then was saved into a static patch. In that use case, one should not use a loadbang'd clear of course. ;) To add another example: I use dynamic patching in the list-abs-intro.pd patch to generate a list of all list-abs in the [list]-abs collection. Ciao ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Hallo, Phil Stone hat gesagt: // Phil Stone wrote: > Good point; I assume you're going to emphasize the pitfalls of dynamic > patching while you're at it, Derek? I have a habit of opening up > patches to see how they work, and if I can't read them because they're > too messy, I'll move stuff around. This is fine, unless it's a dynamic > patch and I hit "ctrl-s" without thinking. D'oh! The initial state of > a dynamic patch is critical to its correct function, and one has to > think very carefully before saving changes. I think I'm going to > develop the habit of putting a large warning comment on any > self-modifying patch. With certain clean patching habits it's not that bad. For example the original nqpoly4 was rather messy because it did the dynamic patching in the abstraction itself, used namcanvas for it and thus relied on a certain initial state. What I changed was to remove namcanvas, do the dynamic patching inside of a subpatch and started with clearing that patch from a loadbang. A loadbanged [; pd-subpatch clear( IMO is mandatory for dynamic patching in abstractions. Even if it's saved with old content that will be removed on the next load. Another use for dynamic patching is automatically creating parts of static patches. For example my piece "Frost" on the GOSUB10 netlabel release uses 60 resonant bandpass filters driven by noise bursts. Of course I didn't patch all of these manually and changed their arguments, instead I used dynamic patching to generate the filter bank once, which then was saved into a static patch. In that use case, one should not use a loadbang'd clear of course. ;) To add another example: I use dynamic patching in the list-abs-intro.pd patch to generate a list of all list-abs in the [list]-abs collection. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Phil Stone wrote: Good point; I assume you're going to emphasize the pitfalls of dynamic patching while you're at it, Derek? I have a habit of opening up patches to see how they work, and if I can't read them because they're too messy, I'll move stuff around. This is fine, unless it's a dynamic patch and I hit "ctrl-s" without thinking. D'oh! The initial state of a dynamic patch is critical to its correct function, and one has to think very carefully before saving changes. I think I'm going to develop the habit of putting a large warning comment on any self-modifying patch. i did that, to no avail :-) f gamsdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Good point; I assume you're going to emphasize the pitfalls of dynamic patching while you're at it, Derek? I have a habit of opening up patches to see how they work, and if I can't read them because they're too messy, I'll move stuff around. This is fine, unless it's a dynamic patch and I hit "ctrl-s" without thinking. D'oh! The initial state of a dynamic patch is critical to its correct function, and one has to think very carefully before saving changes. I think I'm going to develop the habit of putting a large warning comment on any self-modifying patch. Phil IOhannes m zmoelnig wrote: however, my experiences with abcde were the main reason i s did not touch self-modifying patches for years and years. the lesson i learned was: never do self-modification in patches that other people will ever have to regularily use. (the original phrase would have been "never do self-modification in patches that other people will ever have to maintain"; however, this might give the impression that chances are low that somebody else will really have to "maintain" a patch); in practice you pass maintainership to somebody as soon as you give them your patch: they will eventually start to modify it. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Hi Derek i made a mixer for netpd once, that dynamically creates channels and fx-bus. it uses the whole netpd framework, statesaving etc. http://www.netpd.org/Mx if you have already a netpd synth it's quite easy to plugin to the mx, something like that: [osc~] |\ [i2mx~ $0 yourInstrumentName] but: it only works with netpd :) but2: there seems to be a problem with pd-0.42, that i will fix soon. eni Derek Holzer wrote: Hi all and thanks for chiming in on this thread. There was once, long ago, a simple mixer which dynamically created the busses and channels. If anyone can remember that one, it must have been 5 years ago, and was the first dynamic patch I had ever seen. Also fun, non-utilitarian ones, like once someone sent some kind of "card" to the list which just made a huge self-generating GUI art-mess on the screen. I wish I could remember who wrote it. Lastly, IOhannes showed a very nice self-modifying patch at Piksel last December using iemguts. best! Derek ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
hi, just updated the video showing voice patching in pure data. i am now using dyn~ (thank you thomas grill for your externals). http://www.vimeo.com/2814913 lower your volume when you hear "send, 1, 400". pat ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
small stuff in the /jmmmp folder (if you have a night build from the last weeks), but more using data structures and namecanvasdialog. maybe not really total dynamic - sliders - pdcolors - there's a color matrix for data-s Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
hey derek.. i've done some hunting on your behalf, and i think i've found what you are referring to.. a patch created by leonard swiezinski in 2002: http://lists.puredata.info/pipermail/pd-list/2002-03/004940.html alas, the link is a 404.. and mr. swiezinski has been inactive for several years. although he does still own the parent site floppy35.de.. markmail.com is useful ;) ciao, dmotd ps.. i have numerous experiments in dyn-pd on old hard-disk-drives.. wouldn't be too difficult to dig through, but i am sure you will find plenty of examples.. On Thursday 12 March 2009 19:15:24 Derek Holzer wrote: > Thx IOhannes, > > IOhannes m zmoelnig wrote: > > Derek Holzer wrote: > >> Hi all and thanks for chiming in on this thread. There was once, long > >> ago, a simple mixer which dynamically created the busses and channels. > >> If anyone can remember that one, it must have been 5 years ago, and > >> was the first dynamic patch I had ever seen. > > > > could be my "abcde(fg)", the great "ambisonics-based coding and decoding > > environment (for graz)". > > you can get it here: > > http://iem.svn.sourceforge.net/viewvc/iem/spatialization/abcde/ > > It was something less complex than this I think. Just a mixer with > dynamic creation of channels. It was very green, IIRC ;-) > > D. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Thx IOhannes, IOhannes m zmoelnig wrote: Derek Holzer wrote: Hi all and thanks for chiming in on this thread. There was once, long ago, a simple mixer which dynamically created the busses and channels. If anyone can remember that one, it must have been 5 years ago, and was the first dynamic patch I had ever seen. could be my "abcde(fg)", the great "ambisonics-based coding and decoding environment (for graz)". you can get it here: http://iem.svn.sourceforge.net/viewvc/iem/spatialization/abcde/ It was something less complex than this I think. Just a mixer with dynamic creation of channels. It was very green, IIRC ;-) D. -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 185: "Which parts can be grouped?" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Derek Holzer wrote: Hi all and thanks for chiming in on this thread. There was once, long ago, a simple mixer which dynamically created the busses and channels. If anyone can remember that one, it must have been 5 years ago, and was the first dynamic patch I had ever seen. could be my "abcde(fg)", the great "ambisonics-based coding and decoding environment (for graz)". you can get it here: http://iem.svn.sourceforge.net/viewvc/iem/spatialization/abcde/ however, my experiences with abcde were the main reason i s did not touch self-modifying patches for years and years. the lesson i learned was: never do self-modification in patches that other people will ever have to regularily use. (the original phrase would have been "never do self-modification in patches that other people will ever have to maintain"; however, this might give the impression that chances are low that somebody else will really have to "maintain" a patch); in practice you pass maintainership to somebody as soon as you give them your patch: they will eventually start to modify it. having said that, self-modification might work resasonably well with _small_ "atomic" abstractions e.g. implementing a settable [route] via self-modification might be fine, but don't try to do so with core-components of a big application. Also fun, non-utilitarian ones, like once someone sent some kind of "card" to the list which just made a huge self-generating GUI art-mess on the screen. I wish I could remember who wrote it. Lastly, IOhannes showed a very nice self-modifying patch at Piksel last December using iemguts. i'll see what i still have on my disk. being a live-coding session i had not prepared so much "patch" in advance which i could share now... vhmysdrt IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Hi all and thanks for chiming in on this thread. There was once, long ago, a simple mixer which dynamically created the busses and channels. If anyone can remember that one, it must have been 5 years ago, and was the first dynamic patch I had ever seen. Also fun, non-utilitarian ones, like once someone sent some kind of "card" to the list which just made a huge self-generating GUI art-mess on the screen. I wish I could remember who wrote it. Lastly, IOhannes showed a very nice self-modifying patch at Piksel last December using iemguts. best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 130: "Question the heroic" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
the midi controller example is a good one i believe. here is what i did a while ago http://www.netpd.org/Midilearn Am 12.03.2009 um 03:27 schrieb Phil Stone: Hi Derek, Maybe a very simple example would be good. I have an Ozone MIDI- controller, and it has eight knobs, which send out continuous controller data on 8 different MIDI CC numbers. Now, [ctlin] (MIDI control input) doesn't have settable arguments -- only creation args., so I racked my brains trying to figure out how to make an object that would take a knob number argument, 1-8, convert that number to the corresponding controller number, and watch that controller number with [ctlin]. (Admittedly, it would have been easy to create [Ozknob1]...[Ozknob8] objects, but this reeked of kludge to my sensibilities; neither did I consider it elegant to use a [ctlin] for each knob that watched *all* controller data, then [route]d the data from the desired control number -- I wanted the pre-filtering to be done by [ctlin], if possible). The more generalized problem is this: take a creation argument of an abstraction, *do something with it*, then get it into the creation argument of a contained abstraction. Nothing I tried worked, until I took the attached dynamic approach. Phil Stone www.pkstonemusic.com Derek Holzer wrote: Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek #N canvas 676 96 394 341 10; #X obj 8 105 21; #X obj 34 105 22; #X obj 60 105 23; #X obj 86 105 24; #X obj 112 105 25; #X obj 138 105 26; #X obj 164 105 27; #X obj 189 105 28; #X obj 37 74 select 1 2 3 4 5 6 7 8; #X obj 37 51 f \$1; #X obj 37 6 loadbang; #X obj 103 304 outlet; #X text 8 149 Ozone mapping; #X msg 237 93 2; #X text 267 91 channel; #X obj 37 28 t b b; #X obj 102 158 pack f f; #X text 110 16 Use: [OzKnob n] where n is the knob #; #N canvas 0 22 210 111 \$0-oz_ctrlknob 0; #X obj 28 72 outlet; #X restore 103 272 pd \$0-oz_ctrlknob; #X obj 102 218 s pd-\$0-oz_ctrlknob; #X msg 102 187 obj 10 10 ctlin \$1 \$2 \, connect 1 0 0 0; #X connect 0 0 16 0; #X connect 1 0 16 0; #X connect 2 0 16 0; #X connect 3 0 16 0; #X connect 4 0 16 0; #X connect 5 0 16 0; #X connect 6 0 16 0; #X connect 7 0 16 0; #X connect 8 0 0 0; #X connect 8 1 1 0; #X connect 8 2 2 0; #X connect 8 3 3 0; #X connect 8 4 4 0; #X connect 8 5 5 0; #X connect 8 6 6 0; #X connect 8 7 7 0; #X connect 9 0 8 0; #X connect 10 0 15 0; #X connect 13 0 16 1; #X connect 15 0 9 0; #X connect 15 1 13 0; #X connect 16 0 20 0; #X connect 18 0 11 0; #X connect 20 0 19 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list PGP.sig Description: Signierter Teil der Nachricht ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Wed, Mar 11, 2009 at 10:55 AM, Derek Holzer wrote: Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previous posts or new examples welcome! [#in] and [#out] in GridFlow >= 0.9.2. But make sure to pick the latest, as 0.9.2 was quite buggy. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
On Wed, Mar 11, 2009 at 10:55 AM, Derek Holzer wrote: > Would like to show some examples of dynamic and self-modifying Pd patches > during a workshop here in Berlin. I know there are some in the archives (and > maybe on people's HDs) somewhere, but damned if I can find them. Links to > previkous posts or new examples welcome! Here are a few I've done: [hotpack] (in sfruit/ in pd-extended) dynamically builds a [pack] object along with enough [t b a] objects to make every inlet hot. [deeprouteOSC] (ditto) creates a chain of [routeOSC] objects so you can route something like /synth/filter/cutoff instead of making 3 objects. [troute] (ditto) is a settable [route] object, where you can pass a list to its rightmost inlet to change what its routing. [nsend/nreceive] (in nsend/ in pd-extended) gangs sends together, for when you want to send the output of a multi-output object elsewhere (e.g. [nsend 3 $0.notein] creates an nsend with 3 inlets, and [nreceive 3 $0.notein] creates a corresponding nreceive). [hotpack] and [deeprouteOSC] are probably the best balance of complexity vs. utility. Best Luke > > best! > Derek > > -- > ::: derek holzer ::: http://blog.myspace.com/macumbista ::: > http://www.vimeo.com/macumbista ::: > ---Oblique Strategy # 163: > "Turn it upside down" > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > polypoly and nqpoly4 are good examples. nqpoly4 is in Pd-extended, you > can get polypoly here: > > http://itp.nyu.edu/dataflow/uploads/polypoly.zip Isn't polypoly also in pd-extended? Anyway the reference location is the pd subversion in: /trunk/abstractions/footils/foo/ Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
polypoly and nqpoly4 are good examples. nqpoly4 is in Pd-extended, you can get polypoly here: http://itp.nyu.edu/dataflow/uploads/polypoly.zip .hc On Mar 11, 2009, at 3:27 PM, Phil Stone wrote: Hi Derek, Maybe a very simple example would be good. I have an Ozone MIDI- controller, and it has eight knobs, which send out continuous controller data on 8 different MIDI CC numbers. Now, [ctlin] (MIDI control input) doesn't have settable arguments -- only creation args., so I racked my brains trying to figure out how to make an object that would take a knob number argument, 1-8, convert that number to the corresponding controller number, and watch that controller number with [ctlin]. (Admittedly, it would have been easy to create [Ozknob1]...[Ozknob8] objects, but this reeked of kludge to my sensibilities; neither did I consider it elegant to use a [ctlin] for each knob that watched *all* controller data, then [route]d the data from the desired control number -- I wanted the pre-filtering to be done by [ctlin], if possible). The more generalized problem is this: take a creation argument of an abstraction, *do something with it*, then get it into the creation argument of a contained abstraction. Nothing I tried worked, until I took the attached dynamic approach. Phil Stone www.pkstonemusic.com Derek Holzer wrote: Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek #N canvas 676 96 394 341 10; #X obj 8 105 21; #X obj 34 105 22; #X obj 60 105 23; #X obj 86 105 24; #X obj 112 105 25; #X obj 138 105 26; #X obj 164 105 27; #X obj 189 105 28; #X obj 37 74 select 1 2 3 4 5 6 7 8; #X obj 37 51 f \$1; #X obj 37 6 loadbang; #X obj 103 304 outlet; #X text 8 149 Ozone mapping; #X msg 237 93 2; #X text 267 91 channel; #X obj 37 28 t b b; #X obj 102 158 pack f f; #X text 110 16 Use: [OzKnob n] where n is the knob #; #N canvas 0 22 210 111 \$0-oz_ctrlknob 0; #X obj 28 72 outlet; #X restore 103 272 pd \$0-oz_ctrlknob; #X obj 102 218 s pd-\$0-oz_ctrlknob; #X msg 102 187 obj 10 10 ctlin \$1 \$2 \, connect 1 0 0 0; #X connect 0 0 16 0; #X connect 1 0 16 0; #X connect 2 0 16 0; #X connect 3 0 16 0; #X connect 4 0 16 0; #X connect 5 0 16 0; #X connect 6 0 16 0; #X connect 7 0 16 0; #X connect 8 0 0 0; #X connect 8 1 1 0; #X connect 8 2 2 0; #X connect 8 3 3 0; #X connect 8 4 4 0; #X connect 8 5 5 0; #X connect 8 6 6 0; #X connect 8 7 7 0; #X connect 9 0 8 0; #X connect 10 0 15 0; #X connect 13 0 16 1; #X connect 15 0 9 0; #X connect 15 1 13 0; #X connect 16 0 20 0; #X connect 18 0 11 0; #X connect 20 0 19 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] self-modifying and dynamic patching
Hi Derek, Maybe a very simple example would be good. I have an Ozone MIDI-controller, and it has eight knobs, which send out continuous controller data on 8 different MIDI CC numbers. Now, [ctlin] (MIDI control input) doesn't have settable arguments -- only creation args., so I racked my brains trying to figure out how to make an object that would take a knob number argument, 1-8, convert that number to the corresponding controller number, and watch that controller number with [ctlin]. (Admittedly, it would have been easy to create [Ozknob1]...[Ozknob8] objects, but this reeked of kludge to my sensibilities; neither did I consider it elegant to use a [ctlin] for each knob that watched *all* controller data, then [route]d the data from the desired control number -- I wanted the pre-filtering to be done by [ctlin], if possible). The more generalized problem is this: take a creation argument of an abstraction, *do something with it*, then get it into the creation argument of a contained abstraction. Nothing I tried worked, until I took the attached dynamic approach. Phil Stone www.pkstonemusic.com Derek Holzer wrote: Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek #N canvas 676 96 394 341 10; #X obj 8 105 21; #X obj 34 105 22; #X obj 60 105 23; #X obj 86 105 24; #X obj 112 105 25; #X obj 138 105 26; #X obj 164 105 27; #X obj 189 105 28; #X obj 37 74 select 1 2 3 4 5 6 7 8; #X obj 37 51 f \$1; #X obj 37 6 loadbang; #X obj 103 304 outlet; #X text 8 149 Ozone mapping; #X msg 237 93 2; #X text 267 91 channel; #X obj 37 28 t b b; #X obj 102 158 pack f f; #X text 110 16 Use: [OzKnob n] where n is the knob #; #N canvas 0 22 210 111 \$0-oz_ctrlknob 0; #X obj 28 72 outlet; #X restore 103 272 pd \$0-oz_ctrlknob; #X obj 102 218 s pd-\$0-oz_ctrlknob; #X msg 102 187 obj 10 10 ctlin \$1 \$2 \, connect 1 0 0 0; #X connect 0 0 16 0; #X connect 1 0 16 0; #X connect 2 0 16 0; #X connect 3 0 16 0; #X connect 4 0 16 0; #X connect 5 0 16 0; #X connect 6 0 16 0; #X connect 7 0 16 0; #X connect 8 0 0 0; #X connect 8 1 1 0; #X connect 8 2 2 0; #X connect 8 3 3 0; #X connect 8 4 4 0; #X connect 8 5 5 0; #X connect 8 6 6 0; #X connect 8 7 7 0; #X connect 9 0 8 0; #X connect 10 0 15 0; #X connect 13 0 16 1; #X connect 15 0 9 0; #X connect 15 1 13 0; #X connect 16 0 20 0; #X connect 18 0 11 0; #X connect 20 0 19 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] self-modifying and dynamic patching
Would like to show some examples of dynamic and self-modifying Pd patches during a workshop here in Berlin. I know there are some in the archives (and maybe on people's HDs) somewhere, but damned if I can find them. Links to previkous posts or new examples welcome! best! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 163: "Turn it upside down" ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
