For jitter objects, the conventional way is to use a name with underscores
instead of dots in your c code. For example, in your jitter code, you call
jit_class_new() with "foo_bar", and in your max wrapper code you call
This appears to be an optional thing for Jitter objects, because if you call
both jit_class_new() and jit_object_new() using "foo.bar" instead of
"foo_bar", the object will still work fine in Max.
I’m used to writing Jitter objects more than regular max obex objects, so I
created an obex object and in my code I wrote class_new("foo_bar", …). Now
the problem is that there appears to be a difference between Max 4 and 5 in
Max 4 will happily instantiate a correct working object, while Max 5 will
give you a pink box without inlets or outlets and no error messages
I found that Max5 will only instantiate the object if you call class_new()
with "foo.bar" instead of "foo_bar", i.e. the same name as the object on
disk / bundle executable.
While chasing this problem I found that Max4 appears to instantiate the obex
object even if you call class_new("some_invalid_name", …). So I guess in
Max4 this name is only stored in the object for possible identification and
is not used for loading the bundle from disk.
This is a summary of my findings:
jitter "foo_bar" ok ok
jitter "foo.bar" ok ok
obex "foo_bar" ok x
obex "foo.bar" ok ok
obex "something" ok x
I’ve only tested this on MacOS 10.5.4 with Max 4.6.3 and 5.0.4
It took me a very long time to figure out what the problem was. Especially
since there are no error messages. The debugger made no sense to me either.
I now know how to get things working of course, but it would be nice if
someone could give a little explanation for why this works like it does.
We’re close to the release of the new sdk, so I guess this might be
irrelevant soon, but I thought it might be worth reporting since it could
possibly prevent people from making the same mistake.