[PD-dev] inlets sending to wrong outlets

Christof Ressi info at christofressi.com
Mon Jun 1 10:44:47 CEST 2020


(Moving this back to the correct thread)

> For some reason your response didn't show up in my email Cristof,
I can see my e-mail in the archives already... Did you actually 
subscribe to the list? The daily digest is for reading only.

Also note the following (quoted from the Pd digest mail):

"When replying, please edit your Subject line so it is more specific 
than "Re: Contents of Pd-dev digest...""

---

> Could you elaborate on how buffer aliasing is caused by how the 
> surrounding objects are connected?
Pd tries to optimize the DSP graph by reusing signal buffers. The actual 
results naturally depends on the structure of the DSP graph at hand. 
Don't worry about the details, the only thing you have to keep in mind 
is that buffer aliasing can always happen, no matter how many 
inlets/outlets you have and how they are created.

> Assuming of course that's the problem here, but my suspicion is rather 
> that I'm not reading from all inlets before writing to the outlets.
Buffer aliasing is the very reason that you should read all inlets 
before writing to any outlet.

Christof

On 01.06.2020 03:02, Eric Lennartson wrote:
> For some reason your response didn't show up in my email Cristof, but 
> to answer your question, I am providing two creation arguments that 
> sets the number of inlets and outlets. Could you elaborate on how 
> buffer aliasing is caused by how the surrounding objects are 
> connected? Assuming of course that's the problem here, but my 
> suspicion is rather that I'm not reading from all inlets before 
> writing to the outlets.
On 31.05.2020 21:49, Christof Ressi wrote:
>
> In Pd, signal inlets and outlets can share the same buffer. Therefore 
> it is important that for any given sample index you never write to any 
> outlet before reading from all inlets.
>
> In your case, you have to first make a copy of all input signals 
> before passing them through to the outlets. You can allocate the 
> necessary intermediate buffers in the dsp() method.
>
>> I've been working with variable amounts of inlets and outlets
> What do you mean by "variable" inlets/outlets? Do you mean that the 
> number of inlets/outlets is determined by creation arguments? In that 
> case, this is not related to the problem at ahdn. Buffer aliasing can 
> happen either way. (It actually depends on how the surrounding objects 
> are connected.)
>
> Christof
>
> On 31.05.2020 21:12, Eric Lennartson wrote:
>> I've been looking at the code for those, but I'm finding it a little 
>> hard to parse.
>> Not sure how this is going to look on your end, but sorry for the 
>> text wall. If there's a better way to share lmk.
>>
>> typedefstruct_viotest
>>
>> {
>>
>> t_object x_obj;
>>
>> int n_outs, n_ins, n_iolets;
>>
>> t_sample**in_vec, **out_vec; // vector to hold all the inlets and outlets
>>
>> } t_viotest_tilde;
>>
>>
>> staticvoidviotest_tilde_input(t_viotest_tilde*x, t_floatargf)
>>
>> {
>>
>> error("[viotest~]: no method for float.");
>>
>> }
>>
>>
>> statict_int*viotest_tilde_perform(t_int*w)
>>
>> {
>>
>> t_viotest_tilde*x = (t_viotest_tilde*)(w[1]);
>>
>> int nblock = (int)(w[2]);
>>
>> int n = nblock;
>>
>> t_sample **in_vec = x->in_vec;
>>
>> t_sample **out_vec = x->out_vec;
>>
>> int smaller = (x->n_ins < x-> n_outs) ? x->n_ins : x->n_outs;
>>
>> for(int channel = 0; channel < smaller; ++channel)
>>
>>   {
>>
>> t_sample* in = in_vec[channel];
>>
>> t_sample* out = out_vec[channel];
>>
>>       n = nblock;
>>
>> while(n--)
>>
>>       {
>>
>> t_sample out_val = *in++;
>>
>>           *out++ = out_val;
>>
>>       }
>>
>>   }
>>
>>
>> return (w + 3);
>>
>> }
>>
>>
>> staticvoidviotest_tilde_dsp(t_viotest_tilde*x, t_signal**sp)
>>
>> {
>>
>> int i, nblock = sp[0]->s_n;
>>
>> t_sample **dummy = x->in_vec;
>>
>> for(i = 0; i < x->n_ins; ++i)
>>
>>   {
>>
>>       *dummy++ = sp[i]->s_vec;
>>
>>   }
>>
>> for(; i < x->n_iolets; ++i)
>>
>>   {
>>
>>       *dummy++ = sp[i]->s_vec;
>>
>>   }
>>
>> dsp_add(viotest_tilde_perform, 2, x, nblock);
>>
>> }
>>
>>
>> On Sun, May 31, 2020 at 12:05 PM Alexandre Torres Porres 
>> <porres at gmail.com <mailto:porres at gmail.com>> wrote:
>>
>>     I remember I went through similar stuff, see the code of
>>     else/mtx~ and cyclone/matrix~
>>
>>     and, share your code?
>>
>>     cheers
>>
>>     Em dom., 31 de mai. de 2020 às 16:00, Eric Lennartson
>>     <lennartsoneric at gmail.com <mailto:lennartsoneric at gmail.com>>
>>     escreveu:
>>
>>         Hey all,
>>
>>         I've been working with variable amounts of inlets and outlets
>>         and for the most part it's been working fine. If it's only
>>         variable inlets and the outlets are fixed, or vice versa, it
>>         works fine. However when both are variable I can't seem to
>>         get the inlets to go to the correct outlet. My current code
>>         is cycling through the inlets and outlets in pairs, but for
>>         some reason this isn't working. Any thoughts?
>>
>>         Thanks
>>         Eric
>>         _______________________________________________
>>         Pd-dev mailing list
>>         Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>>         https://lists.puredata.info/listinfo/pd-dev
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20200601/779ab576/attachment-0001.html>


More information about the Pd-dev mailing list