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

Alexandros Drymonitis adrcki at gmail.com
Wed Nov 21 18:13:12 CET 2012

Enrique, I've been playing around with pddom and it works very nicely, I
only have trouble making it stereo. I tried to follow the
examples/multi/pd-dom4-help.pd changing it a bit to make it stereo, but it
won't really work. Is it something to do with the right most outlet of
[pddom.from~] that connects to the right most inlet of [pddom.to~] in the
mono version? In you multichannel version there are only tilde outlets in
[pddom4.from~] and the right most inlet of [pddom4.to~] receives nothing. I
tried to modify it accordingly but with no luck.
Could you help?

On Fri, Nov 16, 2012 at 10:43 AM, Enrique Erne <enrique at netpd.org> wrote:

> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121121/bf82d6bb/attachment.htm>

More information about the Pd-list mailing list