I’m having difficulty adding a list outlet to a MOP object in the location where I want it. I’ve modified the jit.op example code to support a number of matrix inlets and a single matrix outlet. I want the list outlet as the second outlet; it’s giving it to me as the first one.

I am using a call to listout() after a call to max_jit_mop_setup_simple() but before I process attributes using max_jit_attr_args(). This is done at the MOP Max Wrapper level by the constructor to max_fcl_jitagmolto_class. I figure this is a reasonable place to put the call to listout() since this constructor is called after the jitter object is initialized.

Is there a better way to do this? Am I being a bonehead?

I appreciate any advice anyone can offer.

Cheers,

Andrei

>
> I’m having difficulty adding a list outlet to a MOP object in the location
> where I want it. I’ve modified the jit.op example code to support a number
> of matrix inlets and a single matrix outlet. I want the list outlet as the
> second outlet; it’s giving it to me as the first one.
>
> I am using a call to listout() after a call to max_jit_mop_setup_simple()
> but before I process attributes using max_jit_attr_args(). This is done at
> the MOP Max Wrapper level by the constructor to max_fcl_jitagmolto_class. I
> figure this is a reasonable place to put the call to listout() since this
> constructor is called after the jitter object is initialized.
>
>
Jitter object don’t normally *have* outlets. The outlets belong to the Max
wrapper object. This is because Jitter objects can be scripted or
instantiated in objects internally, in which case the outlets don’t exist.
So in order for your object to be able to work, it shouldn’t have any notion
of outlets.

If you want to communicate data from your object to the max patcher
interface, you can best use the notify mechanism. This way your wrapper
class is registered as a client of your Jitter class. The Jitter class can
send the data through a notify message to its clients. The max wrapper will
then parse/interpret the data and format it to its dump outlet, or any other
outlet you created in your wrapper.

Have a look at the jit.notify example. The object used to be missing from
the Windows Jitter sdk.

Cheers,
Thijs

Thanks again for your reply.

Yes, I am creating and trying to write on the outlet in the max mop wrapper, not in the jitter object. While I can write to the dump outlet without any problem, I cannot do the same with the new list outlet I am trying to use.

Using the wrapper as an observer that responds to a notify message is a good idea; I’ve just passed the outlet pointer right to the jitter object, and I can use it in the same manner my code in the max mop wrapper would use it. Again, I can write to the dump outlet without a problem but cannot write to the new list outlet. (I do this because I can bypass the overhead of message processing. My application is the real-time fiducial marker detection Andrew Roth was telling you about in another thread, so we need to conserve cycles!)

Maybe I’m making a mistake somewhere, but I’m not sure why I can write to the dump outlet but cannot write to my list outlet. Incidentally, if I get rid of all the calls from the max mop wrapper code that instantiates the jitter object, I can write to my list outlet without a problem! So, I suspect that the MOP class somehow imposes this limitation. I can’t explain it, and I can’t find anything in the documentation to suggest why this happens.