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

[Enrique Erne]

> how can you control the abstractions you add to nodes, say with a slider? Or do you have to create your nodes with abstractions with arguments (like the proposed method in the readme file) and that should be it?

(I forgot to hit reply to all)

It depends on your needs, but [pddom] does not help you building the
interface. The examples/ui illustrates simple ways of controlling the
dynamically created abstractions with 1 interface.

Another way is to use the abstractions own window, that you can open
with [vis $1( where $1 is the position (number) of the instantiated
abstraction. This is of corse if you don't mind having each interface
in it's own window.

To locate and open exactly the one abstraction vis send a [; $1.$2.vis
findparent( command to [namecanvas $1.$2.vis]. This is the only reason
why there is a [namecanvas] inside [pddom.from] and [pddom.from~].
This also requires [pddom.from] and [pddom.from~] to be located in the
main canvas of each abstraction and not hidden somewhere deeper.

How are you planing to use pddom? Do you open the same abstraction
multiple times or do you wish to combine many different abstractions
with their own user interface?


> The only bad thing is the dsp having to go off and on again.

If you are on OS X turning off/on DSP
takes a long time (or at least it used to take over 100ms a few years
ago). On other operating systems it was never a problem iirc.

You could try and increase the Delay time under Audio Settings and
test if that helps.

Alternatively there is another "trick" that works without turning
off/on DSP, this is creating 1 ~ object and deleting it again. See
also tests/basic/test-dsp-update~.pd
It disables the internal off/on update mechanism by [dsp_ disable( and
uses a subpatch for the DSP tree update workaround. See [pd
dsp-tree-update-workaround], but all your messages that change the DSP
tree need to go through that subpatch.