aps502

I'm trying to setup a skeleton external object that has one attribute called, "numChannels" and when the user changes the value it updates the number of audio signal inlets and outlets accordingly.

I can see from the sdk docs that setting the number of proxy inlets and outlets must be done in the new instance routine "class_new".

However it unclear how to remove or add to this initial number or how to set the total number of inlet or outlets dynamically.

Can anyone point me in the direction of an example?

variable-channel-msp-external

U can use object attributes to let the user change number of inlets/outlets . please read section about the attributes . It will allow u to setup proxies for "signal" dynamically . but note that it will reinit your dsp chain .

Hi !
U can use object attributes to let the user change number of inlets/outlets . please read section about the attributes . It will allow u to setup proxies for "signal" dynamically . but note that it will reinit your dsp chain .


Then u can even bind different perform methods in your dsp64 routine.


I'm confused, I don't know how this helps, I'm finding the documentation a bit unhelpful.

The documentation only shows how to do it using the new class routine, but you seem to saying it can be done using the perform routine.

https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_msp_anatomy.html

At least I am able to setup a custom setter function that will be called if numChannels is changed based on this documentation. 

https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_msgattached.html

Although I don't how to use the set function to then update the actual number of inlets and outlets.

The documentation only shows how to do it using the new class routine, but you seem to saying it can be done using the perform routine.
https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_msp_anatomy.html

At least I am able to setup a custom setter function that will be called if numChannels is changed based on this documentation. https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_msgattached.html

my intention is not to constantly change the number of chanels all the time. Rather it will be constant while the dsp audio is running. I.e. I do not want to change the number of channels during playback.

you will do it all in class_new routine . you just have to process attributes that comes at the object (typed).

you will do it all in class_new routine . you just have to process attributes that comes at the object (typed).
i will show u in one second .


first u have to flag your class in order to respond to typed arguments . Lets choose A_GIMME argument type for now as it is more generic and lets u mix attributes and arguments altogether.

int C74_EXPORT main(void){

    t_class *c = class_new("objectname~", (method)do_new, (method)do_free, (long)sizeof(t_do), nullptr, A_GIMME, 0);
    
    class_addmethod(c, (method)do_dsp64,        "dsp64",    A_CANT,  0);    

    class_dspinit(c);
    class_register(CLASS_BOX, c);
    do_class = c;

    return 0;
}



 routine u could process directly object arguments .

// your A_GIMME argument
void *do_new(t_symbol *s, long argc, t_atom *argv){

    t_do *x = (t_do *)object_alloc(do_class);

    x->inputs = 1 ;

    if(argc){
        x->inputs = atom_getlong(argv);
    }

    dsp_setup((t_pxobject *)x, x->inputs);
    for(auto i = 0 ; i < x->inputs ; i++)
        outlet_new(x, "signal");
    
    return (x);
}



u have additional option to change your dsp routines accordingly to your setup .

void do_dsp64(t_do *x, t_object *dsp64, short *count, double samplerate, long maxvectorsize, long flags){

    if(x->inputs > 1)
        object_method(dsp64, gensym("dsp_add64"), x, perform_moreinlets, 0, nullptr);        
    else
        object_method(dsp64, gensym("dsp_add64"), x, perform_oneinlet, 0, nullptr);    
}



int C74_EXPORT main(void){

	t_class *c = class_new("objectname~", (method)do_new, (method)do_free, (long)sizeof(t_do), nullptr, A_GIMME, 0);
	
	class_addmethod(c, (method)do_dsp64,		"dsp64",	A_CANT,  0);	

	class_dspinit(c);
	class_register(CLASS_BOX, c);
	do_class = c;

	return 0;
}



.
now in your new  routine u could process directly object arguments . 

// your A_GIMME argument
void *do_new(t_symbol *s, long argc, t_atom *argv){

	t_do *x = (t_do *)object_alloc(do_class);

	x->inputs = 1 ;

	if(argc){
		x->inputs = atom_getlong(argv);
	}

	dsp_setup((t_pxobject *)x, x->inputs);
	for(auto i = 0 ; i < x->inputs ; i++)
		outlet_new(x, "signal");
	
	return (x);
}



.
u have additional option to change your dsp routines accordingly to your setup . 

void do_dsp64(t_do *x, t_object *dsp64, short *count, double samplerate, long maxvectorsize, long flags){

	if(x->inputs > 1)
		object_method(dsp64, gensym("dsp_add64"), x, perform_moreinlets, 0, nullptr);		
	else
		object_method(dsp64, gensym("dsp_add64"), x, perform_oneinlet, 0, nullptr);	
}



void *do_new(t_symbol *s, long argc, t_atom *argv){

    t_do *x = (t_do *)object_alloc(do_class);

    x->inputs = 1 ;

    if(argc){
        long offset = attr_args_offset(short(argc),argv);
        if(atom_gettype(argv+(offset+1)) == A_LONG){
            x->inputs = atom_getlong(argv+(offset+1));
        }
        
    }

    dsp_setup((t_pxobject *)x, x->inputs);
    for(auto i = 0 ; i < x->inputs ; i++)
        outlet_new(x, "signal");
    
    return (x);
}


for simplicity it doesnt validate the name of the attribute . u could do it by comparing attribute symbol with "@" to make proper selection . i could post some helpful methods but it would hijack the thread :)

void *do_new(t_symbol *s, long argc, t_atom *argv){

	t_do *x = (t_do *)object_alloc(do_class);

	x->inputs = 1 ;

	if(argc){
		long offset = attr_args_offset(short(argc),argv);
		if(atom_gettype(argv+(offset+1)) == A_LONG){
			x->inputs = atom_getlong(argv+(offset+1));
		}
		
	}

	dsp_setup((t_pxobject *)x, x->inputs);
	for(auto i = 0 ; i < x->inputs ; i++)
		outlet_new(x, "signal");
	
	return (x);
}


.#EDIT
for simplicity it doesnt validate the name of the attribute . u could do it by comparing attribute symbol with "@" to make proper selection . i could post some helpful methods but it would hijack the thread :)


it doesnt work with long ? and the struct member is long type too ?

weird . ive just processed attribute args with long and its working ;/ are u using old SDK ? PM's are in need here Ginger !

Thanks, i managed to get it working so that the first argument determines the number of inlets and outlets using the above examples.

I must admit though, i don't understand what the code after the comment "u have additional option to change your dsp routines accordingly to your setup ." is supposed to be doing extra.

Could you please elaborate? does it allow the number of inlets and outlets to be set dynamically i.e. without the need to type the value as the first argument?

I have no idea what you guys mean regarding @typed attribute, could you please explain?

Thanks, i managed to get it working so that the first argument determines the number of inlets and outlets  using the above examples.

just to clarify . you will process your attributes at the new class creation ,

void *myobject_new(t_symbol *s, long ac, t_atom *av)

whether its argument or attribute passed onto the object . Only there you are creating inlets and outlets .

you are allowed here to bind different perform routine methods (where u do all your real time DSP) under some conditions . In your situation u would use inlets count to determine which method would be added to dsp chain . Must note that typing arguments at the object will reinit your object , which also means that your dsp chain will reset.

After such initialization your dsp64 method is called to set up perform routine .

HI !#EDIT
just to clarify . you will process your attributes at the new class creation , 

 whether its argument or attribute passed onto the object . Only there you are creating inlets and outlets . 

you are  allowed here to bind different perform routine methods (where u do all your real time DSP) under some conditions .  In your situation u would use inlets count to determine which method would be added to dsp chain . Must note that typing arguments at the object will reinit your object , which also means that your dsp chain will reset.
After such initialization your dsp64 method is called to set up perform routine .


@typed attributes are registered attributes of your object (found in inspector) , we are allowed to set them with "@" convertion .

For example youve specified new attribute for your object . lets say interpolation . Now instead of looking at the inspector you could type attribute name and the value right after that .

in order to process such typed attributes beside regular arguments you must call to 

void *myobject_new(t_symbol *s, long ac, t_atom *av){
   t_myobject *x = NULL;
   if (x=(t_myobject *)object_alloc(myobject_class)){
      // initialize any data before processing
      // attributes to avoid overwriting
      // attribute argument-set values
      x->data = 0;
      // process attr args, if any
      attr_args_process(x, ac, av);
   }
   return x;
}



@typed attributes are registered attributes of your object (found in inspector) , we are allowed to set them with "@" convertion .
For example youve specified new attribute for your object . lets say interpolation . Now instead of looking at the inspector you could type attribute name and the value right after that .
[yourobject~ @interpolation 1] 

in order to process such typed attributes beside regular arguments you must call to attr_args_process in your class creation method .

So if I understand correctly i could also use the @ conversion i could also change the number of inlets and outlets for example when in presentation mode. Although this would still reset the dsp chain?

So if I understand correctly i could also use the @ conversion i could also change the number of inlets and outlets for example  when in presentation mode. Although this would still reset the dsp chain?


i think its possible but i would not recommend doing that . it would be better to set up 

 object that has different set of your object instances . Think of the situation where your outlets process some data ... u will have to manage outlet/inlet connections too . And sure it will reset the DSP . I would recommend 

 for such scenarios to not mess with dynamic instantiation/reinitialization via attributes (honestly ive never tried).

i think its possible but i would not recommend doing that . it would be better to set up [poly~] object that has different set of your object instances .  Think of the situation where your outlets process some data ... u will have to manage outlet/inlet connections too . And sure it will reset the DSP . I would recommend [poly~] for such scenarios to not mess with dynamic instantiation/reinitialization via attributes (honestly ive never tried).


I think for the moment i'll focus o getting the main functionality running,

I have already implemented a CUDA GPU real-time convolution engine and im simply hoping to expose it in MAX.

To that end and hopefully get a complete multichannel external skeleton up and running, I'm having trouble with the t_double type in the for loop below, yet this is what the simplemsp example does on the first line.

When a sine tone is passed through this, it currently distorts a sine and then crashes MAX.

(apologies about the formatting i cant get it to look right)

void gpuconv_perform64(t_gpuconv *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sampleframes, long flags, void *userparam)
{
t_double *inL = ins[0];        
t_double *outL = outs[0];    
int n = sampleframes;
int i;
    
    while (n--)
    {
        for (i=0;i

I think for the moment i'll focus o getting the main functionality running, 

Any suggestions?
(apologies about the formatting i cant get it to look right)

void gpuconv_perform64(t_gpuconv *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sampleframes, long flags, void *userparam)
{
t_double *inL = ins[0];		
t_double *outL = outs[0];	
int n = sampleframes;
int i;
	
    while (n--)
    {
        for (i=0;i

the suggestions and code examples that I have seen above don't have anything to do with dynamic inlets/outlets, but rather with setting a variable number of inlets/outlets at object instantiation time. In the latter case it is not a good design strategy to make the number of inlets/outlets an attribute since generally attributes can modify the state of an object anytime during the object's life. With your code however you won't be able to modify dynamically the number of inlets/outlets after the object has been instantiated. If you want to see an example of dynamic inlets/outlets in action you can instantiate a [live.gain~] object and then change the @channels attribute. [plot~] also features dynamic inlets/outlets. (@numplots attribute)

In any case, from what I understand reading this thread, you don't really want dynamic inlets/outlets. You are just looking for a way to set up your object with a certain number of inlets/outlets when the user instantiates the objects in a patcher and then leave it like that.

So let's make your last code example work correctly:

first of all, you need to set a DSP flag in your object new method.

This will tell Max/MSP to use out-of-place processing for all the input and output audio vectors.

Here is the correct version of your code:

void gpuconv_perform64(t_gpuconv *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sampleframes, long flags, void *userparam)
{
    long limit = MIN(numins, numouts);
    long i;
    
    for (i=0;i

here is another, more elegant version of your code:

void gpuconv_perform64(t_gpuconv *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sampleframes, long flags, void *userparam)
{
    long limit = MIN(numins, numouts);
    long numbytes = sampleframes * sizeof (double);
    long i;
    
    for (i=0;i

Please keep in mind that this is untested code, but it should work.

the suggestions and code examples that I have seen above don't have anything to do with dynamic inlets/outlets, but rather with setting a variable number of inlets/outlets at object instantiation time. In the latter case it is not a good design strategy to make the number of inlets/outlets an attribute since generally attributes can modify the state of an object anytime during the object's life. With your code however you won't be able to modify dynamically the number of inlets/outlets after the object has been instantiated. If you want to see an example of dynamic inlets/outlets in action you can instantiate a [live.gain~] object and then change the @channels attribute.  [plot~] also features dynamic inlets/outlets. (@numplots attribute)

In any case, from what I understand reading this thread, you don't really want dynamic inlets/outlets. You are just looking for a way to set up your object with a certain number of inlets/outlets when the user instantiates the objects in a patcher and then leave it like that.
So let's make your last code example work correctly:

void gpuconv_perform64(t_gpuconv *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sampleframes, long flags, void *userparam)
{
    long limit = MIN(numins, numouts);
    long i;
	
    for (i=0;i

void gpuconv_perform64(t_gpuconv *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sampleframes, long flags, void *userparam)
{
    long limit = MIN(numins, numouts);
    long numbytes = sampleframes * sizeof (double);
    long i;
	
    for (i=0;i

Please keep in mind that this is untested code, but it should work.
I hope this helps.

Some good and knowledgeable people have contributed to this thread to help you with your problem.

It would be nice to know if you managed to sort out your variable inlet/outlet issue.

@APS502
Some good and knowledgeable people have contributed to this thread to help you with your problem.
It would be nice to know if you managed to sort out your variable inlet/outlet issue.

I really appreciate the contrubutions, Im currently away from my work until later this week and so I will pick the thread up again on my return. Very briefly though, you are right I do not want to alter the number of channels while the dsp is running, I simply wanted to set the number of channels, instantiate the patch and switch on the dsp. However, it would be preferential to allow the user to set the number of channels when in presentation mode but before the dsp is switched on. i.e. so that editing the patch is not required (but this is just an aesthetic preference and is not pivitol to progressing development).

Variable Channel MSP External