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

Jonathan Wilkes jancsika at yahoo.com
Tue Nov 20 01:14:42 CET 2012

----- Original Message -----
> From: IOhannes m zmölnig <zmoelnig at iem.at>
> To: pd-list at iem.at
> Cc: 
> Sent: Monday, November 19, 2012 5:18 PM
> Subject: Re: [PD] weird behavior with dynamically created abstractions (sound doesn't work)
> On 11/19/2012 09:07 PM, Jonathan Wilkes wrote:
>>  ----- Original Message -----
>>  That's not a reason to _suppress_ dsp with dynamic patching,
>>  because the process would work exactly the same regardless.
> i think this is simply a bug in Pd.

Then let's describe it as a bug when newcomers run into these
predictable problems from the buggy behavior, and not as a feature
that helps the user handle dsp toggling the "right" way when doing
dynamic patching.

> i do some live-coding using dynamic patching, and found that saving the patch 
> would re-compute the dsp-graph (i'm using abstractions, so saving will 
> eventually re-instantiate a number of abstractions, which triggers a 
> reavaulation of the dsp-graph; so i found that in practice this bug is not such 
> a big problem for _me_)
>>  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.
> well, very few *externals* (as in "atomic" (non-openable) objects 
> written mostly in C) do anything with loadbangs.
> anyhow, even if we are talking only about abstractions, i think your assumption, 
> that just because [loadbang] is not used in the  described way anywhere in the 
> Pd-svn, this behaviour could simply be changed is not a valid one.
That's not my assumption.  I'm not petitioning for changing Pd's dynamic patching
system-- I don't know the details about how it works internally.  But virtually no one
uses [loadbangs] in the way described in the hypothetical examples used to rationalize
why it's desirable for the dynamic patching system to work the way it does.  That should
be a good indicator that this imaginary library of abstractions which exists only in list
responses about dynamic patching should be removed and replaced with a simple
statement that "this inconsistent behavior is entrenched in Pd and cannot simply
be changed."  (If that is indeed the case.)


> i'd very much like to see [initbang] and [closebang] in Pd-proper though.
> fgmsdr
> IOhannes
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list