@robertesler thanks again! i got rid of reading the value in perform funuction using matrix_rw and now i just access it via the class object x. but still, the laggy sound remains. one thing is, that instead of being 1, the value from matrix (value that multiplies the incoming signal) is 266830762" that explains a lot, so the laggy sound i caused by clipping of some sort. nooow to figure out where this bug comes from.

simple_matrix~.c

//sudo ln /Applications/Pd-0.55-0.app/Contents/Resources/src/m_pd.h m_pd.h
//snad je to ok udelat takhle no

#include <m_pd.h>
#include <string.h>
#include <pthread.h>
#include <stdarg.h>


#define MATRIX_SIZE 7
#define TRANSM_SIZE 3


static t_class *simple_matrix_tilde_class;

typedef struct _simple_matrix_tilde
{
  t_object x_obj;

  t_float some;

  int frame;

  int val;
  int posx;
  int posy;

  char recv[TRANSM_SIZE];

  t_float m_state[MATRIX_SIZE][MATRIX_SIZE]; //stav peč desky
  t_float stat;

  t_inlet *sym_in_on;
  t_symbol *sgo;

  pthread_mutex_t mutex;

  t_inlet *sig_one_in, *sig_two_in, *sig_tri_in, *sig_qud_in, *sig_fiv_in, *sig_six_in, *sig_sev_in; 
  t_outlet *sig_one_out, *sig_two_out, *sig_tri_out, *sig_qud_out, *sig_fiv_out, *sig_six_out, *sig_sev_out;

} t_simple_matrix_tilde;

t_float matrix_rw(t_simple_matrix_tilde *x, int op, int c, ...) //x, 0/1, c, x, y, val
{
  va_list args;
  va_start(args, c);
  
  int xpos;
  int ypos;
  int sval;
  
  int m;
  
  switch(op)
  {
    case 0: //read from timrax
      m = pthread_mutex_lock(&x->mutex);
      xpos = va_arg(args, int);
      ypos = va_arg(args, int);
        
      va_end(args);
      
      pthread_mutex_unlock(&x->mutex);

      return x->m_state[xpos][ypos];
  
    case 1: //write to axtirm
      m = pthread_mutex_lock(&x->mutex);
      xpos = va_arg(args, int);
      ypos = va_arg(args, int);
      sval = va_arg(args, int);
        
      va_end(args);

      x->m_state[xpos][ypos] = (t_float)sval;

      pthread_mutex_unlock(&x->mutex);
        
      return 0;
      
    default:
      //hm
      va_end(args);
      return 0;
  }

  if(m)
  {
    //pthread error
    pd_error(x, "pthread mutex lock is behaving :(");
    va_end(args);
    return 0;
  }
}

void simple_matrix_tilde_oscin(t_simple_matrix_tilde *x, t_symbol *s)
{
  if(strlen(s->s_name) >= TRANSM_SIZE)
  {
    //sometimes the size is for some reason larger, maybe UDP? crazy guy
    //char recv[TRANSM_SIZE]; //snad to nevybouchne
    memcpy(x->recv, s->s_name, TRANSM_SIZE);
  
    x->val = x->recv[0] - '0';
    x->posx = x->recv[1] - '0';
    x->posy = x->recv[2] - '0';
  
    //post("val %d posx %d posy %d", x->val, x->posx, x->posy);

    x->stat = matrix_rw(x, 1, 3, x->posx, x->posy, x->val); //write
  } else 
  {
    //?
  }
}

t_int *simple_matrix_tilde_perform(t_int *w)
{
  t_simple_matrix_tilde *x =  (t_simple_matrix_tilde*)(w[1]);
  t_sample *sig_in =          (t_sample *)(w[2]);
  t_sample *sig_out =         (t_sample *)(w[3]);
  int len =                   (int)(w[4]); //lenght of sample

  //t_float stat = matrix_rw(x, 0, 2, 0, 0); //read
  for(int u = 0; u < len; u++)
  {
    post("%d", x->m_state[0][0]);
    *sig_out++ = *(sig_in++) * x->m_state[0][0];
  }

  return (w+5);
}

void simple_matrix_tilde_dsp(t_simple_matrix_tilde *x, t_signal **sp)
{
  dsp_add(simple_matrix_tilde_perform, 4, x, sp[0]->s_vec, sp[1]->s_vec, sp[0]->s_n);
}

void *simple_matrix_tilde_new(t_symbol *s, int argc, t_atom *argv, t_floatarg some)
{
  t_simple_matrix_tilde *x = (t_simple_matrix_tilde *)pd_new(simple_matrix_tilde_class);

  pthread_mutex_init(&x->mutex, NULL);

  memset(x->m_state, 0, sizeof(x->m_state));

  x->sym_in_on = inlet_new(&x->x_obj, &x->x_obj.ob_pd, gensym("symbol"), gensym("oscin"));

  //wall,
  //wall,
  //x->sig_one_in = inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);
  //x->sig_two_in = inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);
  //x->sig_tri_in = inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);
  //x->sig_qud_in = inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);
  //x->sig_fiv_in = inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);
  //x->sig_six_in = inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);
  //x->sig_sev_in = inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal);

  x->sig_one_out = outlet_new(&x->x_obj, &s_signal);
  //x->sig_two_out = outlet_new(&x->x_obj, &s_signal);
  //x->sig_tri_out = outlet_new(&x->x_obj, &s_signal);
  //x->sig_qud_out = outlet_new(&x->x_obj, &s_signal);
  //x->sig_fiv_out = outlet_new(&x->x_obj, &s_signal);
  //x->sig_six_out = outlet_new(&x->x_obj, &s_signal);
  //x->sig_sev_out = outlet_new(&x->x_obj, &s_signal);

  return (void *) x;
}

void simple_matrix_tilde_freedom(t_simple_matrix_tilde *x)
{
  inlet_free(x->sym_in_on);

  inlet_free(x->sig_one_in);
  inlet_free(x->sig_two_in);
  inlet_free(x->sig_tri_in);
  inlet_free(x->sig_qud_in);
  inlet_free(x->sig_fiv_in);
  inlet_free(x->sig_six_in);
  inlet_free(x->sig_sev_in);

  outlet_free(x->sig_one_out);
  outlet_free(x->sig_two_out);
  outlet_free(x->sig_tri_out);
  outlet_free(x->sig_qud_out);
  outlet_free(x->sig_fiv_out);
  outlet_free(x->sig_six_out);
  outlet_free(x->sig_sev_out);
}

void simple_matrix_tilde_setup(void)
{
  simple_matrix_tilde_class = class_new(
    gensym("simple_matrix~"),
    (t_newmethod)simple_matrix_tilde_new,
    (t_method)simple_matrix_tilde_freedom,
    sizeof(t_simple_matrix_tilde),
    CLASS_DEFAULT,
    0
  );

  class_addmethod(simple_matrix_tilde_class, (t_method)simple_matrix_tilde_oscin, gensym("oscin"), A_DEFSYMBOL, 0);
  
  class_addmethod(simple_matrix_tilde_class, (t_method)simple_matrix_tilde_dsp, gensym("dsp"), A_CANT, 0);
  CLASS_MAINSIGNALIN(simple_matrix_tilde_class, t_simple_matrix_tilde, some);
  
}

code responsible for sending data over network (miniosc is needed to compile https://github.com/cnlohr/miniosc/):
(also run the output as ./a.out <portnumber>)

#include <stdio.h>
#include <string.h>
#include <unistd.h>

#define MINIOSC_IMPLEMENTATION
#include "miniosc.h"

int main(int argc, char *argv[])
{
    //argv[0] must !!
    int port = atoi(argv[1]);
    
    printf("on oprt %d!!\n", port);

    miniosc * osc = minioscInit(7000, port, "127.0.0.1", 0);


    int frame_n = 0;
    int send_test = 1;

    int neco[7][7];
    memset(neco, 0, sizeof(neco));
    neco[0][0] = 1;

    //printf("%d\n", neco[2][2]);

    char path[100];
    char path_one[] = "/matrix/data";
    snprintf(path, sizeof(path), "/matrix/r%d/c%d", 3, 5);

    while(1)
    {
        //sleep(1);
        for(int a = 0; a < 7; a++) //7 matrix size
        {
            for(int b = 0; b < 7; b++)
            {
                //matrix value, pos x, pos y
                char send_mee[3];
                send_mee[0] = neco[a][b] + '0'; //jupi
                send_mee[1] = a + '0';
                send_mee[2] = b + '0';

                minioscSend(osc, path_one, ",s", send_mee);
            }
        } 
        //send_test++;
        
        //frame_n++;
    }

    return 0;
}

testing_tesing.pd patch im testing this stuff on
Thanks !

@FFW You can dynamically re-create the connections, but of course you need to know the object numbers of the objects in the main patch that you want to connect to the inlet/outlet.
I have had to do this building patchable input /output cords in a matrix..... matrix~.zip
Everything inside [matrix~] is created according to its arguments and then the test patch connects to the abstraction.
The test (matrix-test~.pd) works in extended.... but strangely the object numbers have changed when opened in vanilla. Inside [matrix~] everything creates correctly in both versions.
It should create this....... which demonstrates the principle...

It is best to recreate your main patch with the objects you will want to connect being the first objects created... and then copy back the rest of the patch and connect those objects.
Then if you modify the patch later you will not change those object numbers and break the dynamic cord creation.
David.

@whale-av I looked at [matrix] but I couldn't figure out how to use all the eggs(!) and eyes(!) etc. I would assume you use the same principles in [matrix~] ( or [mtx_*~] ) Could one use [matrix~] with control values too or should one then use two parallell matrixes?

Do you mind giving me an example on how to set this up? Re-route some objects in control and signal domain from input to output?

Are @oid dynamic object solution combinable with this approach? I could try both anyway. Is either one less mean on the cpu? If possible I would like to put the code on a raspberry pi later on.

The controller can do a dump of the current physical patching and knob values but it is of course great to be able to save multiple presets.

thank you for your input this is so cool.

@atux There are 16 [catch~] objects that collect the audio to the mixer sub-patch at the bottom left.
After the mixer everything is mixed to a single [dac~] in masterout...... which is the equivalent of [dac~ 1 2]

You can create a [dac~ 3 4] somewhere and if you have a soundcard with a minimum of 4 outputs that will send audio to outputs 3 and 4.
In the patch you can connect the [catch~] objects that you want to the [dac~ 3 4] that you created.

You could copy the whole mixer for your [dac~ 3 4]..... but you cannot duplicate the [catch~] objects.... so you would have to put a [send~] connected to each [catch~] in the original mixer, and then change each [catch~] in your copy to a [receive~]..... all numbered of course.

You can find the [catch~] objects that you want to connect to by using "Find" in the Pd top menu.
You could also then write their output to wav files if you wish.
David.

@esaruoho Off topic (a little, but it might help).
On the audio side you could reduce the patching and remove the audio from your abstraction by using cyclone [matrix~]
Messages from control in the abstraction could control just one [matrix~] for the entire audio chain.
The same [send] address for every fader, and the corresponding [receive] address for [matrix~]
The [dump( message also lets you construct a state saving mechanism for control parameters.

I use it for a 64in 64out mixer, with eq on all ins and outs..... so a lot of fader abstractions although my colour changes are only occasional (new mix templates update colours on the GUI and touch screen tablets).
David.

@high_output-5000 I think [matrix~] is the way to go as @alexandros suggests..... as it avoids building a matrix of [*~] controlled by the toggle matrix.
I have dynamically patched audio connections directly in the past... but of course clicks as connections are made and broken.
I had missed [numberbox_matrix] and would definitely have used that to create the messages to [matrix~] if I had found it at the time.
It is a very simple solution with no need for sends and receives. You can pass the messages directly from [numberbox_matrix] to [matrix~] and set the fade time in [matrix~] to avoid clicks.
But it means putting a number 1 or 0 in the numberbox rather than just clicking a toggle....... so building a toggle matrix might be better...... however.....

If you only needed one toggle selected at any time then [grid] is back on Deken thanks to Lucarda..... and if you set x max and y max to the same as the number of squares in the [grid] it will output the data you need to control [matrix~].
So for my twopence...... [grid] and [matrix~] gives instant relief for a single toggle selection.

Last thoughts.......
A Data structure could well be easier to build than a toggle matrix and easier on the cpu @jona.
If you are sending any to any (any input to any filter) you could use radio buttons instead of toggles.
Or Ofelia could do the job........ https://forum.pdpatchrepo.info/topic/11792/ofelia-test-grid .... but is a bit heavy.
David.

@high_output-5000 said:

@jameslo That sounds interesting! How do you set up the clone architecture?

Maybe like this? https://forum.pdpatchrepo.info/topic/13500/signalrate-matrix-mixer Let me know if this is not right (and please explain how it's not right) and I'll see if there's a way to make it meet your needs if you can't see it before me. Definitely check out @oid's suggestion too.

I'm a beginner currently working on a 24/24 Toggle matrix to use as a general purpose tool for patching.
The Toggles are organized in a square grid inspired by a design used by a few vintage synths to connect modules together. The toggles basically function as ON/OFF switches for patching signals in a synthesizer.

For example, if the output of a sine wave oscillator is sent to horizontal row ( 4 ) and the input of a filter is connected to vertical row ( e ) they can be connected together by triggering the toggle e4.

By sending (send) or (receive) messages in a message box I was able to give several toggles the same row name. I started manually numbering these but then realized that I’d have to name 1152 of them! Half of them sending and the other half receiving with different letter and number combinations.

Is there a way to give the toggles a two part message that includes the numerical row and the alphabetical row so I don’t have to manually add a number?
Or do some kind of row check similar to a button matrix?

Patch Matrix 1.pd

I'm tired of not having a proper mixer abstraction. (Interestingly, searching http://blazicek.net/list_of_pure_data_objects.html for "mix" turns up nothing related to a mixing framework...?)

I was considering a design something like this:

For sends, I'm inspired by VCV Rack expander modules: Rather than fold a limited number of sends into one bigger abstraction, the mixer abstraction would handle only the main signal chain, and you would add a separate abstraction for each send.

In my mental plan, I was also thinking to have a symbol box at the top so the user could change the name of the mixer interactively... but then discovered in the [throw~] help file that this won't work for the mixer's aux input, because [catch~] doesn't accept any messages (must be [catch~] because many mixers can sum onto one submix or master channel). The only way for it to have a changeable name is based on an abstraction argument...

... so, if you need to change the name, you would have to edit the object string, re-creating the abstraction...

... but then, if I set the level/pan sliders' "init" property to true, then I guess the level/pan settings would be overwritten when re-creating the abstraction. So the behavior would be counterintuitive from the user's perspective: change the name, lose the level. So then I would need a global repository of channel internal IDs and values (but there is no singleton object in Pd yet, so there is no good way to do this either). Storage would have to be global because the abstraction is getting rebuilt, losing all of its local state; thus storage must live outside the abstraction itself.

Same problem for the target of a send: You can't reroute programmatically.

Is there any way around this?

hjh

Hi all,

I am trying to build a pressure sensitive multi-touch pad to use as a kind of keyboard.
For the hardware I build a copper/velostat matrix similar to this one here.
So far I managed to get the pressure value of every row-/column- crossing into PD and sort them. See the patch (screenshot below or link).

My problem is, that I just can't wrap my head around how to calculate a singular float out of the discreet input values of the matrix.

For example: I would like to play and adjust the pitch of a tone by moving my finger along the x-axis of the matrix. So what I need is a float, representing the x-axis location of the peak pressure of my finger.
(Y-axis and pressure values itself will also be needed later on - but i guess one thing after the other...)

I guess the discreet values need to somehow be quantized/merged into one but as I said, I lack the skills of imagining how this needs to be done - be it in PD or written code.

I would be eternally thankful if you could point me into the right direction here.

Thank you already and all the best!
JJ