Thanks for that. Using the two outputs of the four channel version works in stereo now just fine. When I try to delete two outputs and inputs from [pddom2.from~] and [<a href="http://pddom2.to">pddom2.to</a>~] respectively, it won&#39;t work anymore. Is what I say clear?...<br>
Anyway, I guess this way it&#39;s fine. Thanks again.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 8:52 PM, Enrique Erne <span dir="ltr">&lt;<a href="mailto:enrique@netpd.org" target="_blank">enrique@netpd.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alexandros, Thanks for reporting, somehow it was registering as<br>
no-audio abstraction. This commit should fix it:<br>
<a href="https://github.com/thisconnect/pddom/commit/b901f9f66b95e7efb244e27901b4d4dbd2a8bbfd" target="_blank">https://github.com/thisconnect/pddom/commit/b901f9f66b95e7efb244e27901b4d4dbd2a8bbfd</a><br>
<br>
Please try the newest verison @ <a href="https://github.com/thisconnect/pddom" target="_blank">https://github.com/thisconnect/pddom</a><br>
and let me know if that works for you. I suggest to:<br>
- copy/paste the abstractions form examples/multichannel into your project<br>
- rename the abstractions to <a href="http://pddom2.to" target="_blank">pddom2.to</a>~ / pddom2.from~<br>
- remove the unused 2 outlets~ s~/r~ parts<br>
<br>
Let me know if that works for you, I will have time tomorrow during<br>
the day to have a look at it.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Wed, Nov 21, 2012 at 5:13 PM, Alexandros Drymonitis &lt;<a href="mailto:adrcki@gmail.com">adrcki@gmail.com</a>&gt; wrote:<br>
&gt; Enrique, I&#39;ve been playing around with pddom and it works very nicely, I<br>
&gt; only have trouble making it stereo. I tried to follow the<br>
&gt; examples/multi/pd-dom4-help.pd changing it a bit to make it stereo, but it<br>
&gt; won&#39;t really work. Is it something to do with the right most outlet of<br>
&gt; [pddom.from~] that connects to the right most inlet of [<a href="http://pddom.to" target="_blank">pddom.to</a>~] in the<br>
&gt; mono version? In you multichannel version there are only tilde outlets in<br>
&gt; [pddom4.from~] and the right most inlet of [<a href="http://pddom4.to" target="_blank">pddom4.to</a>~] receives nothing. I<br>
&gt; tried to modify it accordingly but with no luck.<br>
&gt; Could you help?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Fri, Nov 16, 2012 at 10:43 AM, Enrique Erne &lt;<a href="mailto:enrique@netpd.org">enrique@netpd.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; how can you control the abstractions you add to nodes, say with a<br>
&gt;&gt; &gt; slider? Or do you have to create your nodes with abstractions with arguments<br>
&gt;&gt; &gt; (like the proposed method in the readme file) and that should be it?<br>
&gt;&gt;<br>
&gt;&gt; (I forgot to hit reply to all)<br>
&gt;&gt;<br>
&gt;&gt; It depends on your needs, but [pddom] does not help you building the<br>
&gt;&gt; interface. The examples/ui illustrates simple ways of controlling the<br>
&gt;&gt; dynamically created abstractions with 1 interface.<br>
&gt;&gt;<br>
&gt;&gt; Another way is to use the abstractions own window, that you can open<br>
&gt;&gt; with [vis $1( where $1 is the position (number) of the instantiated<br>
&gt;&gt; abstraction. This is of corse if you don&#39;t mind having each interface<br>
&gt;&gt; in it&#39;s own window.<br>
&gt;&gt;<br>
&gt;&gt; To locate and open exactly the one abstraction vis send a [; $1.$2.vis<br>
&gt;&gt; findparent( command to [namecanvas $1.$2.vis]. This is the only reason<br>
&gt;&gt; why there is a [namecanvas] inside [pddom.from] and [pddom.from~].<br>
&gt;&gt; This also requires [pddom.from] and [pddom.from~] to be located in the<br>
&gt;&gt; main canvas of each abstraction and not hidden somewhere deeper.<br>
&gt;&gt;<br>
&gt;&gt; How are you planing to use pddom? Do you open the same abstraction<br>
&gt;&gt; multiple times or do you wish to combine many different abstractions<br>
&gt;&gt; with their own user interface?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt; The only bad thing is the dsp having to go off and on again.<br>
&gt;&gt;<br>
&gt;&gt; If you are on OS X turning off/on DSP<br>
&gt;&gt; takes a long time (or at least it used to take over 100ms a few years<br>
&gt;&gt; ago). On other operating systems it was never a problem iirc.<br>
&gt;&gt;<br>
&gt;&gt; You could try and increase the Delay time under Audio Settings and<br>
&gt;&gt; test if that helps.<br>
&gt;&gt;<br>
&gt;&gt; Alternatively there is another &quot;trick&quot; that works without turning<br>
&gt;&gt; off/on DSP, this is creating 1 ~ object and deleting it again. See<br>
&gt;&gt; also tests/basic/test-dsp-update~.pd<br>
&gt;&gt; It disables the internal off/on update mechanism by [dsp_ disable( and<br>
&gt;&gt; uses a subpatch for the DSP tree update workaround. See [pd<br>
&gt;&gt; dsp-tree-update-workaround], but all your messages that change the DSP<br>
&gt;&gt; tree need to go through that subpatch.<br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>