diaseis

So I had an issue for my external saying that I was sending an output directly into an input. Since I did not do so in my patch, I used the debogger and discovered that ins[2] == outs[0]. I thought it was because of me and I started to minimize the code to see why was that. But now that I've got rid of all the feature, leaving just a skeleton, I'm starting to wonder whether it's a bug.

/*
    split~: An audio version of the Max 'split' object
    Originally known as tap.split~, from Tap.Tools by Timothy Place
    Copyright 2011 Cycling '74
*/

// TODO : optimization when not connected

#include "ext.h"        // standard Max include
#include "ext_obex.h"    // required for "new" (Max 4.5 and later) style objects
#include "z_dsp.h"        // required for audio objects



typedef struct _granolar {
    t_pxobject    s_ob;            // audio object "base class"
} t_granolar;




// method prototypes
void* granolar_new(t_symbol* msg, long argc, t_atom* argv);
void granolar_assist(t_granolar* x, void* b, long m, long a, char* s);
void granolar_int(t_granolar* x, long n);
void granolar_bang(t_granolar* x);
void granolar_float(t_granolar* x, double val);
// (we can skip the prototypes for the perform methods; we'll define them in the body above the point where they are called)
void granolar_dsp64(t_granolar* x, t_object* dsp64, short* count, double samplerate, long maxvectorsize, long flags);


// global class pointer variable
static t_class* s_granolar_class = NULL;



//***********************************************************************************************

void ext_main(void* r)
{
    t_class* c = class_new("truc~", (method)granolar_new, (method)dsp_free, sizeof(t_granolar), NULL, A_GIMME, 0);

    class_addmethod(c, (method)granolar_int, "int", A_LONG, 0);
    class_addmethod(c, (method)granolar_float, "float", A_FLOAT, 0);
    class_addmethod(c, (method)granolar_dsp64, "dsp64", A_CANT, 0);        // New 64-bit MSP dsp chain compilation for Max 6
    class_addmethod(c, (method)granolar_assist, "assist", A_CANT, 0);
    class_addmethod(c, (method)granolar_bang, "bang", 0);

    class_dspinit(c);
    class_register(CLASS_BOX, c);
    s_granolar_class = c;
}


void* granolar_new(t_symbol* s, long argc, t_atom* argv)
{
    t_granolar* x = (t_granolar*)object_alloc(s_granolar_class);

    if (x) {
        dsp_setup((t_pxobject*)x, 3);                // 2 inlets (freq, start,recording)
        outlet_new((t_object*)x, "signal");
    }
    return x;
}


//***********************************************************************************************

void granolar_assist(t_granolar* x, void* b, long msg, long arg, char* dst)
{

}


void granolar_float(t_granolar* x, double value)
{

}


void granolar_int(t_granolar* x, long value)
{

}


void granolar_bang(t_granolar* x) {

}

//***********************************************************************************************




void granolar_perform64(t_granolar* x, t_object* dsp64, double** ins, long numins, double** outs, long numouts, long sampleframes, long flags, void* userparam)
{
/**************** This is the lign of the breakpoint ***********/
    t_double* out = outs[0];    // Output 1

    int            n = sampleframes;

    while (n--) {
        *out++ = 0;
    }
}



//***********************************************************************************************

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

    object_method(dsp64, gensym("dsp_add64"), x, granolar_perform64, 0, NULL);
}


So here is what the debogger says when I place a break point line 99 :

Capture.PNG

Untitled1.maxpat

Hi ! 
So I had an issue for my external saying that I was sending an output directly into an input. Since I did not do so in my patch, I used the debogger and discovered that ins[2] == outs[0]. I thought it was because of me and I started to minimize the code to see why was that. But now that I've got rid of all the feature, leaving just a skeleton, I'm starting to wonder whether it's a bug.
 

/*
	split~: An audio version of the Max 'split' object
	Originally known as tap.split~, from Tap.Tools by Timothy Place
	Copyright 2011 Cycling '74
*/

// TODO : optimization when not connected

#include "ext.h"		// standard Max include
#include "ext_obex.h"	// required for "new" (Max 4.5 and later) style objects
#include "z_dsp.h"		// required for audio objects



typedef struct _granolar {
	t_pxobject	s_ob;			// audio object "base class"
} t_granolar;




// method prototypes
void* granolar_new(t_symbol* msg, long argc, t_atom* argv);
void granolar_assist(t_granolar* x, void* b, long m, long a, char* s);
void granolar_int(t_granolar* x, long n);
void granolar_bang(t_granolar* x);
void granolar_float(t_granolar* x, double val);
// (we can skip the prototypes for the perform methods; we'll define them in the body above the point where they are called)
void granolar_dsp64(t_granolar* x, t_object* dsp64, short* count, double samplerate, long maxvectorsize, long flags);


// global class pointer variable
static t_class* s_granolar_class = NULL;



//***********************************************************************************************

void ext_main(void* r)
{
	t_class* c = class_new("truc~", (method)granolar_new, (method)dsp_free, sizeof(t_granolar), NULL, A_GIMME, 0);

	class_addmethod(c, (method)granolar_int, "int", A_LONG, 0);
	class_addmethod(c, (method)granolar_float, "float", A_FLOAT, 0);
	class_addmethod(c, (method)granolar_dsp64, "dsp64", A_CANT, 0);		// New 64-bit MSP dsp chain compilation for Max 6
	class_addmethod(c, (method)granolar_assist, "assist", A_CANT, 0);
	class_addmethod(c, (method)granolar_bang, "bang", 0);

	class_dspinit(c);
	class_register(CLASS_BOX, c);
	s_granolar_class = c;
}


void* granolar_new(t_symbol* s, long argc, t_atom* argv)
{
	t_granolar* x = (t_granolar*)object_alloc(s_granolar_class);

	if (x) {
		dsp_setup((t_pxobject*)x, 3);				// 2 inlets (freq, start,recording)
		outlet_new((t_object*)x, "signal");
	}
	return x;
}


//***********************************************************************************************

void granolar_assist(t_granolar* x, void* b, long msg, long arg, char* dst)
{

}


void granolar_float(t_granolar* x, double value)
{

}


void granolar_int(t_granolar* x, long value)
{

}


void granolar_bang(t_granolar* x) {

}

//***********************************************************************************************




void granolar_perform64(t_granolar* x, t_object* dsp64, double** ins, long numins, double** outs, long numouts, long sampleframes, long flags, void* userparam)
{
/**************** This is the lign of the breakpoint ***********/
	t_double* out = outs[0];	// Output 1

	int			n = sampleframes;

	while (n--) {
		*out++ = 0;
	}
}



//***********************************************************************************************

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

	object_method(dsp64, gensym("dsp_add64"), x, granolar_perform64, 0, NULL);
}


So here is what the debogger says when I place a break point line 99 : 

Hi ! 
So I had an issue for my external saying that I was sending an output directly into an input. Since I did not do so in my patch, I use

-max-sdk-ins-and-outs-pointers-of-the-perform64-method-are-equal

Hi, I think the problem might be related to this:

https://cycling74.com/forums/signal-inlets-2-wont-work/replies/1

(just put the "Z_NO_INPLACE" flag in your new instance routine to bypass the feature which causes inlets and outlets to share memory)

Hi, I think the problem might be related to this:
https://cycling74.com/forums/signal-inlets-2-wont-work/replies/1 

as Raja pointed out the problem is related to input and output vectors sharing the same memory.

It is an optimization indeed, and like all optimizations it makes your code perform faster. So my suggestion would be NOT to use the Z_NO_INPLACE flag (and therefore disable the optimization) until you have a valid reason to do so. Many algorithms can perfectly work in-place (sample in / sample out)

This has been a topic much discussed in the past.

Please refer to this thread for more info.

https://cycling74.com/forums/problem-with-multiple-msp-inletsoutlets-in-c-api

Hi there,
as Raja pointed out the problem is related to input and output vectors sharing the same memory.
It is an optimization indeed, and like all optimizations it makes your code perform faster. So my suggestion would be NOT to use the Z_NO_INPLACE flag (and therefore disable the optimization) until you have a valid reason to do so. Many algorithms can perfectly work in-place (sample in / sample out)
This has been a topic much discussed in the past.

Please refer to this thread for more info.
https://cycling74.com/forums/problem-with-multiple-msp-inletsoutlets-in-c-api

MSP object inputs not satisifed, likely due to infinite recursion

that it's creating? What should I do with that. Because indeed I replace every part of the input with an output but I still get this issue.

Thank you very much ! So what about this
MSP object inputs not satisifed, likely due to infinite recursion
that it's creating? What should I do with that. Because indeed I replace every part of the input with an output but I still get this issue.



Sorry, I don't understand what you are talking about. Could you maybe post some code?

[Max SDK] Ins and outs pointers of the perform64 method are equal