[PD] dynamic patching woes...

[IOhannes zmölnig]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120622/f7da56e3/attachment.pgp>