I've been checking out the new photos of the 100h from the makerfaire.
Does the lights on the 100h support different levels of intensity?

If you check this photo - http://flickr.com/photos/amitp/505429747/ -
some lights seems to be darker than the rest, but they are lit. Am i
wrong here?

hey, no need to take this is as godspell, but im almost certain the 
lights are only on/off.

the visual effect of appearing this way is most likely because the 100h 
was running a program like _life for example, and lights are rapidly 
turning on and off. merely an artifact of the cameras exposure catching 
the light just turning on/off..

...i think..

trent

for a very long time i was inclined to make the 16x16 capable of 
multiple levels of brightness. i have several prototype circuits which 
could do this.

however, in the end, we decided to again make it mono-color on/off. and 
everything became clear, elegant, and intuitive again.

the main problem with multiple brightness, like multi-color, is having a 
method of control that really makes sense. the osc protocol would've 
become broken and convoluted. it's much nicer, clear, and intuitive to 
work on a bit level.

also i didn't like that we were considering breaking out of binary for 
one system (the leds) while maintaining it for another (the key press). 
if somebody wanted to make a multi-point velocity sensitive grid of pads 
with rgb leds, i see how that could be useful and fun.

by maintaining the same osc protocols, all of the applications will work 
across any unit, including multi-logicboard custom boxes which should be 
abundant soon. since part of the hardware's viability is based on the 
continual renewal and adaptation of patches/apps by the community, it's 
in all of our best interest to keep things compatible.

I think yall should make a thread to see how many people would buy a 
100h, if it had green lights


Cuz I would love to have a 100h with green or orange lights

i'd love my 40h with white leds. although, i'm too lazy to mod it.

i personally agree with what brian says.  so far, the ONLY limitation my 
patches have faced with the 40h is the amount of buttons - while 
multicolor or individual intensity of the led's would probably allow 
more advanced patches, i think it would become a bit convoluted anyways. 
also, the 100h has 4x the buttons, which already will be alot more work 
to handle on the application programming side (max/reaktor/pd/etc).  i 
cant imagine feeling limited programming 100h-based patches with that 
many buttons.

OTOH, i can see the differant led options being very useful in projects 
where the display elements are just as important as the functionality 
elements, like for live gigs that show off the box (like the way 
daedalus has his angled in a way that the crowd can see it better, even 
though its somewhat being pointed AWAY from him!).

just my POV...

kid-sputkin: i don't think anyone is disagreeing with w/ brian nor 
monome camp. no one wants convulotedness but having options isn't bad 
either. if 100h is a similar feature set of the 40h and the expanded 
software, well great...sign me up.

folks wanting different light states, multi-color, and even the much 
loathed around here velocity sensitivity is just other people wanting to 
see a feature set that is ideal for how they work. personally none of 
the above is necessary for what i do but i'm all for having options, but 
if it means a lot more money then i'll take me 100h vanilla.

i like options...thats how i ended up wanting the 40h + max/msp over a 
year back.

seriously, right now i am SO glad that i don't have to deal with sending 
RGB colors to the leds for the patches i am writing... programs are hard 
enough to write with just on/off!

While I think that compatibility as much as possible is a good thing, I 
would support having a way to have the light brightness be varied for at 
least 4 8 or 16 states per light. This shouldn't be terribly complex 
within the delay loop you're already using.

It doesn't have to change the standard protocol, there should be some 
extensions for people who can make use of it. I could suggest several 
ways to efficiently get the data into the monome.

I love doing things with the monome, but in particular this would 
significnatly increase the options for different UI setups with it and 
if kept separate, wouldn't actually intefere with compatibility.

In other senses, the binary nature of the pushbuttons isn't a 
showstopped. I can think of several appliactions where how long you hold 
a button down translates directly into a velocity-like signal from the 
perspective of controlling the intensity.

Please consider giving us these extra capabilities, it would be really 
really cool :)

B>

individual intensity would be pretty nice, imo, and alot easier to work 
with than multicolor leds.  this i would be pretty cool with.

honestly, multicolor led's WOULD be cool, as i said it would just take 
alot more work to use.

what i usually do now for multibutton use is to make some buttons 
blink/flash, so you can then get at least 3 states: on, off and blinking 
(also, if you do differant tempo-synced blinking patterns for differant 
buttons, the effect could actually be very useful).

one thing that would be cool would be choice of led color when ordering, 
but i understand that this would be near-impossible, due to the sheer 
tinyness of Monome (im guessing that they try to get as many units 
assembled in advanced as possible, the fact that alot were made to order 
was more because of the limited manpower vs number of orders received).

I was poking around looking at the base max/msp patches and one of them 
lets you set the LED intensity to a value - I forget which one but 
apparently it can be done in a patch.

that is for ALL LEDs though, not each one individually.