Forums > Java

MXJ getting wrong inlet


jbm
March 29, 2008 | 4:34 pm

I have an mxj object which is incorrectly identifying the inlet of a message. I placed a "post(getInlet())" at the top of my "public void list()" method, and ran a trace. I can see, during the trace, that the message is clearly being sent to inlet 0, but the mxj is identifying it as "inlet 1" (which causes an error in my patch). What’s even more confusing is that another instance of the mxj, loading exactly the same code, doesn’t have this problem. So it appears to be some sort of messaging error in the max patcher itself.

I tried cleaning the Eclipse project, deleting and re-instantiating the mxj, and even opening the max patch as text, copying it, and doing "new from clipboard." None of these ‘solutions’ worked.

Any ideas?

J.



jbm
March 29, 2008 | 4:37 pm

I should mention that I’m on a Mac Pro 2.8, 10.5.2, so maybe this is a Leopard bug of some kind…



jbm
March 29, 2008 | 5:40 pm

Just in case this was an installation-specific problem, I tried it on my laptop. Same result. Mind you, it’s also running 10.5.2…

Looking more closely at the output, it seems that this particular mxj instance is reporting the most recent inlet to receive input whenever it gets input from inlet 0. Weird. So, if the last inlet used was input 2, then the message to inlet 0 reports inlet 2, if the last inlet used was inlet 1, it reports inlet 1 when inlet 0 gets a message… very odd.

Maybe I’ll try re-building the max patch from scratch, just to see if anything changes.

J.



jbm
March 29, 2008 | 6:05 pm

Okay, so I built a smaller version of the patch. It’s a network-like patch, and my original topology had 4 input nodes, 2 layer 2 nodes, and 1 layer 3 node. Node 1 of layer 2 was reporting the wrong inlet. I built another network, with a smaller topology of just 2 input nodes and 1 layer 2 node. Same error, and same topological location; that is, first node in layer directly below top layer (or, in Max terms, "the mxj instance on the left"). Exact same problem: trace shows the message going to inlet 0, but mxj’s getInlet() reports inlet 1.

Looking for updates I noticed that 10.5 is still "officially" not supported, so I assume I’m on my own. But this should be filed as a bug anyway. Also, Max won’t gracefully exit from tracing – it becomes unresponsive to menu clicks (no spinning ball), then crashes.

Mac Pro 2.8 8-core
16 GB RAM
Apogee duet
MaxMSP 4.6.3
OS X 10.5.2 with all updates

cheers,

J.



jbm
March 29, 2008 | 6:53 pm

Just for kicks I made a patch and mxj to replicate the problem. On my system this demonstrates both the mxj getInlet() problem, and the trace crashing max problem. The interesting thing for me, though, is that it doesn’t explain why one instance of my full network patch actually worked correctly… very strange, indeed.

The patch deliberately makes a loop, so run it with trace enabled! Then you can end your test session with max crashing on the trace problem! ;-)

It would be interesting to see whether this problem is 10.5 (or 10.5.2) specific.

J.


March 29, 2008 | 7:46 pm

This may not be the reason, but in your example you’re doing
declareInlets and declareOutlets (1 of each) followed by an argv-
populated declareIO. I don’t know what happens if you do both.

– N.

Nick Rothwell – nick@cassiel.comhttp://www.cassiel.com
— open-source goodies for MaxMSP: Python, Groovy, Nixie Tubes,
— rotatable text bricks, databases: all at http://www.loadbang.net



jbm
March 29, 2008 | 9:03 pm

Hmmm… Interesting thought. I really just threw that together with quickie, forgetting to delete the declareInlets stuff. But I just tried deleting everything but the declareIO(). Same problem.

J.

Quote: nick rothwell / cassiel wrote on Sat, 29 March 2008 19:46
—————————————————-
> This may not be the reason, but in your example you’re doing
> declareInlets and declareOutlets (1 of each) followed by an argv-
> populated declareIO. I don’t know what happens if you do both.
>
> – N.
>
>
> Nick Rothwell – nick@cassiel.comhttp://www.cassiel.com
> — open-source goodies for MaxMSP: Python, Groovy, Nixie Tubes,
> — rotatable text bricks, databases: all at http://www.loadbang.net
>
>
>
>
—————————————————-



jbm
April 10, 2008 | 10:25 pm

Because of the problem noted in this thread (mxj identifying inlet numbers incorrectly in Leopard), I’m trying to figure out how to send messages to specific methods in mxj objects over max wires. I tried wrapping my data (a double[]) in an Atom[] with the method name at args[0], but the mxj just sends it to the "list()" method. I’m using list() for another purpose, so this won’t work.

Specifically, I tried copying a double[] into a new Atom[] with args[0] manually inserted as the string "recurrent". The target mxj has a "recurrent(double[] in)" method, but it’s not being seen. Instead, the message is going to the "list()" method.

Does anyone know if it’s possible to target named methods over max wires between mxj instances? Why am I bothering? Because messages between mxjs seems to be able to pass arrays of more than 256 elements…

thanks,

J.



jbm
April 10, 2008 | 11:23 pm

duh… false alarm. The method was being accessed as expected. The error was somewhere else. Sorry folks.

J.


April 10, 2008 | 11:41 pm

As an aside. You could do pretty much any sort of complex message to
function invocation mapping you wanted to if you just override the
anything(String message,Atom[] args) and handle all the messages
yourself. I guess in this scenario all your internal methods would
potentially be protected/private instead of public to avoid any confusion.
T



jbm
April 11, 2008 | 1:33 am

Oh, nice – that’s good to know! Could simplify some things in the future. Thanks for that.

cheers,

J.

Quote: topher lafata wrote on Fri, 11 April 2008 00:41
—————————————————-
> As an aside. You could do pretty much any sort of complex message to
> function invocation mapping you wanted to if you just override the
> anything(String message,Atom[] args) and handle all the messages
> yourself. I guess in this scenario all your internal methods would
> potentially be protected/private instead of public to avoid any confusion.
> T
>
—————————————————-



jbm
July 13, 2008 | 3:36 pm

I just opened up my ouletMania patch, as posted above, and noticed that the problem is still there (mxj not recognizing inlet numbers correctly) in Max 5 on Leopard (10.5.4, in my case). It’s not something I use often, but it is a documented bit of functionality, which appears to be broken…

J.


July 13, 2008 | 3:56 pm

On 13 juil. 08, at 17:36, jbmaxwell wrote:

> I just opened up my ouletMania patch, as posted above, and noticed
> that the problem is still there (mxj not recognizing inlet numbers
> correctly) in Max 5 on Leopard (10.5.4, in my case). It’s not
> something I use often, but it is a documented bit of functionality,
> which appears to be broken…

I doubt that it will ever work. I’m quite certain you would have the
same result in C. The problem is that in the same ‘tick’ the object
receive 2 things arriving in the 2 different inlets, so it seems to
override the inlet proxy.

I guess that if you defer your outlet call it will work as you expected.

HTH,
ej



jbm
July 13, 2008 | 4:39 pm

oh, right. That makes sense, and it does work with deferlow. I should point out, though, that the posted patch was just a tester. I originally had the problem a few months ago, in a totally different context, in which there was no tight loop of this sort.

Anyway, it does appear to be working… But does this mean that, even without a loop, we’d have to make sure to defer one of the inlet messages arriving at an mxj, if they happened to arrive at essentially the same time? That seems odd to me, as the right-to-left execution order should be taking care of that, shouldn’t it?

I’d imagine this is the problem I originally had… Or at least something similar. Can’t C-based Max externals manage messages to different inlets, having different functions, by obeying the right-to-left ordering rule?

cheers,

J.


Viewing 14 posts - 1 through 14 (of 14 total)