« Previous - Version 8/10 (diff) - Next » - Current version
Diemo Schwarz, 2011-02-02 01:53 pm
start spec, correct typos

Integration between Jamoma and FTM

Steps and ways to make Jamoma and FTM get along with each other and
maybe even interoperable.

Specification and Architecture

According to the original proposal and the considerations for Modular 0.6, the spec for implementation would look like this:

Original Proposal (Diemo)

One can identify three levels:

Level 0:

Take care that ftm atoms get through all jamoma externals and are not
mangled like with some nasty max externals (e.g. route, zl).

FTM atoms carry a reference to an ftm data object. They use a type code of 75
and the pointer field to point to the object data structure, allocated on the
heap. For messages carrying a single ftm object, the selector 'ftm_object' can
be used, but 'list' should work also.

Level 1:

Wouldn't it be nice to store an ftm data object, like a matrix of
floats, as a jamoma parameter?

For this to work, all jamoma needs to do is to correctly work the reference
count that triggers garbage collection when a data object is no longer needed:
An incoming object's refcount is incremented (we say "referred"). When it is
replaced by anonther one (or the parameter is deleted), the refcount is
decremented and, if zero, the destructor is called (we call this "release").

How could we do this with minimal code dependency? One idea is that if ftm is
loaded, jamoma detects this via a global symbol, through which jamoma accesses a
table of function pointers with "services" exported by ftm. The two services
for level 1 would be object refer and release. They would be defined by just one shared header file.

Level 1.05

On double-click on the jcom.parameter holding an ftm object, open the ftm.editor, like done by the ftm.object external. (Trond)

Level 1.1

Level 1.1 would be to be able to snapshot or preset an ftm object in text, which
could use ftm's way to store persistent objects in the patch.

This would nor mean that Jamoma would require that the user has FTM installed.
If FTM is not present, then no ftm atoms can come in, and the ftm
services will not be sollicited.

The only problematic case is for level 1.1, if you had serialised ftm objects in
a preset and try to reload that on a machine without ftm installed. Then jamoma
needs to output an error.

Level 1.2

Would it make sense to have a similar functionality than jcom.in/jcom.out for modules working with a stream of matrices (either sound or gesture or other data)?

This could be integrated into jcom.in/out, or alternatively (and more sensibly) be separate modules jcom.gbr.in/out or jcom.ftm.in/out or jcom.fmat.in/out, and would update some iconic visualisation in the jcom.ui (similar to level meters). They would also provide features like mute/bypass.

For this, we'd need a few use cases to see what makes sense and is needed here.

Level 2:

For some cases, it would make sense to interpolate ftm objects like
any parameter, especially matrices of the same size.

This is usually done in ftm using an external ftm.inter, but could be
implemented as another "service" ftm exports.


Do Jamoma and FTM get along when it comes to licensing? FTM is LGPL and Jamoma is now BSD. (Kristian)

As there's no linking or code exchange involved (except for the shared header
file that could be in any license), this shouldn't be an issue.

Potentially complicating things, Jamoma needs to be able to pass matrices and other complex types in the absence of FTM too. (Tim)

Some work on this has started in the JamomaGraph project. Unfortunately, this support is extremely immature. I don't see why we can't do both, but it might be something to think about...

Do we need a specific parameter datatype like "ftmobject", or is "generic" enough?

Wouldn't the special data type would introduce a hard dependency of Jamoma on FTM?

Considering Modular 0.6 developement (Théo)

Level 0 :

now, each there are redesigned/new jcom externals based on Modular 0.6,
it could be possible to convert t_atom into TTValue which could carry reference too.
There is a precise place where the conversion is done and
where we could look at during the workshop (ModularForMax.cpp > jamoma_ttvalue_to/from_Atom)

Level 1 :

a jcom.parameter is now a wrapped instance of a TTData (like jcom.message and jcom.return).
The most important attribute of a TTData is its value which is a TTValue.

So here, if we want a real integration of ftm object in jamoma
(and not just carrying their reference being linked to the Max api),
We have to look deeply in the code of the TTValue during the workshop
(I really don't have a clear picture about how to deal with the refcount
mechanism but I'm pretty sure Tim will have one).

Level 1.1 :

if the TTValue really handles the ftm mechanism, this would allow TTPreset,
TTMapper, the DataspaceLib and many other features to deal with it.

Level 2 :

same as level 1.1, the interpolation feature will deal with TTValue ...

Jamoma and the lllls (Lisp-Like Linked Lists) of Bach

Related to this discussion it might be worth considering the issues that would arise from adding support for the lllls of Bach in Jamoma. lllls seem to resemble FTM tuples quite a bit. However surce code is not currently available for Bach, so the API required for supporting lllls is unknown at the moment.