Lighting a row: integer -> 16-item line with max of 15?

hi everyone. monome user for nearly two years now. and it’s my first post!

question on making lists for lighting rows. can anyone point me towards how i might make a process in max that converts an integer into a list that’s 16 items long, with each item being a maximum of 15, and all items’ sum total is the original integer? e.g. inputting the number 17 would create the list “15 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0”, and inputting the number 159 would result in the list “15 15 15 15 15 15 15 15 15 15 9 0 0 0 0 0”, etc.

perhaps someone else has done something similar? thanks!

ps as an introduction for what it’s worth, i don’t have any cool monome patches to show, but for any max for live heads out there, i’ve been making some useful devices that you’re welcome to download… and i make weirdo synth music

Hopefully that all works (haven’t posted an encapsulated patch here yet). I’ve done a few things using zl objects like the following, I’m not sure it’s the most elegant but it gets the job done.


tambouri, you’ve made my day, thank you!

@tambouri that’s an interesting, novel approach!

I’ve done a fair amount of research into ‘anti-aliased’ displays on the grid (and arc) and always ended up using javascript as it always seemed a much more appropriate approach to these problems. That being said, the above max patch is surprisingly simple, if a little opaque.

If you’re curious to see some examples of using JS to implement various different anti-aliased grid displays, have a look at the monome_sum github in the /tools/blinky folder:

@Galapagoose haha, thanks! I remembered being much more scared of javascript about a year ago when i worked something like this out, though my now limited javascript is probably similarly rough and idiosyncratic.

I was curious, I’ve heard you and/or Tehn mention anti-aliasing displays (and I say this w/o having dug into your .js files), but what about the display is anti-aliased in this case? My familiarity w/ the term is through photoshop pathing/selections/jpg creation where vectors edges are softened to avoid jaggies, but I was wondering if you could explain more abstractly (and less in JS terms) how this is applied to the 16 step resolution of the grid displays?


I was certainly still scared of JS when I made those scripts linked above so I’m sure there’s lots of room to improve them.

Regarding the anti-aliasing you mention, this is entirely the same as what you already know from photoshop / vector edge display. Basically interpolating across multiple discrete points, with variable intensity, to create the impression of a value in-between two discrete states. If you look at monome_sum the ‘beams’ patch is a bank of anti-aliased bars to help visualize the values sliding around in a continuous state.

In general these types of interfaces are uncommon because they’re generally not suited to the highly discrete nature of the grid (why build a fader with only 8 levels, when you could just use a real fader), but it’s a nice workaround for situations where you want some kind of mixed functionality between the precision of separate grid keys, but need to show some kind of smoothly varying display.


As an interesting aside - the first foray into this kind of display was @tehn’s ‘returns’ which uses an anti-aliased pointer on the arc. This obviously makes much more sense as the 64 leds are showing a continuous value spread out around the arc ring. My versions for the grid were mostly a personal challenge to help learn a bit more about javascript and interfacing with the variable brightness capability of the grids of recent years.

Thanks for spelling that out, I’m fairly certain it makes way more sense now.