…But i miss some [localsend] and [localreceive] max objects, that would only send&receive inside a small patcher hierarchy, but not the other patchers/modules… So that i could load many identical module without they interfere with each other… You can look at the patch in attachment which illustrate my little problem (and see the way i want to connect max UI with some java-sound-modules) : Please launch together “sound_module_patcher” and “sound_module_patcher_copy”…

…Is there a simple way to do that and keep the data local (each patcher with its data) using some PATTR object instead of send&receive ?

I imagine that there is, but it doesn’t look simple to me as abstractions are involved. (Plus i want to be able to had new UI/abstractions on the fly while the patch is running)

Thanks,

edit:

ah you attached a file, didnt see that.

ok, so one way would be this:

[loadbang]
[set #0_from_java_parameter]
[send] [receive]

of course, initialising the names of the sends and receives
from the same source somehow makes the use of send and
receive more complicated than using a connection.

so what you are asking for is an external?
 

Maybe the pattrforward object will also help

-A

[pattrforward] in my abstractions seems to be the way to go, after trying around for two hours with this, i can get to ‘send’ my parameter from the UI object : Now the data is sent only in the local “sound_module_patcher” even if DIFFERENT INSTANCES of it are loaded in max. ok.
… but i cannot ‘receive’ the parameter to the UI… Look at my patch attached bellow in this message:

Is there some way i could get my [pattrforward My_controls::param::from_java_parameter] to work with every [param x] abstractions ?? (Actually it seems to be bind to only [param 5])
Or to manage it in an other way ??

-> For the ‘send from the UI’ part, the “parent::parent::” stuff works perfectly but then here i would need some kind of “sub::sub::” stuff, but this doesn’t seem to be implemented in pattr…

Thanks,

@Gregory : These three dashes sound nice but it doesn’t appears to work in max.. (i don’t use M4L)

@Roman : I’ve thought about this kind of solution, but then I wouldn’t, as i wrote, “be able to had new UI parameters/abstractions on the fly while the patch is running”, which is important to me.

@C74 : A new “2 or 3 patcher-levels of tolerance” option, to bind pattr stuff together without the need of putting the name of the subpatch with “::”, would be welcome. Then, also, we wouldn’t need to worry when we want to encapsulate or de-encapsulate…

@C74 : mxj pattr compatibility would be even more welcome…

I really like the “abstraction” pragmatism : Also, i wanted to say that in my project i will put a second argument for the ‘param’ abstraction to display the name of the parameter… which i’ll use in java, for example :

if i need some ‘sound_blur’ and ‘lfo_factor’ parameters in my java code, i’d have a [param 1 sound_blur] and a [param 2 lfo_factor] in ‘my_control’ patch, and in java i’ll then just need to put : new final int sound_blur = 1 ; new final int lfo_factor = 2, and with some automated method to load and save parameters from their number in an array, then i just use : param[sound_blur] and param[lfo_factor] as my parameter in my java code… This is the most elegant solution that i’ve found for the moment…

…But i do want to find a nice solution to this pattr/send&receive problem… ?
If there is no simple solution to this, using standard objects, then i think something could be improved by C74 in this direction to open more the way of “modularity” in general. Patchcords are nice, but not always.

Now I have a working solution, it looks like it's working for the moment.
(Through It was not that simple, i had to find a trick for the data to be really 'sent' to the other side of the module**, with a global bang sent, and a 'not_this_patch' test, plus the i didn't find the pv.maxhelp really clear about 'public' & 'private', so i had strange bugs at the beginning. And also to init pv with an argument: it only works if the init argument is in the pv which is in the main patch.)

@johnpitcain : Thanks, your objects are looking quite interesting, but i have to tell that using so much externals in the basic structure of my project doesn't really convince me. I want standard objects for that. (Through i do need few externals like the great resonators~ )

So here bellow is the last version of this modular-patch-with-mxj-paramaters, i found a nice way to display my controls, using an abstraction called “_” for floats parameters, and “l” for list parameters like multisliders.

Thanks everyone,

** It would have been more simple if pv would react like pvar (seeding the value), or if real “psend” and “preceive” objects would exist…

P.S : I will share here a template of my basic mxj structure (coming with real time data automation and others stuff) when it'll be realized.

[attachment=154095,1820]