----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 15, 2012 1:13 PM Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
On Wed, 2012-11-14 at 10:33 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Cyrille Henry ch@chnry.net To: pd-list@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.
That's not a reason to _suppress_ dsp with dynamic patching, because the process would work exactly the same regardless.
#1 Pd in its current state: user makes sure to suppress dsp, dynamically creates patch, then turns on dsp when finished #2 Pd with dynamic patching behavior being the same as the current manual patching behavior: user makes sure to suppress dsp, dynamically creates patch, then turns on dsp when finished
The only difference is that #1 introduces a frustrating inconsistency so that the user who is dynamically instantiating _one_ abstraction with a few tilde objects inside it gets confused and must ask on the list what they did wrong there, and I still haven't seen a clear example of how the behavior I describe would cause a bug or crash. (If it does happen to cause a bug or crash then I would agree the proper response is "this behavior avoids a crash and/or buggy behavior".)
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.
Dynamically created: [abstraction1]---[abstraction2]
I've never seen an external in svn where [abstraction1] would rely on an internal [loadbang] in order to send a message to its outlet. That would obviously complicate realtime patching, too. Even if you're designing your abstractions for the specific purpose of dynamically patching, it's much more sensible to dynamically create the [loadbang] itself to show clearly what's going on:
[loadbang]--[abstraction1]--[abstraction2]
If the user doesn't know about the canvas "loadbang" method, they can also do this:
[$0-loadbang]--[abstraction1]--[abstraction2]
-Jonathan
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.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list