Alexandros, Thanks for reporting, somehow it was registering as no-audio abstraction. This commit should fix it: https://github.com/thisconnect/pddom/commit/b901f9f66b95e7efb244e27901b4d4db...
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@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@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.