j.modular doc

classic Classic list List threaded Threaded
8 messages Options
jln
Reply | Threaded
Open this post in threaded view
|

j.modular doc

jln
Administrator
Hi,

Following Ricardo’s question regarding j.modular, could someone (*ahem* Theo ?) give me a short broken english description of the following messages and attributes, I’ll be more than happy to write maxhelp & refpage for j.modular.

- @debug
- @activity : is it just = an @active attribute ?
- @type
- namespace/build: as I get it, it grabs the namespace from a distant app, right ? Couldn’t it be renamed namespace/grab, then ?
- namespace/observe
- object/*
- protocol/scan

Best,
Julien

PS: If we are to split j.modular into different externals in the near future, shouldn’t we make some abstractions so patches are not broken after release ?



------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: j.modular doc

Pascal Baltazar-5
Hi !

Thanks for the initiative !

I’m not 200% sure of all of these, bu I’ll try to answer (sorry if my English is not broken enough…)
>
> - @debug
I guess that posts debug messages to the Max window - never actually used it, though...
> - @activity : is it just = an @active attribute ?
nope, this sends all incoming and outcoming messages to [j.receive /:activity/in] (or /out)
> - @type
local for local device (only one argument provided to j.modular: protocol used
mirror for a remote application (tow arguments provided to j.modular: remote device name and protocol used)

BTW, maybe this could be changed and this attribute made more explicit, instead of using @name in the case of local
Maybe that should even be two  separate externals, because they have very different functions….

> - namespace/build: as I get it, it grabs the namespace from a distant app, right ? Couldn’t it be renamed namespace/grab, then ?
it explores and mirrors the remote device/app - so namespace/mirror ?
> - namespace/observe
observes the remote app
> - object/*
maybe for adding nodes in an OSC namespace ??? (BTW, there’s a typo to “retrieve »)
> - protocol/scan
I guess that scans for available protocols….
>
> Best,
> Julien
>
> PS: If we are to split j.modular into different externals in the near future, shouldn’t we make some abstractions so patches are not broken after release ?
Very good idea !!!

p

>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: j.modular doc

Renaud Rubiano

>> PS: If we are to split j.modular into different externals in the near future, shouldn’t we make some abstractions so patches are not broken after release ?
> Very good idea !!!
+ 1

------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
jln
Reply | Threaded
Open this post in threaded view
|

Re: j.modular doc

jln
Administrator
In reply to this post by Pascal Baltazar-5
Hi,

Thanks for the feedback. After some sleep and NOT looking at j.modular maxhelp, things are a little more obvious. :-)

(sorry if my English is not broken enough…)
I’ll cope with that :-) 
> - @activity : is it just = an @active attribute ?
nope, this sends all incoming and outcoming messages to [j.receive /:activity/in] (or /out)
Yes, I realised that once in my bed... 
> - @type
local for local device (only one argument provided to j.modular: protocol used
mirror for a remote application (tow arguments provided to j.modular: remote device name and protocol used)
I notice there is also a ‘proxy’ value (for OSC app ?). 
BTW, maybe this could be changed and this attribute made more explicit, instead of using @name in the case of local
Maybe that should even be two separate externals, because they have very different functions….
Then as I get it, this is read-only and could/should be hidden, right ? 

More on the seperating externals option in the following mail.
> - namespace/build: as I get it, it grabs the namespace from a distant app, right ? Couldn’t it be renamed namespace/grab, then ?
it explores and mirrors the remote device/app - so namespace/mirror ?
namespace/explore ? That sounds a bit more inline with the workflow to me. Again, another proposal in a following mail. 
> - namespace/observe
observes the remote app
Yep. 
> - object/*
maybe for adding nodes in an OSC namespace ??? (BTW, there’s a typo to “retrieve »)
mmm… *scratch scratch* 
> - protocol/scan
I guess that scans for available protocols….
I’d bet on this as well :-) I’ll test and see 

Thanks !

Best,
Julien

------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: j.modular doc

Pascal Baltazar-5

> - @activity : is it just = an @active attribute ?
nope, this sends all incoming and outcoming messages to [j.receive /:activity/in] (or /out)
Yes, I realised that once in my bed… 
What happens in your bed is out of our concern
> - @type
local for local device (only one argument provided to j.modular: protocol used
mirror for a remote application (tow arguments provided to j.modular: remote device name and protocol used)
I notice there is also a ‘proxy’ value (for OSC app ?). 
no idea whatsoever
BTW, maybe this could be changed and this attribute made more explicit, instead of using @name in the case of local
Maybe that should even be two separate externals, because they have very different functions….
Then as I get it, this is read-only and could/should be hidden, right ? 
probably

or just removed with separate externals

More on the seperating externals option in the following mail.
> - namespace/build: as I get it, it grabs the namespace from a distant app, right ? Couldn’t it be renamed namespace/grab, then ?
it explores and mirrors the remote device/app - so namespace/mirror ?
namespace/explore ? That sounds a bit more inline with the workflow to me.
I also thought about it, so maybe that’s the right one ?
Again, another proposal in a following mail. 
> - namespace/observe
observes the remote app
Yep. 
> - object/*
maybe for adding nodes in an OSC namespace ??? (BTW, there’s a typo to “retrieve »)
mmm… *scratch scratch* 
This one definitely requires Théo’s input… but anyway, I’m not certain at all this is a basic feature of the object…
> - protocol/scan
I guess that scans for available protocols….
I’d bet on this as well :-) I’ll test and see 

Thanks !

De nada !

p


Best,
Julien
------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
jln
Reply | Threaded
Open this post in threaded view
|

Re: j.modular doc

jln
Administrator
In reply to this post by jln
Hi Again :)




<pre><code>
----------begin_max5_patcher----------
1703.3oc0ZssaiaCD8YmuBB8TKPhiH089RyhtEEXQKZQWf9xtEFTRL1LQVTk
hJW5h8eu7hjLkircRVaWGr.xNjRTyblyblgz6WNahSJ6ARsC3G.eBLYxWNax
D8PpAlz92SbVheHq.WquMmL1xkjRgy4l4DjGD5w+Eh.fAEzZAfcMHqgyk2Uw
ifZhnoBfqpJnYXAkUV28nEzRRFqoT+7n1AKaVRKKHB8KC1NXZSZZAwdjJNoV
t95EbFmjILt.D4M08bPXb3zfyAtpuKu.961mhlqMUV5MW3A6LiqYkhR7R8x6
7qXAC7mj4MEXtyJSh0H5rI2A1jx8Wh4yokZqqaxJrHaAsb9HlVBRYZvXj5u7
SrrNkgTS+WiepldEBmwJXby53N06bqKPqEnV7nAkbbTC70yNSc47mYfcIotF
Om7j.qUn6RU30YrHEZ6wETfw2iZiHaNr3NNp2E2MCIdrhXVXGm9UYDL2.4Qt
gpOh0WQn8FfsoLAF2lteYNQQS.+HfSVxtS9EmsQ02DwNQyWBUDlsifnjuQh8
Xb2t2dr5CXj1HPvWA2M7bqKGWtaVAAKiLkLwBB+cUUuJdLzBG1ZTHd+yi6f+
PuiDQlHxltUxpsCGs+ocHnuxSCRzNrm6oFqaS31MSKIh6Y7aA4D4cKoRWtDW
J4mCJCBXk.IUDzcuRfRsfMkpaf.tmJV7xqTZGQBN.BA5.RjVM22Uql6EuV.4
Zb1fR0CBRdG8fzM0MzN+LkwyIbaebTP7ZZAoGuVPJpxIBLsnd5M88tXiy6yL
cC.CiM7dMNqttRhYdISd2RRzsCpZf4R6UP3yjFdaqRct3M0x9SZTD0197VwO
klxARrkkVS3xhceaxsdZ4Vee3Nka81+xssxNcU6N7xsezzoLHW1jEtTXKVb.
aY1OHQ0PZf+t5XFgNxcL66GZZUNV+AL5Tqi4MEH+4GpjubI4GTK8nBxQJRBi
CT.kWHZmoKG8M+DEoIYtlPoIA6s1leHsgU5E0YxOeU8OpE18h1sf1AXePAHM
w.F3djDz9N7sXfhcUWI6I3xzFZQ92C5yNJJdtGNf29I+HPWOEkDtKzGlbryO
LRc9dAlHjuoe+2j4GupB8FJY7NOe.3AXeU9AZBADBOR4EiTfGfEBNMsQPpAK
wOBRIc6cHGPKyIUD4E04oc.yOPcau2emQgnib9AJRaNdHS6wgAuEyOLhcsUO
.UblfIMM.qN6h+ogve7UUPQmw.S14wBAC2+INdA52NxGsmSbd4nIsRF0kVi7
evWENlXn96rvLL3.fidlSzw8XcBku2Hs.DKn0fOfWxVhuHEWK0ZrkjFd9D6i
FWswQ+icI1XygAm39F9722LoGTw3B.TlRlrRZ42nkMzW0A1CCMBtAd6Lg.s+
SHPlSXxyTP5+EgE0g0KH+EMmv9CkYpA6DzTXnzllFXf6HWWzJz92+3OsUn1F
zFeCXuiSwEG.3z0P1g6ac5Rx8Ru4InYEX0Ifd0.R5Ucvl5qCYoJ3CbkBJ.3l
bZKpeEtQrfwAe14CrEkf2yHe1Ab0cDdsRgxc5npRAOySHEtcElAI8IwIn.8o
S5KaPJDoyG7fw9AC0.17uBUTj0tuhBGOHXuJlSpbRO1aNXxVe2xklnnuVCOw
5QTAraLdQz48CQKY1mBpbHN4NZ2yGzOJlK8EgzQZ3F66g3t1HTKCKmvkgNso
XFTRcNqaA6b+.SoU218znce+XK0DIKadAK6VRtsM4vj87RKs0mFLcN4ZbSgX
13p1Cmu6HoGcxQy9l3LmSyYkJiX.TqFt60o1RoIlZ6L56nDWMxCKIcRXYCSJ
2SfnoNEyUQh1BmntIELVwvo5etBx0h1oqnkkqghBV0lmjSmuXKOaJSN4xss1
5Ypm0TZlclTYPLqFe2PzVH2peqTwvk+AbIcIVPDTSH.41Oo4brWTmwYEEC7W
yL2MxL4RRbF4dZtXg9EYSFj2NspiD4zGkyoyI0hgiIvyqGNxSRPkC0j1ljNS
PVVUH8hg2vf+iUXmQZKpNX70DW0RW8YaqKm4ZMwHRZatBxNphrw1mZo5leAT
y908rShGGmL5nltP6qxLoqRi4KqRcTp3sXl4WlnWPwQQpxmYRflsZyxqqP9h
BzRUmTbQaXrWFXaQ8UTiyV4DsEM0tgsKzUCU+BTiOrRZMqgm0g+c+ee.rppf
zUDzxdguO0GfstmEz7bhstn5rEToGlD0QKo+bMG0uoxoj4bZgNpCh5TxbBOs
LmfSKyAdZYNnCn4XjgVqiPkkrVmfq0E3S6.byc+sdmex27WO6+DqsipA
-----------end_max5_patcher-----------
</code></pre>

PS: If we are to split j.modular into different externals in the near future, shouldn’t we make some abstractions so patches are not broken after release ?
I remembered we talked about this hence I asked again about it. However, while thinking at it this morning, I wonder whether it is a good design idea or not. But truth is I dont remember at all the reasoning behind the idea of splitting j.modular… So please, a short summary would be helpful if I’m missing something obvious. Anyway, I paste below a little workflow-based brainstorm sketch I did this morning, based on what seems confusing to me as j.modular is at the moment. That is:

- j.modular do two very different things based on the number of arguments. This is hard workflow-wise imho. However, rather than splitting things, maybe we should rather re-work the object and put a focus at the right place and clarify how it inserts itself in the workflow. 

- Currently, it is not clear to me where is that focus. Is it an application-oriented approach ? Is it a protocol-oriented approach ? Of course both are related, but I feel we have room to clarify the focus. Hence my attempt at a « generic » j.network.

- I am not fond of having to create an object in my patch to declare it on the network. Then, do the same on a second patch on a distant application, then add an object in my first patch to declare the remote to my second patch, then add an object in my second patch to declare a remote to my first patch, etc… This surely is explicit but a bit fastidious. + I’m not sure it is good to have to hard-code this in a patch (well, I could actually be sure it is not ;-)

Anyway, here a patch I did while brainstorming. Obviously, object and message names are mainly to get an idea. And not all features are here. Again, just brainstorming.

Best,
Julien

------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: j.modular doc

Théo de la Hogue-2
In reply to this post by Pascal Baltazar-5
Hi,
sorry for the huge delay on this.

> Le 5 sept. 2015 à 08:31, Pascal Baltazar <[hidden email]> a écrit :
>
> Hi !
>
> Thanks for the initiative !
>
> I’m not 200% sure of all of these, bu I’ll try to answer (sorry if my English is not broken enough…)
>>
>> - @debug
> I guess that posts debug messages to the Max window - never actually used it, though…
it allows to enable the post of some debugging messages I use in externals code.

>> - @activity : is it just = an @active attribute ?
> nope, this sends all incoming and outcoming messages to [j.receive /:activity/in] (or /out)
it have been renamed into @monitor
https://github.com/jamoma/JamomaMax/issues/954

>> - @type
> local for local device (only one argument provided to j.modular: protocol used
> mirror for a remote application (tow arguments provided to j.modular: remote device name and protocol used)
>
> BTW, maybe this could be changed and this attribute made more explicit, instead of using @name in the case of local
> Maybe that should even be two  separate externals, because they have very different functions….
this one should be hidden as it is a very criptic information for Max users.

>> - namespace/build: as I get it, it grabs the namespace from a distant app, right ? Couldn’t it be renamed namespace/grab, then ?
> it explores and mirrors the remote device/app - so namespace/mirror ?
ok for mirror

>> - namespace/observe
> observes the remote app
>> - object/*
> maybe for adding nodes in an OSC namespace ??? (BTW, there’s a typo to “retrieve »)
to hide !
https://github.com/jamoma/JamomaMax/issues/952

>> - protocol/scan
> I guess that scans for available protocols….
this was initially to use the scanning feature of a protocol in order to find applications over a network.
this is not working so I should hide it.
https://github.com/jamoma/JamomaMax/issues/953

>>
>> Best,
>> Julien
>>
>> PS: If we are to split j.modular into different externals in the near future, shouldn’t we make some abstractions so patches are not broken after release ?
> Very good idea !!!
+1 !

Best,
TO

>
> p
>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Jamoma-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: j.modular doc

Théo de la Hogue-2
In reply to this post by jln
Hi Julien,
thanks for this draft.

actually we have the same desing problem in the OSSIA C++ API Network part.
the last time in Paris, Jean-Michaël and me have discussed about that so I would like to share you our conclusions.

we decide to have two main classes: Namespace and NamespaceHandler.

the Namespace is a tree structure made of Nodes and some of them refers to Address (e.g. parameter in Jamoma).
when you make an application you deal with severals Namespaces: one for you own application, one for a distant OSC application or a MIDI controller, …
but they are all Namespaces and you don’t care to know if they are distant or not.

however at some point you need to describe how Namespaces are handled and this description depends on the network point of view where you start the description from. I mean many things can be connected together but some network points doesn’t need to be aware of all the other points. 
and from the point of view you start a network point can be seen as a server or client.

that’s why we decide to forget about old Application or Device and Protocol classes for a generic interface (C++ speaking) called NamespaceHandler.
there are many differents NamespaceHandler to make available: 

- MinuitServer(port)
- MinuitClient(ip, in_port, out_port)

- OSCServer(port)
- OSCClient(ip, in_port, out_port)

- WebsocketServer(?)
- WebsocketClient(?)

- MIDIInput(?)
- MIDIController(?)
- ?

- OSCQueryServer(?)
- OSCQueryClient(?)

- and more to do for DMX, Serial, … ?
All those NamespaceHandlers have to provide what to do for the following actions:

- handle(Namespace) : depending on the NamespaceHandler, it will build a mirror or a proxy tree for client or just prepare to receive request for server.
- detach(Node) : allow to remove a Node to not be handled by the NamespaceHandler.
- attach(Node) : allow to add a Node to be handled by the NamespaceHandler.
- map(Address, any arguments) : allow to link a specific NamespaceHandler message with an Address of the Namespace (particularly useful in MIDI, DMX or Serial case)

Notice at this level of the API doesn’t provide file managment to save or recall a Namespace as those features are part of the APIToolkit.

All this architecture is still not available in OSSIA but I plan to work on this soon.
of course the use of OSSIA in Jamoma is not for tomorrow but it can helps to design some patchers on top of existing j.modular external.

Hope this helps !

Best,
TO

Le 5 sept. 2015 à 13:04, Julien Rabin <[hidden email]> a écrit :

Hi Again :)




<pre><code>
----------begin_max5_patcher----------
1703.3oc0ZssaiaCD8YmuBB8TKPhiH089RyhtEEXQKZQWf9xtEFTRL1LQVTk
hJW5h8eu7hjLkircRVaWGr.xNjRTyblyblgz6WNahSJ6ARsC3G.eBLYxWNax
D8PpAlz92SbVheHq.WquMmL1xkjRgy4l4DjGD5w+Eh.fAEzZAfcMHqgyk2Uw
ifZhnoBfqpJnYXAkUV28nEzRRFqoT+7n1AKaVRKKHB8KC1NXZSZZAwdjJNoV
t95EbFmjILt.D4M08bPXb3zfyAtpuKu.961mhlqMUV5MW3A6LiqYkhR7R8x6
7qXAC7mj4MEXtyJSh0H5rI2A1jx8Wh4yokZqqaxJrHaAsb9HlVBRYZvXj5u7
SrrNkgTS+WiepldEBmwJXby53N06bqKPqEnV7nAkbbTC70yNSc47mYfcIotF
Om7j.qUn6RU30YrHEZ6wETfw2iZiHaNr3NNp2E2MCIdrhXVXGm9UYDL2.4Qt
gpOh0WQn8FfsoLAF2lteYNQQS.+HfSVxtS9EmsQ02DwNQyWBUDlsifnjuQh8
Xb2t2dr5CXj1HPvWA2M7bqKGWtaVAAKiLkLwBB+cUUuJdLzBG1ZTHd+yi6f+
PuiDQlHxltUxpsCGs+ocHnuxSCRzNrm6oFqaS31MSKIh6Y7aA4D4cKoRWtDW
J4mCJCBXk.IUDzcuRfRsfMkpaf.tmJV7xqTZGQBN.BA5.RjVM22Uql6EuV.4
Zb1fR0CBRdG8fzM0MzN+LkwyIbaebTP7ZZAoGuVPJpxIBLsnd5M88tXiy6yL
cC.CiM7dMNqttRhYdISd2RRzsCpZf4R6UP3yjFdaqRct3M0x9SZTD0197VwO
klxARrkkVS3xhceaxsdZ4Vee3Nka81+xssxNcU6N7xsezzoLHW1jEtTXKVb.
aY1OHQ0PZf+t5XFgNxcL66GZZUNV+AL5Tqi4MEH+4GpjubI4GTK8nBxQJRBi
CT.kWHZmoKG8M+DEoIYtlPoIA6s1leHsgU5E0YxOeU8OpE18h1sf1AXePAHM
w.F3djDz9N7sXfhcUWI6I3xzFZQ92C5yNJJdtGNf29I+HPWOEkDtKzGlbryO
LRc9dAlHjuoe+2j4GupB8FJY7NOe.3AXeU9AZBADBOR4EiTfGfEBNMsQPpAK
wOBRIc6cHGPKyIUD4E04oc.yOPcau2emQgnib9AJRaNdHS6wgAuEyOLhcsUO
.UblfIMM.qN6h+ogve7UUPQmw.S14wBAC2+INdA52NxGsmSbd4nIsRF0kVi7
evWENlXn96rvLL3.fidlSzw8XcBku2Hs.DKn0fOfWxVhuHEWK0ZrkjFd9D6i
FWswQ+icI1XygAm39F9722LoGTw3B.TlRlrRZ42nkMzW0A1CCMBtAd6Lg.s+
SHPlSXxyTP5+EgE0g0KH+EMmv9CkYpA6DzTXnzllFXf6HWWzJz92+3OsUn1F
zFeCXuiSwEG.3z0P1g6ac5Rx8Ru4InYEX0Ifd0.R5Ucvl5qCYoJ3CbkBJ.3l
bZKpeEtQrfwAe14CrEkf2yHe1Ab0cDdsRgxc5npRAOySHEtcElAI8IwIn.8o
S5KaPJDoyG7fw9AC0.17uBUTj0tuhBGOHXuJlSpbRO1aNXxVe2xklnnuVCOw
5QTAraLdQz48CQKY1mBpbHN4NZ2yGzOJlK8EgzQZ3F66g3t1HTKCKmvkgNso
XFTRcNqaA6b+.SoU218znce+XK0DIKadAK6VRtsM4vj87RKs0mFLcN4ZbSgX
13p1Cmu6HoGcxQy9l3LmSyYkJiX.TqFt60o1RoIlZ6L56nDWMxCKIcRXYCSJ
2SfnoNEyUQh1BmntIELVwvo5etBx0h1oqnkkqghBV0lmjSmuXKOaJSN4xss1
5Ypm0TZlclTYPLqFe2PzVH2peqTwvk+AbIcIVPDTSH.41Oo4brWTmwYEEC7W
yL2MxL4RRbF4dZtXg9EYSFj2NspiD4zGkyoyI0hgiIvyqGNxSRPkC0j1ljNS
PVVUH8hg2vf+iUXmQZKpNX70DW0RW8YaqKm4ZMwHRZatBxNphrw1mZo5leAT
y908rShGGmL5nltP6qxLoqRi4KqRcTp3sXl4WlnWPwQQpxmYRflsZyxqqP9h
BzRUmTbQaXrWFXaQ8UTiyV4DsEM0tgsKzUCU+BTiOrRZMqgm0g+c+ee.rppf
zUDzxdguO0GfstmEz7bhstn5rEToGlD0QKo+bMG0uoxoj4bZgNpCh5TxbBOs
LmfSKyAdZYNnCn4XjgVqiPkkrVmfq0E3S6.byc+sdmex27WO6+DqsipA
-----------end_max5_patcher-----------
</code></pre>

PS: If we are to split j.modular into different externals in the near future, shouldn’t we make some abstractions so patches are not broken after release ?
I remembered we talked about this hence I asked again about it. However, while thinking at it this morning, I wonder whether it is a good design idea or not. But truth is I dont remember at all the reasoning behind the idea of splitting j.modular… So please, a short summary would be helpful if I’m missing something obvious. Anyway, I paste below a little workflow-based brainstorm sketch I did this morning, based on what seems confusing to me as j.modular is at the moment. That is:

- j.modular do two very different things based on the number of arguments. This is hard workflow-wise imho. However, rather than splitting things, maybe we should rather re-work the object and put a focus at the right place and clarify how it inserts itself in the workflow. 

- Currently, it is not clear to me where is that focus. Is it an application-oriented approach ? Is it a protocol-oriented approach ? Of course both are related, but I feel we have room to clarify the focus. Hence my attempt at a « generic » j.network.

- I am not fond of having to create an object in my patch to declare it on the network. Then, do the same on a second patch on a distant application, then add an object in my first patch to declare the remote to my second patch, then add an object in my second patch to declare a remote to my first patch, etc… This surely is explicit but a bit fastidious. + I’m not sure it is good to have to hard-code this in a patch (well, I could actually be sure it is not ;-)

Anyway, here a patch I did while brainstorming. Obviously, object and message names are mainly to get an idea. And not all features are here. Again, just brainstorming.

Best,
Julien
------------------------------------------------------------------------------
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel