[PD] weird behavior with dynamically created abstractions (sound doesn't work)

Jonathan Wilkes jancsika at yahoo.com
Wed Nov 14 19:33:35 CET 2012

----- Original Message -----

> From: Cyrille Henry <ch at chnry.net>
> To: pd-list at iem.at
> Cc: 
> Sent: Wednesday, November 14, 2012 5:49 AM
> Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
> Le 12/11/2012 16:29, Ángel Faraldo a écrit :
>>  Hi List,
>>  I've been increasingly working with dynamic patching and there is an 
> issue that don't understand in relation with creating multiple audio 
> abstractions...
>>  Imagine I put an oscillator inside an abstraction and I recall one instance 
> of it from the main patch (already computing audio). This is what happens:
>>  The abstraction will not produce sound until I:
> no sound is produce until a new DSP graph is created.
> it is usually recommended to switch dsp off before dynamically patch audio 
> object, and switch if on after.
> see ML archives for reasons.

If turning off dsp before dynamically patching an audio object is what the user
is _supposed_ to do, then why is audio turned off for a dynamically created
abstraction?  Is there a potential crasher if the behavior were different that can
be shown in a short example patch?

Regarding loadbang being suppressed in a dynamically instantiated object--
would there be crashers caused by not suppressing it?

These issues come up time and time again because Pd's behavior is
glaringly inconsistent-- a live coder typing <ctrl-1> and the word "foo" in the
box gets different behavior than someone doing [obj 20 20 foo(--[sendcanvas].
Since I've _never_ read a message from a live coder who wants loadbangs
to cease automatically firing inside abstractions, and I've rarely if ever seen
an abstraction in svn that uses [loadbang] to send data to a hot inlet, it'd be
nice to have a short example patch that shows how a crash could occur
for automated dynamic patching, but not live coding, if loadbangs did fire in both

This inconsistency is the reason the list continues getting these queries. When the
behavior clashes so much with the user's own experience, time and time
again we see they think it's a problem with _their_ patch, which is why they often
don't search the list first for the same issue first.  Without a clear counterexample of the
edge case that would cause a crash, we can't expect users to understand
why behavior they've encountered 1000 times in building patches must change when
they automate that same process.


More information about the Pd-list mailing list