@cuinjune thanks.
next i will try to store the grid values (x, y/id, color/toggle state) into a table/array. just discovered that its possible to create "matrices" with tables in lua. which could be nice for that.
do you think it makes more sense to use open frameworks or lua arrays/tables fore storing open frameworks data in ofelia?
edit: with print everything works like expected, need to learn whats the difference between return and print. funny (and useful) that lua prints into the pd console. is it also possible to return lists? thats something i am used from pure data...
just a test.
ofelia_array_matrix.pd

function ofelia.float(f);
local matrix = {};
for i = 1, 10 do;
matrix[i] = {};
for j = 1, 10 do;
matrix[i][j] = i*j;
end;
end;
print(table.unpack(matrix[f]));
return table.unpack(matrix[f]);
end;

@elden Yes, using messages, any object can be put into a patch.

I have messed about with this help file in the past, so some bits might not work.........send_messages_to_pd.pd
More info........ https://puredata.info/docs/developer/PdFileFormat
which lists the objects that can be patched and modified with messages.... at the bottom of the page it shows the parameters that can be set at the same time.
Some parameters do not set properly at creation, but if you set a receive name then you can update them afterwards with messages.

The only difficult bit is keeping track of object creation order, so as to correctly use the [connect( message to join them up.
It can be useful to set a counter that puts, with arguments, and then connects as it counts, and also spaces the objects across the patch as they are "put".......
I use it a lot for building patches of variable size......but here to build a vanilla equivalent of [matrix~]...... matrix~.zip

You will see in [matrix_test~] that there are no audio connections made. That is because the inlets and outlets of [matrix~] have been created dynamically..... they were not there when the patch was opened. You need another patch to tell [matrix_test~] to reconnect...... ... When I use [matrix~] my patch then creates [throw~] and [catch~ objects in the correct quantity and connects those to [matrix~].......... job done. I had to do that in extended anyway.
Always use input (go) and output (go next) bangs so that things build in the correct order.
Usually anything is possible in Pd.

A bit more........0.all_msg.pd
David.

Hello I'm Programming with pure data, a simple controller pc to mixer,
the mixer work in midi in and out using usb port of the pc.

When programming ctlin 1 1 ---- fader in ----- fader out---- ctlout 1 1 a have a problem, because when i move the fader 1 con the mixer ,the fader go slowly jerked...
If i disconnect the last block ctlout 1 1 from the chain, the fader works ok, and the fader of pure data moving normally
It is possible to stop sending ctlout when i'm using the control fader of the physical mixer?

whats going wrong?

thank you!!!

This is a spiritual successor to amPd. It's much more stable and has many more features than amPd:

• reads/writes metadata to/from patches. This is done by storing the info in the form of comments, in a canvas called [pd meta] or [pd info]. If no such canvas exists, foobar will add it in the top left-hand corner of your patch.

• comes with a Win32 Dialog UI element, containing sliders, toggles, buttons, and edit-text/button combos to send messages to your patch.

  • foobar looks in your patch for a canvas called [pd mix] and uses the parameters of whatever sliders, bang objects, or toggles it finds there to give your UI controls similar functionality.

How playback works

• libpd sends a 1 to vol, then a bang to play.
  • Generally this is where, in your patch, you have an [r play] hooked up to your metro, and an [r vol] connected to a [*~ ] before your output reaches [dac~].

• the length of the song is arbitrarily set by the user.
  • This affects the trackbar's cursor visibility and ability to set a position.
  • If the length is 0, there will be no trackbar cursor. Otherwise, the cursor, when moved, will send its position in seconds to pos. From there, it's up to your patch to take that information from [r pos] and work it into song events.

• The patch will not actually stop and move on to the next track until libpd receives a bang from [s stop].

How the mixer works

• all mixer controls go inside of [pd mix]

• horizontal and vertical sliders are turned into slider controls in the UI element
  • labels assigned to sliders in the patch become labels for the UI element's slider controls. The same applies for send symbols.
  • min and max values of sliders on the UI element work in integers only, so if you want a gradual shift from, say, 0 to 1, write "gradient" in the slider's receive symbol, and the slider's range will be broken down into roughly 200+ individual steps.
  • there are currently 7 sliders in the UI element

• bang objects with no label become simple buttons in the UI
  • their send symbols will be reflected in the button's name and they will send a bang when clicked.
  • there are currently 3 buttons

• bang objects with a label assigned become message buttons
  • these have an edit text field associated with them, where you can type out any message you want and send it to the destination.
  • the bang's label is placed inside of the edit text field as a suggested message to send.
    • pure data strips commas out of labels, so I'm using apostrophes to denote where commas should go. ex: do this' then this
  • there are currently 2 message buttons, with the 'any' button being a potential 3rd.

• a bang object with a label written in the format dest : msg will be assigned to the 'any' button.
  • the 'any' button has an editable destination field, giving you access to basically any receive symbol in your patch.
  • also substitutes as a third normal message button, when the other two are already in use

• toggles become checkboxes
  • each checkbox can have a label and send symbol assigned to it
  • there are currently 4 checkboxes

• right-clicking a track shows the context menu entry Pd Player -> Load mixer.
  • basically, you can load mixers of tracks not currently playing for some potentially interesting exchanges between patches. After loading the mixer, you still need to hit the Refresh button to show the changes.

foo_pd's copy of libpd.dll contains only the externals that I needed to run the example patches. If you want your own patches to work with foo_pd, you might need to make another build using MSYS2. If you're not sure which objects aren't instantiating, foobar's console prints all of pd's messages while audio is being processed. I'll also add more externals over time.

I'll be maintaining foo_pd at https://github.com/myQwil/foo_pd where you can also find the latest builds

foo_pd.zip
Last Updated: Feb 26, 2021 3:55pm EST

Ah, awesome. I played with matrix a while back as my unit to transfer data from file to pure data.

Upon loading of a song, it pulls up all the potential states / programs into a txt. Firing a state or program load event selects the correct matrix. Then arrives at the example above.

Matrix was my method to store the cc-value pairs, and unload them via the [row( command. I was thinking of matrix in terms of storing a multidimensional array.

After loading a state or program, the initial information is rounded up into a array to act as a buffer for storing all changes I make. That array is pulled to save the next state. So either in live performance or composition, I load a program and or state, goof around, save a state - and pull up that reference at any time.

I'll make a bench mark for the method you've shown above and see the results. Thank you.

@funkheld ?...... like this.......

It can't be done with an array (a Pd table array that is) as each value is given an index, and if you write to the index with a different value it drops the old value. I think you would have to use Gem (writing individual pixels) if you want to view the array.
Or you could make a grid of 100x100 canvases, and send messages to them to change their colours.
If you don't want or need to see the result then you could use a matrix, that could be printed to the terminal or a text file........
The iemmatrix library which is included in Pd Extended can probably be imported to Vanilla through the Deken Plugin....... and contains [matrix-help].....
matrix.zip ..... shows what can be done, but might not work without the complete library.......
David.

@luismipv In Pd extended (and in the Zexy library, if you have that installed in Vanilla) there is an object [multiplex] (or [mux] that you can use "off the shelf"...... see [multiplex-help]

In vanilla (or extended) it can be done like this.......muxer.pd
David.

And here it is as an abstraction........ it will deal with symbols and floats, but gets messy afterwards if sending both. See the help file for how to deal with that..... they both drop out, but symbols do not "behave".....
muxered.zip

@Pierre-Guillot said:

You still don't use the realloc method properly. The method is for reallocation, so you should give it the pointer to the memory you want to resize.
In your code, you allocate new memory each time you resize the arrays without releasing them thus you have a lot of memory leaks.

Sorry, I can't see my error. I think, lines 116-119 do free the allocated memory:

if (x->matrix) free(x->matrix);
    if (x->vector) free(x->vector);
    x->vector = temp_vector;
    x->matrix = temp_matrix;

VS shows me the process memory. When I do produce memory leaks, the process memory should raise, I guess. But with my code it corresponds to the size of the matrix. So lowering the sample length lowers the memory also.

With the first, x->vector should be set to NULL, this way the method will acts like malloc.

OK. I added x->matrix = NULL; x->vector = NULL; to the method average_init_arrays

My updated code is here:
https://github.com/XRoemer/puredata/blob/master/average%7E/C/r_average%7E2.h
(I also changed the method average_resize_arrays from:

void average_resize_arrays(t_average_tilde *x, t_floatarg f) {

    x->row = 0;
    x->len_avg = f;

    average_resize_avg(x, f);
    average_resize_matrix(x, f);

    if (!x->avg && !x->matrix) {
        x->matrix = NULL;
        pd_error(x, "allocation failed");
    }
}

to:

void average_resize_arrays(t_average_tilde *x, t_floatarg f) {

    x->row = 0;
    x->len_avg = f;

    average_resize_avg(x, f);
    average_resize_matrix(x, f);

    if (!x->avg || !x->matrix) {
        if (x->matrix) free(x->matrix);
        if (x->vector) free(x->vector);
        x->matrix = NULL;
        x->vector = NULL;
        pd_error(x, "allocation failed");
    }
}

I wonder if your method of allocating one array has any performance advantages inside the perform method?

Yes in theory because all the sample are next to each other. If you allocate several vectors, one can be "far" from another and the memory access can be CPU expensive.

If I would free sample_arr first, I would loose the references to the allocated arrays.

No because the matrix (sample_arr) doesn't own the memory of the "real" vector. The matrix is in fact array of pointers that point to the "real" vector but it's just addresses.

Your code needs a larger block of free memory than mine.

No, you allocate n times a vector of size m and I allocate a single vector of size n*m, it's the same memory size (except the matrix that is one vector of pointers of size n that is pretty small). Anyway, nowadays the size of memory allocated isn't really a problem.

When allocation fails, my code reduces the size of the matrix and tries to allocate again. (I don't know if that makes much sense. Beeing so close to full memory might cause performance issues anyway.)

I think with modern computer and for the size of matrices you want, it's almost impossible that the allocation fail. But if it happens, in my opinion, the best is to notify that something wrong happened and to avoid the perform method. Instead of pushing the computer in its limits, the user or the developer can change and correct its approach because it means that there is an error somewhere (an error of matrix size for example).

Is there any advantage of using freebytes() instead of free() except for the includes?

No I don't think but it was used to keep a track of the global amount of allocated memory and freed so you can check if there are memory leaks in the application.

Do I really have to free the colums before reallocating the rows?

Normally, but a good practice in C is:
Allocation:

t_sample ** matrix = (t_sample**)getbytes(nrows * sizeof(t_sample *));
if(matrix)
{
    t_sample * vector = (t_sample*)getbytes(nrows * ncols * sizeof(t_sample));
    if(vector)
    {
       for(int i = 0; i <  nrows; ++i)
       {
          matrix[i] = vector+i*ncols;
       }
    }
    else
    {
        freebytes(matrix, nrows * sizeof(t_sample *));
        matrix = NULL;
        pd_error(x, "allocation failed");
    }
}
else
{
    vector = NULL;
    pd_error(x, "allocation failed");
}

Release:

if(matrix)
freebytes(matrix, nrows * sizeof(t_sample *));
matrix = NULL;
if(vector)
freebytes(vector, nrows * ncols * sizeof(t_sample));
vector = NULL;

Reallocation:

temp_matrix = resizebytes(matrix, nrows * sizeof(t_sample *), new_nrows * sizeof(t_sample *));
if(temp_matrix)
{
        temp_vector = resizebytes(vector, nrows * ncols * sizeof(t_sample *), new_ncols * new_nrows * sizeof(t_sample));
        if(temp_vector)
        {
            vector = temp_vector;
            matrix = temp_matrix;
            nrows = new_nrows;
            ncols = new_ncols;
            for(int i = 0; i < nrows; ++i)
            {
                matrix[i] = vector+i*ncols;
            }
        }
        else
        {
            freebytes(temp_matrix, new_nrows * sizeof(t_sample *));
            freebytes(vector, nrows * ncols * sizeof(t_sample));
            vector = NULL;
            matrix = NULL;
            pd_error(x, "allocation failed");
        }
 }
else
{
    freebytes(matrix, nrows * sizeof(t_sample *));
    freebytes(vector, nrows * ncols * sizeof(t_sample));
    vector = NULL;
    matrix = NULL;
    pd_error(x, "allocation failed");
}