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

[Enrique Erne]

Alexandros, Thanks for reporting, somehow it was registering as
no-audio abstraction. This commit should fix it:
https://github.com/thisconnect/pddom/commit/b901f9f66b95e7efb244e27901b4d4dbd2a8bbfd

Please try the newest verison @ https://github.com/thisconnect/pddom
and let me know if that works for you. I suggest to:
- copy/paste the abstractions form examples/multichannel into your project
- rename the abstractions to pddom2.to~ / pddom2.from~
- remove the unused 2 outlets~ s~/r~ parts

Let me know if that works for you, I will have time tomorrow during
the day to have a look at it.



On Wed, Nov 21, 2012 at 5:13 PM, Alexandros Drymonitis <adrcki at gmail.com> wrote:
> 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.
>
>