Mudo wrote:rozling wrote:Great that you built in SPI - is this a derivation of Sparkfun's board then? Sorry about the questions - maybe this can be the start of a FAQ?!
It is not a evolution from sparkfun one sorry. At wiki is full documented the process.
More or less: Monome project > Arduinome project > Unsped Octinct project > Hangar Octinct revision.
Sparkfun spi boards (almost usb version) doesn't have diodes (they are developed for tetris) and you couldn't press two buttons of the same row at same time.
Different necessities, different board design.
So you have got around the multiple buttonpresses per column limitation? Nice. This was a concern with the SF board alright. My one does have room for diodes btw - they recommend 1N4148, although it hasn't done me much good so far...
Mudo wrote:...
rozling wrote:
Hang on, you have velocity control with the membrane buttonpads? Or are you just using velocity as the colour 'channel'?
We are wondering the possibilty of manage colour in midi mode with velocity bit for output in octinct.
...
So if I understand correctly you use the Key data to identify the button and the velocity data to send the RGB value, and presumably this would update the board faster than if you update the whole board every time a single button changes colour?
The Sparkfun board e.g. requires [255, 0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0][255, 0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0][255, 0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0][255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255] to light button 1 & read all button press states.
And presumably this requires a bit of processing ability on the board's side to interpret this data (Key + Velocity bytes received), hence the slightly bigger board.
Actually I was surprised when you mentioned MIDI protocol - aren't you making more work for yourselves implementing both MIDI & OSC? Surely OSC alone would be easier? Not complaining though
