volker böhm

i'm working on an external that is supposed to process int or float 

i've implemented methods for both input types.

since both processes should output their results to the same outlet, 

i'm not sure which routine to call for creating an outlet in the 

surprisingly something like this seems to work:

void myObj_procInt(t_myObj *x, long value) {

    long result = /* process input */

void myObj_procFloat(t_myObj *x, double value) {

    double result = /* process input */

    x = (t_myObj*)newobject(myObj_class);

    x->out = floatout(x);        //

am i going to run into problems if i keep sending int messages with 

should i better not care about the message-lookup overhead and use x- 

hi,
i'm working on an external that is supposed to process int or float  
input.
i've implemented methods for both input types.
since both processes should output their results to the same outlet,  
i'm not sure which routine to call for creating an outlet in the  
creation function.
surprisingly something like this seems to work:

void myObj_procInt(t_myObj *x, long value) {
	long result = /* process input */
	outlet_int(x->out, result);
}
void myObj_procFloat(t_myObj *x, double value) {
	double result = /* process input */
	outlet_float(x->out, result);
}

void *myObj_new() {
	t_myObj *x;
	x = (t_myObj*)newobject(myObj_class);

	x->out = floatout(x);		//
integers sent to it are output as ints
}

am i going to run into problems if i keep sending int messages with  
outlet_int to an outletfloat?
should i better not care about the message-lookup overhead and use x- 
 >out = outlet_new(x, 0L) instead?

routines-for-creating-outlets

I'm not sure how important it is which outlet creation routine you use, but outlet_new() is supposed to be there for outlets that will send different message types, so that's what I use in the situation you describe.

I understand the SDK documentation to indicate that when outlets can be typed at patch time the runtime engine can be a bit more efficient. But I suspect that is much less of an issue with modern hardware. Don't forget Max 2.2 was running on hardware with clock rates of ~33MHz.

I understand the SDK documentation to indicate that when outlets  can be typed at patch time the runtime engine can be a bit more efficient. But I suspect that is much less of an issue with modern hardware. Don't forget Max 2.2 was running on hardware with clock rates of ~33MHz.


On 05 Jul 2007, at 18:16, Peter Castine wrote:

> I'm not sure how important it is which outlet creation routine you 

> use, but outlet_new() is supposed to be there for outlets that will 

> send different message types, so that's what I use in the situation 

> I understand the SDK documentation to indicate that when outlets 

> can be typed at patch time the runtime engine can be a bit more 

> efficient. But I suspect that is much less of an issue with modern 

> hardware. Don't forget Max 2.2 was running on hardware with clock 

thanks, i think i was hoping to hear something like that.

>
> I'm not sure how important it is which outlet creation routine you  
> use, but outlet_new() is supposed to be there for outlets that will  
> send different message types, so that's what I use in the situation  
> you describe.
>
> I understand the SDK documentation to indicate that when outlets   
> can be typed at patch time the runtime engine can be a bit more  
> efficient. But I suspect that is much less of an issue with modern  
> hardware. Don't forget Max 2.2 was running on hardware with clock  
> rates of ~33MHz.

thanks, i think i was hoping to hear something like that.
outlet_new() is working fine.
volker.


routines for creating outlets