Monome Pure Data how to select a 12 x 8 grid or any size

[fauveboy]

Hi
Ive been using the select object to allocate a button in my patch. Rather than writing a new select object for each button you want to use is there a more efficient way this can be done?
Im trying to have my patch say “okay select a 12 x 8 grid and number the each ‘cell’ from 0 upwards”. I was trying to make it easier also that if I want to loose a row or column i can just say select 12 x 7 ect.
I was interested to here if anyone has allocated specific grid space using there monome and PD or Max and if they 're happy to share their method I would be grateful for that.

[dylanw]

hi somebody most definitely will be more helpful than myself ( i don’t own a monome so the specifics of your problem are a little hazy to me).

But maybe you need a nested loop. Select col/row and then iterate over all cells within that col/row. Move onto the next col/row until n (12). Counter, uzi, pack and zl spring to mind as potentially helpful.

[jwudel]

If I’m hearing you right, what I’ve done to get something similar with my launchpad is make an abstraction with all the possible controls, then filter input and output with creation arguments that define the size.

For example, I made an abstraction called “fader” that could make a low-resolution fader on all 8 columns of the launchpad, like a super-simple version of Beams. If I create it as “fader 0 8,” then it will use all 8 columns, but if I create it as “fader 6 2,” it’ll create two faders in the right-most two columns.

Happy to share patches, if you think it might help!

[fauveboy]

Ah thats cool. I would be keen to see your patch if you’re happy to share it please.
Im trying to designate a certain block of buttons and in this case use them as a keyboard. Atm I can get values from the monome and either view them from 0 - 255 or i can view them as ie column 2, row 5. Im hoping I can take the solution you’ve used for the fader and use the buttons selected to send midi note messages to an oscillator ?
Ive taken a look at uzi which sends a certain number of bangs and with counter seems to be a nice way to increment the bangs.
Ive taken a screen shot what do you think of this approach? I can only seem to count a row or column one at a time. This you can see in the first two /grid/led/set messages from the left. But on the right ive tried /grid/led/set $0 $1 1 but its doesn’t seem to like counting a simultaneous second argument?

[jwudel]

Woof. Sorry to take a minute to get back to you.

Zip file attached with 6 pd abstractions.

• lpin and lpout take the launchpad midi info and turn it into a monomeish list of x y z values, or receive said xyz values and turn them into lights on the controller.
• lpfade is the fader abstraction I mentioned. lpfade 0 8 gets you 8 faders, lpfade 0 4 gets you faders on the right half. Has 9 outputs (because 9 columns on the launchpad). If fewer rows are defined, no thing should come out of the undefined outlets.
• lpxy is a simple xy pad, that can be defined at just about any size/location. So, lp 0 0 4 4 should give you a 4*4 xy pad at the top left of the grid. Always has 2 outputs, x and y position
• lpstep is a simple step sequencer. lpstep 0 3 gets you a playhead row and 3 rows of triggers. Has 8 outputs, one for the playhead position and 7 for possible rows of triggers, which come out as bangs.
• notemap4ths tunes the grid in 4ths, like a super-simple earthsea or a linnstrument.

Hope these are helpful!
LPPD.zip (7.3 KB)

[fauveboy]

Look who’s taking a minute now, wow, sorry about that. This was over the christmas holidays and then I had to drop the monome for a bit… So im not sure how you re applying the values after the abstraction title is written… ie is I write “lpxy 12 8”… like so It doesnt seem to change the functions going on internally?

[tehn]

ok, so you just want a single “big” pad which is assembled from a group of pads?

i’d suggest thinking logically, as in, logic operations

for example, if you want a region from 2,2 to 6,9 to be a single group pad, just check the x and y position

if x >= 2 and x <= 6 and y >= 2 and y <= 9 then yes, it’s in range

go checkout the pd objects for logical comparisons-- greater than, less than, and

[jwudel]

$1, $2, etc are variables. So when you create lpxy 0 5 4 4, $1 = 0, $2 = 5, etc. The internals of the patch won’t look different, but it should behave differently. lpxy also takes four creation arguments, the first is the x position of the top-left corner of the pad (assuming 0, 0 is the top left corner of the grid), the second is the y position of the top-left corner, the third is the x dimension, the fourth is the y dimension (it’s complicated enough that I don’t use it myself all that often). So, for the case you’re hoping for, I think you’d want 0 0 12 8.

Moses is a pd shortcut for the greater than/less than functions, outputting values < the creation argument on the left and > the creation argument on the right (not sure off the top of my head which side values equal to the creation argument come out)

Also, you’ll need to swap lpin and lpout for something monome-specific. Those abstractions I use to talk to my launchpad mini, but they output (or accept) x, y, z messages that are (I believe) very close to the osc message the monome produces.

Hope this is helpful!

[fauveboy]

I’m not sure where to apply the logic in this patch? I’ve been studying the grid studies today and for example here’s the PD toggle LED patch. Using route to cancels out rows 6 and 7. If say a value for the row is sent then if its larger than or equal to two the /monome/grid/led message has to set manually of every button coming though right? Also I’ve tried just getting column values by switching the states around and this doesn’t work the same as the columns LEDS…the button pressed will light up another region?

[fauveboy]

apologies jwudel I don’t fully understand your patch

[jwudel]

Nothing to be sorry for!

To back things out, I’d encourage you to try breaking the problem into smaller pieces. As I understand your end goal, your patch/abstraction needs to do several smaller things that would add up to something like a 128 bank of faders, or a 128 x/y pad. One (still pretty high level) way you might break it out is like this:

1. Filter keypresses so the patch only responds to keys in the designated area.
2. Respond to keypresses (or bangs, or other things within the patch) to output some kind of information that will be used elsewhere in a larger patch.
3. Output information to the monome for visual feedback.
4. Bundle up your abstraction so that later, you can use it in a patch as a 128, or a 126 or an 8*4 version of the same thing. (probably don’t worry about this until you’ve got a solid grasp on steps 1-3).

In step 1, you could use route, or moses, or logic operators, or some combination of these to filter out incoming keypresses. My approach was to use route to filter out key releases (messages with a state of 0), then split out x and y into individual messages and use a series of moses-es to make sure that only keypresses in the area I wanted affected the part of the patch that used those presses to send out control information.

I hope this is helpful!