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

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

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

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.

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

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

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

On Thu, Mar 12, 2009 at 6:21 PM, Luke Iannini lukexipd@gmail.com 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

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

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

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

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

On Wed, Mar 11, 2009 at 10:55 AM, Derek Holzer derek@umatic.nl 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

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