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

[Roman Haefeli]

On Wed, 2012-11-14 at 10:33 -0800, Jonathan Wilkes wrote:
> ----- 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?

First, dynamic patching - though widely used - is _not_ a documented and
officially supported feature. Consider it something that people found
out how it works as a hack to do some stuff that wouldn't be possible
otherwise. Nevertheless it's not a Pd feature as such and might be
subject to change.

I don't know the actual answers to your questions, but I have some
guesses. The difference between manual patching and dynamic patching is
that for the former every user action is considered finished as soon as
the user did something. For instance, whenever a tilde object is
created, the graph is recompiled. However, dynamic patching emulates the
process of loading a patch. On patch load, only when all objects are
instantiated the process is finished and all loadbangs are fired in the
order innermost first, the outermost last. Also the graph is then only
compiled once, but not on every object creation. When doing dynamic
patching however, Pd does not know automatically when process of dynamic
patching has finished. 

Actually, I consider it a good thing that loadbangs are not fired
immediately on dynamic creation. This gives more control to the patch
designer as they can let the loadbangs fire when the patch designer
considers the dynamic part to be ready. Also it saves a lot of (cpu)
time to only recompile the graph once instead of on every tilde object
instantiation. 

Roman

> Also:
> 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
> cases.
> 
> 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.