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.
----------begin_max5_patcher----------
1417.3oc0Zs0qahCD94jeEHj1m1zyhM2R121eGUUQFvmD2BFDXN8zV0+6qu.
Df.ASxQApZU3vLf8LeyEaOL+Z6Fyfz2wElF+qwmM1r4Wa2rQRRPXS08aLSPu
GFiJjOlIE+8zfuZtSwhgemIImY.bKpoVv9QLVRtlRZIKFyX+HCqlKSSiuTwh
VlPnblxgGTQLCwBOSnmNliCYpWAXe3Eqc7owQbwwR7KD9hUy.QhjSIW59jKz
7xnql6qGdbdkZVomaLekDieCmWPRosd5MlnrrVj2z5UDfyWSkCj+tFRDphjU
Cob7aj52G1PEkyURFWCKyUv0668LuLLoQ3bZIQJJJh+dasHcAWbUvhks3hmi
7N28NW.FtE8TbZ32vQskIyzLLkPyxwEXJCwpDtF1Q3WQkwriulRYEjeJkO.G
tGh+qnP7nuLEknTt+KmfhqUOyS4jnTpPH5.0Bx0SG2l6pL4sUF4SPQYC7xbS
OGVFgYAWIKKBP4BKQfx+r1TXxRSi6xp48hwuxpXmQnzdnHKMabl4jSmuw6Fj
xYlbqwVxo3XIUw8HOJjcr.8VWzlghiqBK6N7uinjDDCyHJS.zpgIlh3J54hv
7z33N5qhyaCvIh6DGh+NIhcVNQscF3ONIq1IxrwJGQNgKXcowPmJ5R4p7EbR
kAUAoGY3jrXtVz8A5j3pcDY6DXcneqDYcSl8WbWt1LtV9FLmFgxZRqccpMXK
FCjdyUkPSFhYnR00N6V+LbNlcmm1I4pY76saq+ice7fDyHvH3NPo.D8j4tpq
iCWfaCW.qCu3ty3fbw.amofK33vE74.Wex.rLtT.KkmkDutoK0gE2m5uWJPB
5XqIHsewAoeFav2NwcfShnt6Gnph3rgt5kgxd+hGykgB+lgkg08fUOJNAO.j
6DyaRbxeEjJmXPty.ucSE+AzJIET5OYOMZ4s3dUhE9hefE9terB5rWhR9RXx
1ZRvxcwAKdxpD146Js9iktBBUmSDHQI2I2gfsyZ.qJh46v1.3sTvEzGpNF4j
vk8hCWwonHUL08EJ9n68TcvauoiBgqh8pSdfTVOTFdX0dEpNZyj3E7vyw0JA
WTfNgGDvrLt8+.ty5+smiXBEGlVRkSj8ybmIUw3hBowceAdRyhnfQiZI.qhM
6lxVrzgpiE33NkOKX42r6+r.EsvyW5P4I2pqMXJTx643NIE+O187aoylXU0j
1t42wfAWqafCs3DlljfoUUO6CDeTS2z.zrRxqVMzwEpIFbiTKVy.CtTWXQd0
QJHnTdE7GFbJRKyCqcBpJtlQWIOBWvHzlpj+4KECn2CdlDEgo80hHRgnnppx
6pkkbthr3bQ5IyqFQlusHCfFRrXUHsD4DRTVJOeVQ8GLRsbGTcnRaa4pdh65
NoOEEUGSinR.qE2IckY35wcBnoHCVOQshs59GoLCzUlAqBYd.3ajPP60SHnu
tx7JZUHswY26LmNnpNg9xZr5JuHu6ImSWtdqNQAdqFiiy9O50g5YbbUE91Ws
rqxRIu6IaabzMqp85w3LP.wHxry5RlA5JyqiUBFHA+pGm8lSbKX9ws9dx3VK
fbCxUewJwcO43Vc0yA10z70Sw2RwcYzSw4+06rZGVOw5NZFq6B9fjYiurscK
uYJZ6onipV75HhwxIAkL0I9a2CeypUjNEmFfhqZznlFU6V8kzklWZ6E4U9qB
k0oEJ6V34KUvSUsX33kct9M5TBY2GtoKg2noKsjewQvAYcPUk4x2a3ltzwZj
lt7NfH9HDfymS+j1uihlcekB7unhi0Wo0ezK93jy8VX37ip1kqky8PU+sR6k
CY2BUo.i9QiUPx0QgsisFK.ryQxuN365.uqrM5JN8lpQRhY0NywLjGEZ0q2a
EhRudtsW+1dcu1Nde11uGa4y7u29+9ay4JB
-----------end_max5_patcher-----------
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: https://github.com/monome/monome_sum
@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?
thanks!
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.