jamie

I'm in the process of porting one of my PD externals to Max/MSP, and

I've run into what seems to be a strange problem. In the PD object, the

first inlet and and first outlet are for control data, the others are

used for audio data. I try doing this in Max/MSP, and when I connect the

rightmost outlet to the inlet of another audio object I get:

error: ugen_connect dssi~ dac~ -1 1 (2 2)

dsp_setup((t_pxobject *)x, x->plugin_ins);

for(i = 0;i < x->plugin_outs; i++) outlet_new((t_pxobject *)x,

x->control_outlet = outlet_new ((t_pxobject *)x, "control");

The external works fine if outlet_new((t_pxobject *)x, "control") is

called first, but of course this results in the rightmost outlet being

the control outlet which is not what I want.

Is it a Max/MSP convention to have the in/outlets in a specfic order, or

I'm in the process of porting one of my PD externals to Max/MSP, and
I've run into what seems to be a strange problem. In the PD object, the
first inlet and and first outlet are for control data, the others are
used for audio data. I try doing this in Max/MSP, and when I connect the
rightmost outlet to the inlet of another audio object I get:

for(i = 0;i < x->plugin_outs; i++) outlet_new((t_pxobject *)x,
"signal");

The external works fine if outlet_new((t_pxobject *)x, "control") is
called first, but of course this results in the rightmost outlet being
the control outlet which is not what I want.

Is it a Max/MSP convention to have the in/outlets in a specfic order, or
am I doing something wrong in my code?

outlet-creation-order

> I'm in the process of porting one of my PD externals to Max/MSP, and

> I've run into what seems to be a strange problem. In the PD object, the

> first inlet and and first outlet are for control data,

In Max you have to create the outlets the other way round (right to 

Jamie Bullock wrote:
> Dear Max/MSP dev'ers,
>
> I'm in the process of porting one of my PD externals to Max/MSP, and
> I've run into what seems to be a strange problem. In the PD object, the
> first inlet and and first outlet are for control data,

In Max you have to create the outlets the other way round (right to 
left), not left to right as in Pd.

On Mon, 2007-02-05 at 12:08 +0100, Olaf Matthes wrote:

> In Max you have to create the outlets the other way round (right to 

Yes, but my question is: is it possible for the outlets to be of

arbitrary type "signal"/"control"? My problem occurs if I try to make

the leftmost outlet a control outlet, and the rest signals. The other

>
> In Max you have to create the outlets the other way round (right to 
> left), not left to right as in Pd.
>

Yes, but my question is: is it possible for the outlets to be of
arbitrary type "signal"/"control"? My problem occurs if I try to make
the leftmost outlet a control outlet, and the rest signals. The other
way round, things work fine.

Just to confirm, I had the same experience. I gave up, and placed my 

On Feb 5, 2007, at 3:36 AM, Jamie Bullock wrote:

> On Mon, 2007-02-05 at 12:08 +0100, Olaf Matthes wrote:

>> In Max you have to create the outlets the other way round (right to

> Yes, but my question is: is it possible for the outlets to be of

> arbitrary type "signal"/"control"? My problem occurs if I try to make

> the leftmost outlet a control outlet, and the rest signals. The other

Just to confirm, I had the same experience.  I gave up, and placed my  
message outlet last (rightmost) instead.

> On Mon, 2007-02-05 at 12:08 +0100, Olaf Matthes wrote:
>
>>
>> In Max you have to create the outlets the other way round (right to
>> left), not left to right as in Pd.
>>
>
> Yes, but my question is: is it possible for the outlets to be of
> arbitrary type "signal"/"control"? My problem occurs if I try to make
> the leftmost outlet a control outlet, and the rest signals. The other
> way round, things work fine.
>
> Jamie
>


On Mon, 2007-02-05 at 09:35 -0800, Joshua Kit Clayton wrote:

> On Feb 5, 2007, at 3:36 AM, Jamie Bullock wrote:

> Your findings are correct and described in the SDK documentation. 

> First paragraph of "Writing MSP Code":"New Instance Routine":

Ooops. Thanks for the info. I should have RTFM :)

On Mon, 2007-02-05 at 09:35 -0800, Joshua Kit Clayton wrote:
> On Feb 5, 2007, at 3:36 AM, Jamie Bullock wrote:
>
> Your findings are correct and described in the SDK documentation.  
> First paragraph of "Writing MSP Code":"New Instance Routine":
>

@JoshuaKitClayton What did you say here? your comment was erased. This paragraph doesn't seem to be in the documentation and I'm getting the same error (and crashes)

http://peabody.sapp.org/class/350.838/read/WritingMax_MSPExternals.pdf

I know I'm reviving a four year dead thread, but @AudioMatt came back after 10 years, so maybe somebody else will too.

This seems also to be the case in the min-devkit. Max 8 shows the ugen_connect issue and follows with a complaint about infinite recursion.

This seems to be outlined here:
http://peabody.sapp.org/class/350.838/read/WritingMax_MSPExternals.pdf 

Bottom of page 209.

I know I'm reviving a four year dead thread, but @AudioMatt came back after 10 years, so maybe somebody else will too.

This seems also to be the case in the min-devkit. Max 8 shows the ugen_connect issue and follows with a complaint about infinite recursion.


Outlet creation order