model-related parameters/messages should be turned to methods

[bltzr]

Just like for presets (as explained in #287), we think it would be nicer if model-related parameters/messages were turned to methods (under the model's node)

i.e. /someModel/model/documentation/generate would then be addressed via something like /someModel:documentation/generate This would make the namespace much more thin, on methods that we don't want to addressed in our actual use of Jamoma (e.g. performance)

While we're at it, we could probably try to make these names more consistent, e.g. by replacing those -> by: documentation/generate -> reference/generate edit -> state/edit help -> help/open open -> internals/open (or patcher/open ?) reference -> reference/open address class

[theod]

This is problematic. Actually the /any/address/to/an/object:method or /any/address/to/an/object:attribute is available only if a TTObject is registered below the /any/address/to/an/object node.

In the j.model case it is a TTContainer and this class do not have 'help' or 'internalOpen' message because those service are specific to Max (and not to any C++ application using JamomaModular).

This is working for the preset stuff because this object have generic services that are both usefull at C++ and Max level.

So I propose to close this request as it is irrelevant considering the way JamomaModular works. is this make sense ?

[bltzr]

Can you give me a couple of days to think it over before we close the issue ?

[theod]

sure !

[bltzr]

thinking again about this:

it seems to me that all the messages under model are functions that we don't want to address during performance (or composition), they all are some kind of "utilities": documentation/generate -> reference/generate edit -> state/edit help -> help/open open -> internals/open (or patcher/open ?) reference -> reference/open so... could these just be implemented as (plain Max) messages to the j.model external ? so they don't pester the namespace, but can still be accessed within Max (for example by sending state/edit to [j.send /my/model/name) does that make sense ?

Concerning model/address, I agree that it makes sense to keep it as is, because that can be useful to retrieve it remotely - and also I understand that this is a very sensitive part... though, can we consider again having this as an attribute ? /my/model/name:address ? because if this shows up as being a possible solution, it will be harder to change later than sooner

concerning model/class, I would also have the impression that this should be an attribute.... but if model/address remains as a return, then maybe model/class can remain too... ?

we can discuss that on skype if you prefer, Théo ? do others have opinions ?

[theod]

Le 7 sept. 2013 à 15:38, Pascal Baltazar notifications@github.com a écrit :

thinking again about this:

it seems to me that all the messages under model are functions that we don't want to address during performance (or composition), they all are some kind of "utilities": documentation/generate -> reference/generate edit -> state/edit help -> help/open open -> internals/open (or patcher/open ?) reference -> reference/open so... could these just be implemented as (plain Max) messages to the j.model external ? so they don't pester the namespace, but can still be accessed within Max (for example by sending state/edit to [j.send /my/model/name) does that make sense ?

yes ! I can make them only Max message but in this case you'll cannot access them using a [j.send /my/model/name] as they will not be into the tree anymore (but is this really needed ?).

Concerning model/address, I agree that it makes sense to keep it as is, because that can be useful to retrieve it remotely - and also I understand that this is a very sensitive part... though, can we consider again having this as an attribute ? /my/model/name:address ? because if this shows up as being a possible solution, it will be harder to change later than sooner

IHMO the model/address parameter is needed because we are in Max. I try to imagine this mechanism as a generic mechanism for any C++ application but I can't find example for the moment and so having an address attribute for the TTContainer class would be useless.

maybe better user example will come in the future when people will use Modular in other application but I can't figure this out now.

concerning model/class, I would also have the impression that this should be an attribute.... but if model/address remains as a return, then maybe model/class can remain too... ?

the class is something relative to Max because we organize things in patcher but they can have a different name when they are instantiated. The C++ layer don't need to store this information.

a solution could be to store this into the tag attribute and to remove the model/class return.

we can discuss that on skype if you prefer, Théo ?

I'm available if needed do others have opinions ?

— Reply to this email directly or view it on GitHub.

[bltzr]

aren't we done with this one now ?

[bltzr]

except documentation or reference/generate