#1

dear folks,
as i’ve happily been playing around with my monome for the past months, i’m at a point where i’d like to learn better practices for updating and managing grid states / leds.

i’ve been using matrixctrl in max and i’m not really satisfied with it (as it sends out lots of values and is additionally incapable of only outputting changes).

are there any third party externals or other general hints and tips as for optimising and managing changes to the grid? i’ve been going through various forums, how ever have the feeling that there’s something i’m missing :expressionless:

thanks!

#2

just a thought : [zl change] ?

#3

thanks @chapelierfou … yes, basically this would work – i would how ever need 256 [zl changes] in order to monitor each cell of my matrixctrl /:

#4

the next step is a large-ish leap. i’d suggest using javascript.

using /map messages is by far the most efficient.

check out the .js included in http://monome.org/docs/grid-studies/max

1 Like
#5

thanks @tehn … that’s what i was afraid of (:

#6

I guess a good middle ground is moving away from GUI objects, so using zl stuff, or perhaps using the BEAP serialosc modules which use jitter matrices to store stuff (though that might be overkill/heavy since each one has a qmetro banging away every 10ms?).

I’m actually in a similar boat concern wise as I’m starting to rebuild the party van, and want to do it “better” this time, as some parts of that patch, especially with regards to LED feedback are… a little clunky to say the least.

#7

I love JavaScript (have written a lot of it for companies like Yahoo, Google, etc) so I’m happy to help folks get a grip on it if need be. That being said, I’m completely new to JavaScript in Max, so now I know what I need to study tonight.

#8

Using js in Max isn’t so bad. I’ve gotten out of the practice of it, but for a bit I was using little bits of js to deal with loops and stuff like that that were difficult to do in Max natively.

There’s some I/O bits you need to add, and other than that each function is just a message you send into the object, so pretty straight forward beyond that.

I’ve not done much with arrays or long strings, so I would lean towards zl-based solutions (but js seems attractive for this).

I’m guessing that’s not been the case when using /map type messages, but a few years ago I switched to a js-based replacement to OSC-route and holy shit did that kick my computers ass. I was sending a lot of messages through it, but I had massive LED lag, audio dropouts, and my computer fan went into overdrive. So since then I’ve been wary of using js for timing sensitive stuff.

1 Like
#9

Has anyone started diving into using gen~ (and by extension, C++) for grid messages? Is it even possible/feasible?

1 Like
#10

great guys. thanks @Rodrigo for the input and @jasonw22 for the kind offer. it’s good to know that i’m not wandering completely blind, as i honestly had no clue when i started with the monome (: hehe … it’s a little soothing to know, that even the party van avoids a “best practice” up till know.

… and holy shit did that kick my computers ass

that is indeed a concern i’ve been having, too. it seems like a balancing act (even with vanilla max object) to find a decent way in favor of the monome and a patch’s performance. obviously it’d be possible to build a rather complex management-system with colls and list to arrive at clean /map -messages in the end, how ever i’m a little scared of that.

#11

Has anyone started diving into using gen~ (and by extension, C++) for grid messages? Is it even possible/feasible?

i’d be very interested, too!

1 Like
#12

I’m surprised and disappointed to hear that js has poor performance in Max. Seems like a very good reason to look at gen~. I’m generally allergic to C++ but perhaps it’s time I got over that.

#13

js has improved massively in max 7. don’t fear it!

i remember when js was introduced in version 4 and it was terrible. but no more.

1 Like
#14

@reallyok Probably not a good idea to do grid stuff in gen~ as gen is “expensive” computationally (everything calculates every sample).

In my (shitty performance) case, every single OSC message in or out was going through the js, and that took a shit on performance.

It’s good to hear that it’s improved in Max7, though I still think it runs in the low priority thread (and can’t be bumped up).

I figured since all the native apps went to js that performance was much better than I had experienced.

#15

but no more.

grr… briefly thought i had an excuse. thanks tehn (: