Alexandre

With the new vizzie set, i was telling myself that it's good that with the time, more people - at C74, or anywhere - start to think of any work as a set of MODULES connected together, more than just heavy patches and codes, that we always restart from the beginning. My personal project is in fact evolving in this direction. Max already have already a good "object-oriented" part in itself, as many evolved language like C,java,etc - Patchers are a bit like objects in fact...

...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)

Hi,
With the new vizzie set, i was telling myself that it's good that with the time, more people - at C74, or anywhere - start to think of any work as a set of MODULES connected together, more than just heavy patches and codes, that we always restart from the beginning. My personal project is in fact evolving in this direction. Max already have already a good "object-oriented"  part in itself, as many evolved language like C,java,etc - Patchers are a bit like objects in fact... 

...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"...

need-local-sendreceive-can-i-use-pattr-to-do-that

You should take a look at the 'send receive hoard 0#' and 'send receive hoard 1#' example. You can find it in the Examples Overview, accessible from the Extras menu.

Thanks but this doesn't really help here in my situation/example...

then explain what _would help. (if not using local sends for having local sends.)

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?

[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.

preceding source and destination names with three dashes (e.g., s ---there) handles localization within separate M4L devices. That's not what you need?

In this particular case, it looks like you could just use patch cords.

Maybe the pattrforward object will also help

The problem with patchcords is that when i have dozens and dozens of parameters in a view then it's big big mess to edit...

[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])

-> 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...

@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...

[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 ?? 

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


Thanks for your patch, ok it is a working solution but... again, it's a really boring solution if you have 56 parameters in the same patch, and if you often want to had some parameters quickly on the fly..

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.

Hi Stefan,
Thanks for your patch, ok it is a working solution but... again, it's a really boring solution if you have 56 parameters in the same patch, and if you often want to had some parameters quickly on the fly.. 

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.


I haven't studied this thread thoroughly, so may be off the mark, but Is there a reason why you can't use pv?

You might find it worthwhile to take a look at the oo objects.

I love max but sometimes with all theses objects you're a bit lost.. pv was not in the "see also" section of the helpfiles of the pattr objects.. I did look at pv.maxhelp many years ago but i forgot about it..

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.

** 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.

pv!
I love max but sometimes with all theses objects you're a bit lost.. pv was not in the "see also" section of the helpfiles of the pattr objects.. I did look at pv.maxhelp many years ago but i forgot about it..

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.)

Need LOCAL send&receive - Can i use pattr to do that ?