Need LOCAL send&receive – Can i use pattr to do that ?
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)
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.)
ah you attached a file, didnt see that.
ok, so one way would be this:
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?
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])
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…
@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…
pattr is one possibility:
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 1695.3oc0ZsraiaCEcsyWAgPWlQP7gdkUse.EnKJ5lYFXPaQ6vo5ggDSlLc5 7uW9PVVxQ1VZLMahAhbzkhzWd38buGR6ue2BuUUuvZ7.O.9HXwhue2hEZSJC KZuegWA8k04zF8i4sIup7oBu6MMsopTzv+GlpIHxOn0r7I3k4LgtKvCFqdRr 2Jp05NpX8i7xsKqYqEFGIj.kiDHLReMPcEIuB9baWLih3a6XlmW4STg28.uU zxsdcOGOS6wUq9xGvA883RZgtqd+VMml6oZ3G2cm5x8SDEJYeUNr6Gymo0cC 4NZMsHbeKB1KhVyBQMvzH3WWwKyDUfe+aKWKcm5p7lGd3OFzwbdIac0Skh9X 0OOZiuHZCI5qX8MXx4faERq+aTjFdFjtskZVinptc39PfODFlRPciVC8YV1R 4fI8wkJbiu5IgIJcQ25wBCRyDr5krR5pb8vEnaSuXdcKoGV3pY6XkYfvqOjG dwEgDr5ZT3kC4GG6Q1MJ2AbcRPhs45nXmx0ImiqSNCWm3dtdKZaKtNJYlbcb fe3aaZN4lRyaw+qjliRe2QyQwgVmlSbJMGeNZN9Lzbr6o4sns0n4gyjlCeay ww2TNdK3esb7n2cbbHAYcNNzobbz433nyvwQtmi2h1ViiilKGOt2m0aRZN5l Ryaw+qkliukA3cPRszaXxzxH.FPrwVYhNCvnwEThNM.LXB4A5BLu+RAoAu6R JlZ6ThP2t6F34RIBOSJQn6SIlZyDhv4J5AieqmPDdSSHlZgzgPKqoecUQASF 4cLh.92OU9W.4KeeeYz6WnOSuQgqAmIQoQjNNV8VJ9Uwq8wEr6wkM0UE+uhL n.zDPF36OcxlBjXaVTvxG7WAqogtk8p3CB3WlURDzrUUYvlntr2RBRxrSiD6 F1xe9HCjQET.uATV8Uv1J4jATUl+M.uDHjslWsllC9jWij1jsrnJ6ob1R8zl U+IO.6YVIfuATPKUcoQPKWyZ.zZUOoYrL03HcEvCixAw2RNHIxHfqkKhzqEj jwYgINQE695XMLws8T5hzojgl2hI+jEyhbpPMsJBQ0x9Yr6PtlcLVVNu.DGL JxQ7woxYcnU3vFYXFlrYW.H7rAuPWkPScjzigIHnOJEACIyGSVsccUdUsY5E 3GghIgPIjnfB4sAwIDr91tI9IBBw33fzXUJPCllh7ihPIIIRHMc1PJwIjzhW 9hV0vx947FMnKzOAShigiAvAyVxftNJLF5CSCHxHYInoAbT33orPthc1aqQu NiFXjVGDEF6GIwHDxJfDAaRlGZTdZDqiOQN8I7831VI63c0rgmKqrU2vqJ6Q KTaWZuiDkRNjcHLHpSt2dGQQhjEO+aVVuozBuL1lYMHUx5EG5Pfg.16xvmjW JqvzHqzSEstd+OX5S4hkiWuYX6anqYmryiBjK71VyypJUNwfdpLu+iqaCCg8 8a8STR2MRmEUU4qn0Oya3sasrakPFKSK4ETASvM9CJnqe7hc0biBiNalsm9X yZYfZ9fgxzxyizRF6Y9Z1W4YhG0i0AzZvO5jdQNCXYCreb5bIbxax4Yxfu6O 7L8ocC94TbRQA5FTDPkNtisOph9SysLYff6UKnNJh9gXm9HHF7HC2ayd6liC Xw9LR+LXlnZ61tLwiCW3IAWiVz6jeaHHiVJL5.tftHrnC+NApjZSPYv18FGT H8a8D7+YfWWHLBiLxtQmX2gyYGhmRk94J64NbE4TbsEPgFVpcwUxaJbE5130 fdG2pcgU37g0C0EUaTtsDC3ysmn57Na1KVJ+UMNEwAmn9+kzWbNoC4Uqn4sR w5dFuWeJxZvoOvrWYqtuJ6C02JEvWud+RV6wp.NHULi0H3kcRk93guhldOzi 7rrAxR7J3Y6pj42Gr37Jw1S0kzebjK3SpeRhywmjJJwAxWxMogMZthgXehzB hLpIsNzPYzen9+swbBeIbNYdyoXIoLU9JoaBPBh8iUVF2j47dfwVbNgtzbJb dyoPrepZcB0MAPwXeoR1.33lLmjSBwhyI3klSn4MmvxU.0bB1MATpHiTlhF0 j4LRCg1YNo9BXtHGOzsTbr8coV7BFD2dBy6u4Z80H66qswq12WSsuu1luv59 JFYeesMes880fI3qXjS4PGUA7D9jiKcOI4Dot0mRlhOE6VeZJojOJwyM2mBm hOQbqOMkX7iJlbq8I3TvIXr6kLeQeZtEoz0SwlS+RmPs++SNjg0BxtlRs.Dz sqySIWFzs7A3TvI2F5ME1faSjME8ZWyxl7leb2+QISJxI -----------end_max5_patcher-----------
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.
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.
Forums > MaxMSP