Forums > Dev

JS interface for obex objects


December 10, 2008 | 10:51 pm

Lately I find myself making non-graphical objects by using the Jitter API,
only because it gives them instantaneous compatibility with JS and Lua
scripts.

In practice I would prefer to use the Obex API over Jitter, because its a
little cleaner (methods for attributes, atom etc). I was kind of hoping the
new Max5 API would merge the Jitter and Obex methods, since they are almost
the same but not quite compatible, but I don’t see any changes yet.

For some of my objects I decided I like to create custom Lua bindings (for
reasons which are irrelevant now), so one argument to choose Jitter over
obex is gone. I now wonder, how hard would it be to make standard Max (obex)
objects compatible with JS in the same way that Jitter objects are out of
the box?

I know FTM has JS capabilities, but they’re not obex objects afaik. Is there
documentation somewhere to explain how to go about JS-tifying standard obex
objects (gimmeback methods and attributes)? Is it possible at all? Are there
any future changes planned to the Max API that might influence my decision?

It feels wrong to keep using the Jitter API for all sorts of things that
don’t involve graphics or video processing.

Thijs

December 10, 2008 | 11:27 pm

Hi Thijs,

There is an undocumented way to do this now. I can’t guarantee that it
will be supported in the future, but you can safely use it until
something changes. Just make a .js file (name isn’t important), and
put it in the jsextensions folder. For each "nobox" class you’d like
to wrap with a JS interface, add a line like the following:

maxclasswrap("mymaxclassname","MyJavascriptClassName");

This will automatically create a class definition wrapped with the
appropriate methods and instantiable in JS like this

var mything = new MyJavascriptClassName();

Hope that helps. Otherwise you’ll need to build a C jsextension which
does the manual wrapping for all your classes similar to what you may
have done for Lua.

FWIW, Jitter inner classes and obex classes are virtually the same
under the hood–e.g. jit_class_new("classname") just calls
class_new("jitter","classname").

-Joshua

December 11, 2008 | 1:22 pm

On Thu, Dec 11, 2008 at 12:27 AM, Joshua Kit Clayton wrote:

>
> There is an undocumented way to do this now. I can’t guarantee that it will
> be supported in the future, but you can safely use it until something
> changes. Just make a .js file (name isn’t important), and put it in the
> jsextensions folder. For each "nobox" class you’d like to wrap with a JS
> interface, add a line like the following:
>
> maxclasswrap("mymaxclassname","MyJavascriptClassName");
>
> This will automatically create a class definition wrapped with the
> appropriate methods and instantiable in JS like this
>
> var mything = new MyJavascriptClassName();

If they have to be nobox how would I then use them in the patcher world?
With Jitter objects, the methods and attributes are automatically exposed to
the patcher interface by using the max_jit_classex_standard_wrap() method
right? So if I were to declare my objects as "nobox" how would I be able to
create max box wrappers for them?

>
> Hope that helps. Otherwise you’ll need to build a C jsextension which does
> the manual wrapping for all your classes similar to what you may have done
> for Lua.
>
> FWIW, Jitter inner classes and obex classes are virtually the same under
> the hood–e.g. jit_class_new("classname") just calls
> class_new("jitter","classname").
>
>
Maybe I should stick with the current Jitter approach for now. I got myself
tangled up in a bit of an ambitious project creating a data framework for
Max. As things progressed I completely separated the framework from the
Max/Jitter API, to the point where I don’t need to link against the API
frameworks.

I create the Max objects as a bridge between the 2, acting as wrappers for
my classes, passing over messages and parsing atoms in order to convert
things back and forth. Because this current approach uses multiple layers of
abstraction, I was looking for a more direct approach for the JS/Lua
interface by talking more directly to my framework.

It seems silly to for example, to convert Lua to Max/Jitter and then to my
own objects. This would convert numbers and symbols in the Lua world to
atoms and symbols, and then those are parsed and redirected to communicate
with my framework.

I think the only correct approach is to go all the way and do both the Lua
and JS bindings manually. I hope I can find the time, but I think I’ve
already passed the point of no return.

Best,
Thijs

December 11, 2008 | 5:52 pm

On Dec 11, 2008, at 5:22 AM, Thijs Koerselman wrote:

>
> If they have to be nobox how would I then use them in the patcher
> world? With Jitter objects, the methods and attributes are
> automatically exposed to the patcher interface by using the
> max_jit_classex_standard_wrap() method right? So if I were to
> declare my objects as "nobox" how would I be able to create max box
> wrappers for them?

The logic of max_jit_classex_standard_wrap() is pretty simple. It just
runs through the attributes and messages of the jitter class, and then
adds the appropriate wrappers. This is the same thing we do with the
generic language binding for JS, Lua, JS. A "box" class is befuddled
with notions of inlets and outlets, which aren’t applicable outside of
a Patcher, so they don’t make much sense wrapped as JS or Lua objects
IMHO.

> I think the only correct approach is to go all the way and do both
> the Lua and JS bindings manually. I hope I can find the time, but I
> think I’ve already passed the point of no return.

Personally, I think all the maintenance for building direct language
bindings is much more work than building the generic language bindings
like we have in maxclasswrap() or JitterObject, but whatever you find
works best for you.

-Joshua

December 11, 2008 | 7:22 pm

On Thu, Dec 11, 2008 at 6:52 PM, Joshua Kit Clayton wrote:

>
> The logic of max_jit_classex_standard_wrap() is pretty simple. It just runs
> through the attributes and messages of the jitter class, and then adds the
> appropriate wrappers. This is the same thing we do with the generic language
> binding for JS, Lua, JS. A "box" class is befuddled with notions of inlets
> and outlets, which aren’t applicable outside of a Patcher, so they don’t
> make much sense wrapped as JS or Lua objects IMHO.
>
>
> I think the only correct approach is to go all the way and do both the Lua
>> and JS bindings manually. I hope I can find the time, but I think I’ve
>> already passed the point of no return.
>>
>
> Personally, I think all the maintenance for building direct language
> bindings is much more work than building the generic language bindings like
> we have in maxclasswrap() or JitterObject, but whatever you find works best
> for you.
>

Thanks a lot for your advise Joshua. I’ll give it a good night sleep.

Best,
Thijs

February 18, 2009 | 2:01 pm

JKC wrote:

> Otherwise you’ll need to build a C jsextension

is there any chance this could be documented, or at least an example provided?

cheers,

oli

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

Forums > Dev