Forgot to send to the list...

---

Buffer aliasing means that the input and output signal might point to the same buffer. This is done to minimize memory usage and increase cache friendliness. In practice, this means that processing happens /in place/. You must not write to any output before reading the /corresponding /inputs. For most objects this is not a problem because for each sample you'd typically read the input(s) and then calculate the output(s).

Problems arise when you want to write a whole output /block /before processing/copying all the inputs. Here's a simple example: Say you send the list [2 1( to your [remap~] object. In your original "naive" version, you would copy the second input channel to the first output channel (2 -> 1). However, since input and output alias each other, you have in fact overwritten the first input channel! Now, when you go on to copy the first input channel to the second output channel (1 -> 2), you get unexpected values.

Side note: why do your channel indexes start at 1? Pd uses zero-based indexes for almost anything, with only few exceptions (ADC/DAC and MIDI channels, anything else?).

Christof

On 23.07.2023 05:59, Alexandre Torres Porres wrote:

On Sun, 23 Jul 2023 at 00:10 Alexandre Torres Porres porres@gmail.com wrote:

I see now I was just doing something silly thinking I was trying
to copy some sophisticated trick that would sove things.

I can't remember now which object I had to deal with something
like this.

Found one, copied the structure, it works! I still have no good idea on how things work, but hey, I got it working and I can sleep

Thanks

anyway, in this last version, I have my own "perform" method that
fails equally as before in some cases, but it is not as weird as
before...

let me just copy it instead of linking to a github code that might
change, here's the code section

*static*t_int*remap_perform(t_int *w){

t_remap *x = (t_remap *)(w[1]);

t_int n = (t_int)(w[2]);

t_int nchans = (t_int)(w[3]);

t_sample *in = (t_sample *)(w[4]);

t_sample *out = (t_sample *)(w[5]);

*for*(*int* i = 0; i < x->x_n; i++){ // channels to copy

*int* ch = x->x_vec[i].a_w.w_float - 1; // get channel number

*if*(ch >= nchans)

ch = nchans - 1;

*for*(*int*j = 0; j < n; j++){ // j is sample number of each channel

*if*(ch >= 0)

*out++ = in[ch*n + j];

*else*

*out++ = 0;

}

}

*return*(w+6);

}


Em sáb., 22 de jul. de 2023 às 21:22, Alexandre Torres Porres
<porres@gmail.com> escreveu:

    ok, I was able to compile a version that does not blow pd up

    obviously I have no idea of what I am doing and I did some
    things based on warnings I was getting, but then, I do copy
    the input first and then reorder the channels but I do get the
    exact same result as before, so it was all for nothing.

    here's my new attempt, hopefully not too far from getting
    things right
    https://github.com/porres/pd-else/blob/master/Code_source/Compiled/signal/remap~.c#L34

    cheers

    Em sáb., 22 de jul. de 2023 às 21:02, Alexandre Torres Porres
    <porres@gmail.com> escreveu:



        Em sáb., 22 de jul. de 2023 às 18:39, Christof Ressi
        <info@christofressi.com> escreveu:

            if the input and output signals have the same channel
            count, they will alias each other, just like in
            regular single-channel objects.

        actually, funny stuff happens for 4 multichannel input and
        3 multichannel output, but I've seen that issue with
        single channel objects and I tried copying stuff from
        other objects in ELSE into this multichannel idea and failed.

            You first need to copy the whole input signal to a
            temporary buffer (probably allocated in your object)
            and then copy the corresponding channels to the output
            signal.


        I wonder if you can give me a better detailed strategy/steps.
        thanks