Im working with a patch which needs to be displayed on 16 by 16 grid hardware, called monome. Inside the file is an abstaction called gridsamplerPtest $0. There is an unpack f f f object which receives grid coordinates from the monome. These values then need to be sent around the patch....inside the sub patch load.sample there are the sub patch monome.abs inside there receives values from the grid. however where i;ve left the comment "assign to grid" I need to specify the the coordinate values i want i want to use as the condition. how do i do this after trying to make unque instances of the first sub patch $0 ? will the gird values have to be put in manual..this would be counter intuitive to the design? and I do require multiple instances of gridsamplerPtest? grid250717 2.zip

@Fauveboy If you want a send/receive object to have a unique address contained within an abstraction and any of it's sub-patches.... use $0..... it will not communicate with any outside address.
If you want to be able to send a message to only one abstraction and it's sub-patches..... use $1, $2 etc. inside the abstraction and sub-patch..... and it's real value 1, 2, 3 etc. outside.
If you want to send a message everywhere do not use $ at all.

In "monomer.abs" you have not used $1 as a fixed value, because you have given it the value of $0 from it's parent...... so..... you cannot communicate with it except from that parent, because only it's parent knows it's value. Do not pass down $0 if information needs to be sent from elsewhere (in this case from "grid_2")?.
David.

okay so when im receiving values from the grid hard wear i've got the unpack f f f and im using $0...if i pack the values together i would get a grid coordinate combo eg 0 3 1. this would be the x cordinate, y coordniate and the 1 means whether its on or off. how do i specify the the values on the grid i want to do a particular job inside monome abs? In the equal to condition would i have to write this by hand...what would this mean if i want multiple instances of gridSamplerPTest would i have to write new x, y values for the equal too objects....could i somehow make something that says this these buttons are assigned to this row ect ....could it check if the row is already occupied with annother instance of gridsamplerpTest

@whale-av I understand the $0 or $1 can be used to send values but it doesnt seem as straight forward to obtain input and have the programme know how to check those values , if this makes sense ?

@Fauveboy This example is very basic but you can adapt the concept to your patch. You can pass down arguments from the parent to abstractions. There's also a mechanism to keep track of the arguments already used, haven't tested it thoroughly but that's the idea I think, I suppose you could have two different tables for x and y coordinates.

nested.arguments.zip

@Fauveboy
The [expr $i1 + $i2 + $i3] in [monome.abs] is asking if the value from [r 1004-y] =1007.... (as the $0 values are assigned when I start the patch and open the first).
In fact, in each and every [monome.abs] you are trying to match a different completely random number ($0)........

That is the only strange thing I have spotted. The other $'s look correct at first sight.
I will let you know if I see anything else.
David.

@weightless Im not entirely sure what this is working out. if i consider monome.abs however....
I need to allocate a row rather than a single coordinate.

For example in load sample subpatch with the hardware I need to control smpLen. but that means i have to maually state the row "x" value in the monome.abs and if thats the case if I want another copy of all this that x value manually typed in is already in use? is this what nested.arguments checks?

@whale-av the expr object is meant to check the co ordinates values coming in from the equal to objects. but thats not what the $ signs are receiving?

@Fauveboy Yes, the expression object is checking....... for all true=3
"asks is x = $2" (= the value of $0 in the parent handed down.... in my pic above..... so = 1004)
"asks is y = $0" (= 1007 in the pic above, and 1006, 1008, etc. in the other [monome.abs] ..... completely unknown in advance and therefore........I think..... wrong)
"asks is z = 1" (probably reasonable?)

So unless y = 1007 in [monome.abs $0 8 phasePosSel]........ expr will never output 3.
And unless y = 1006 (or 1008 or whatever $0 is in each abstraction of[monome.abs]...... expr will never output 3....... and the message will never be sent.
etc.

[r $1-x] ...... (y and z) do receive values from [GridSamplerPtest]...... so if nothing is arriving then nothing is being sent. Have yo used "MagicGlass" or print objects to check that all messages are correct in the osc and elsewhere?
David.

@Fauveboy As far as I see it, if you don't want to type the row number by hand in the monome abstraction, then you have to specify it somewhere else and I think the approach that makes more sense is to specify it either as an argument in the parent and pass it down, or send it to the parent via inlet and pass it down. There's also the problem @whale-av explained in the expr. My suggestion is to work out what values you need to pass down, decide which argument you're going to type them in in the parent ($1, $2, $3 etc) and adapt your design so that they are passed down to the nested abstractions.

To check whether an argument has already been used is a bit tricky, my patch was just an idea and it doesn't fully work because all the abstractions are created at the same time. Maybe one way to do it would be to introduce delays in each abstraction (based on an abstraction id?).

@weightless That's clever and interesting..... a bedtime chew required.
I would rely on the incoming data. Checking for consistency of a data set of 3 components seems pointless when [route] can be used to send the required (filtered) data to the correct abstraction.
Each data set is arriving as a list...... so cohesive, stuck together... whatever....... no opportunity for error.

So check x....... if else for which [route] can be used
Then check y........ same
Then check z........ same
If the message has passed then send to wherever determined by (presumably) the values of x, or y, or z, or a combination of all 3.
Each abstraction receives only messages intended for it's operation.

A [monomer.abs] wants to know " am I on or off" so it's arguments should be x and y (it's unique coordinates..... the button that controls it).....and whatever else is necessary, and the data it wants is z. I think. If another button also controls it's operation then those coordinates can be added to it's arguments....
So each abstraction receives only the button data it expects.

@whale-av I think that what he is trying to do is: have a sampler to be controlled with the buttons of row X... if he then creates another sampler controlled by the same row X then to avoid conflict, the new patch won't be created (maybe the patch is complicated enough so there is the possibility to lose track of what's controlling what) . @Fauveboy, is this correct?

@weightless There are other errors that make the patch non-operational such as.....

It would need to send info from a whole row of buttons to achieve the objective.
Selecting for x and sending y, (on/off....z.... sorry, s in this case) onwards.

The whole probably needs going through with a fine tooth comb.... But is impossible to design without a "button map".....
With a button map a ground up redesign for the osc (incoming data routing) would be advisable I think.
David.

@whale-av i already wrote a button map concept for @fauveboy with which he could flexibly assign buttons to individual moduls: https://forum.pdpatchrepo.info/topic/10749/binary-counter/13

Even wrote a trainer for the monome, with which he could easily create the button map: https://forum.pdpatchrepo.info/topic/10749/binary-counter/16

But this was not wanted for some reason...

@Fauveboy Some of it fixed.. I think... row 8, 9, 10 should work...... grid3.zip

@whale-av i m just away from the monome at the moment to test it properly... the 2nd argument we give monomer.abs can this be a variable that can be sent the argument or is this design suited to type in these constant values ?

@Fauveboy Throw grid3 away..... there was a mistake anyway.
Yes, anything can be done in Pd.......... grid4.zip
Row changed by message (monomer retains function, only row changed).
You could use the buttons of a row to change functions throughout.... by sending such messages...
David.

the problem is if i do two instances of gridSamplerPTest $0 when I change monome $0 7 whatever...its changes it in both instances of gridSamplerPTest I thought $0 would help separate the two?

@Fauveboy

grid5.zip
$0 gone.... except for local sampler messages. No more mind mangling.

Gridsamplers numbered (0-15).
Row one buttons control which gridsampler is being actively controlled (and is sending back to the leds).
All gridsamplers continue to play.... correct? or should stop?

Probably no sound, as I have not touched your [pd fader] volume control.
There will be small mistakes maybe?, probably?.
David.

thanks sorry it took a bit long to take a study of the patch....the limitation is that monomer.abs is set up to display only one grid sampler...i changed it to this so now the display is comes down from the top of the 16 x 16 grid but....is there away to set up monomer.abs so i can do this without changing it globally...i would then set the leds to toggle then it will be possible to view muliple samples on the grid

This is working in the correct way but it stops me from controlling multiple samples. compared to previous designs..if I need to launch two samples simultaneously it cant happen?