Hello,

you've described explicitely the reasons why I don't use abstractions in a dynamic patching project, at least the audio part. The signal objects won't work unless you make some connections inside your abstraction, manually or with an internal message. In fact instead of dynamically creating abstractions, using internal messages for constructing all the patch should be a better approach, you can store the lines of code that is constructing the patches with [textfile], and then you can clear and reconstruct any part of the patch by using an internal message manager, that can be made with a few objects. Also, I don't really get why you don't use [throw~] [catch~] [send~] and [receive~] instead of [inlet~] [outlet~]

Colet Patrice

----- Mail original -----

De: "Jörn Nettingsmeier" nettings@stackingdwarves.net À: pd-list@iem.at Envoyé: Vendredi 22 Juin 2012 19:48:31 Objet: [PD] dynamic patching woes...

hi *!

i've played around with dynamic patching to create readanyfs~-based players with variable number of channels, and i must say i'm not too happy with what i saw... in your experience, is dynamic patching a suitable approach outside of crash'n'burn live coding?

it's almost manageable when working on a fresh canvas, but in order to add outlets depending on a creation parameter, i found it necessary to dynpatch a quite large abstraction (my object count offset is close to 200...). not fun. is there a less invasive way to get a dynamic number of outlets and separate the dynpatching from the main patch?

also, i find that when i use my dynamically patched abstraction with those shine variable output ports, pd is unable to recreate the connections from those outlets to the dac~ object - i guess it's a race condition where it tries to connect before the objects have completed their startup. is there a workaround or alternative approach for this?

last thing i was wondering: is it possible to use dynpatching to create a patch and then save that for later use? i think i saw someone mention this (frank b.?), but i can't seem to find the thread just now... pointers to examples would be most welcome.

thanks,

jörn

-- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT

http://stackingdwarves.net

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 06/22/2012 07:48 PM, Jörn Nettingsmeier wrote:

hi *!

i've played around with dynamic patching to create readanyfs~-based players with variable number of channels, and i must say i'm not too happy with what i saw... in your experience, is dynamic patching a suitable approach outside of crash'n'burn live coding?

hmm, i'm not aware of how dynamic patching helps too much in live-coding...(probably it's only the words you are confusing: dynamic/live patching/coding)

it's almost manageable when working on a fresh canvas, but in order to add outlets depending on a creation parameter, i found it necessary to dynpatch a quite large abstraction (my object count offset is close to 200...). not fun. is there a less invasive way to get a dynamic number of outlets and separate the dynpatching from the main patch?

also, i find that when i use my dynamically patched abstraction with those shine variable output ports, pd is unable to recreate the connections from those outlets to the dac~ object - i guess it's a race condition where it tries to connect before the objects have completed their startup. is there a workaround or alternative approach for this?

this has been discusses at lengths on the list. the problem you have is that [loadbang] guarantees to bang only after your abstraction is fully connected on the parent patch. this is a *feature*! it allows you to have an abstraction that initializes values in the parent patch.

unfortunately it also means, that with [loadbang] you cannot create iolets _in time_. the iolets will only appear after the parent patch tried to connect to the non-existing iolets. (for the sake of good style i'll repeat the word "iolets" a couple of time: iolets, iolets be gone)

there is one workaround and two solutions for this:

• solution #1: don't do it. think of other ways to do it. dynamic

patching is something that is overestimated.

• workaround #1: save your abstraction with a maximum number of iolets

preallocated, and delete them dynamically. this will only work if the iolet types (message/signal) are consistent.

• solution #2: use [initbang]. [initbang] will fire once the abstraction

has been created, but before the parent patch tries to use it (e.g. connect to it). [initbang] will also work in dynamic patching context, where yo uhave to manually trigger [loadbang] (search the archives: "loadbang+dynamic+patching" should do) unfortunately [initbang] has not been accepted into Pd-vanilla (nag miller about it). if you are using Pd-extended you will be able to use it, but obviously your abstraction will not be Pd-vanilla compatible anymore.

last thing i was wondering: is it possible to use dynpatching to create a patch and then save that for later use? i think i saw someone mention this (frank b.?), but i can't seem to find the thread just now... pointers to examples would be most welcome.

frank might have said this, i surely did: using dynamic patching to create static patches is probably the only sane[*] way to use it. the idea is simple: use dynamic patching to create a patch, copy it into a new abstraction and save it. you can automate the process. our CUBEmixer uses such a technique (there's a "configurator" pd-patch that will create all those (or most) multi-instance patches dynamically. once you have gone through that, you just start the static application.

i can only repeat it: dynamic patching is totally overestimated. Pd is not made for it (it merely allows it). it seems like many new users go directly into dynamic-patching hell, because having multiple instances of objects is so easy in other languages. this is simply not the case with Pd, but once newbies complain about it, they are usually told that their problem is solvable with dynamic patching. while this is true, it also remains true that Pd is simply bad at this.

ah yes: and dynamic patching can be fun.

gmadsr IOhannes

[*] with "sane" i mean: i haven't seen any non-trivial patch that is maintainable and uses dynamic patching. "trivial" patches would include things like your own [trigger] implementation: a utility object that does a very simple thing and makes live a lot easier. you (or at least: I) don't want to have part of your business-logic depend on dynamic patching.