Obex class_new() difference between Max 4, 5 and Jitter

    Aug 17 2008 | 1:55 pm
    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
    jit_object_new(gensym("foo_bar"), ..).
    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
    this regard.
    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:
    max4 max5
    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.

    • Aug 19 2008 | 9:26 am
      I just ran into this myself this morning. Will investigate. Thanks for the report.