Julien Bayle

In order to centralize almost all in my JAVA core, I'm tempted by splitting it in 2 parts.

I'd have to share data between them ( something related to classloader I found here & there on the forums ) which wouldn't be basic.. I guess.

But intuitively, I guess one of the two part would be more specialized in OSC communication with my external audio engine and the other in calculations.

it it would be over the probable problems I could have with the fact I'd need to share data between the two 2 MXJ, I'd go there :)

In order to centralize almost all in my JAVA core, I'm tempted by splitting it in 2 parts.
I'd have to share data between them ( something related to classloader I found here & there on the forums ) which wouldn't be basic.. I guess.
But intuitively, I guess one of the two part would be more specialized in OSC communication with my external audio engine and the other in calculations.

2-mxj-instead-of-one-sharing-datas-what-would-be-the-benefit

I had the same problem too when making my midi looper application (Zyklus Improvisor). Classes are your friend, in the end I found it was easier to use one core object. I do use some other mxj objects but they have a very specific task. When everything is done inside one mxj object all your data is easy accessible and thus avoiding the problem when it's divided over two or more mxj objects.

I use Eclipse over here and it's rocking. (But sometimes I wish there was a mix between Max and for example Delphi when it comes to IDE).

I had the same problem too when making my midi looper application (Zyklus Improvisor). Classes are your friend, in the end I found it was easier to use one core object. I do use some other mxj objects but they have a very specific task. When everything is done inside one mxj object all your data is easy accessible and thus avoiding the problem when it's divided over two or more mxj objects. 

I use Eclipse over here and it's rocking. (But sometimes I wish there was a mix between Max and for example Delphi when it comes to IDE).


did you get anywhere with this J? I'm really interested in sharing data across mxjs

if I'd go to 2 or more, I'd basically use data structures in each one, and I'd wire them in order to create a kind of data propagation system.

it would take more memory but it would be ok.

another thing I'd do: if I had multiple mxj, it would be only to share the load and have some specific tasks in each one, then, maybe, I wouldn't need to propagate all datas, but maybe, only to trigger things

hi there,
I didn't.
I finally use only one core.

if I'd go to 2 or more, I'd basically use data structures in each one, and I'd wire them in order to create a kind of data propagation system.
it would take more memory but it would be ok.

btw, and indeed, 1 core is really easier


One option is to use static class variables and share the data across multiple instances of the mxj object, then leverage the power of poly~, for example. If you use poly~ @parallel 1 and some clever message logic between poly~ instances this enables you to do certain things in parallel and other's in serial, if necessary.

2 MXJ instead of one, sharing datas ... what would be the benefit?