Project Logs

Collapse

• end of the tour

  mpinner • 10/03/2015 at 03:45 • 0 comments

  after rebuilding the development environment to get the dev/test gems working again. seriously, kids, keep backups of all your arduino libraries and versions for important projects. it took me the better part of a day to reinstall and track down the right library dependencies.

  things seem to be doing ok with only minimal maintenance. i had to replace a teensy because it forgot the programming. nicely enough there was plenty of time as we had at least one extra of everything.

  Thanks, #Hacker Channel ;) !

  
  

• Shaders

  mpinner • 06/26/2015 at 22:23 • 0 comments

  Q : how do you control 1000s of leds with minimal delay?

  
  

  A : no delay.

  from the beginning i knew this was going to be the central issues. to ease development i choose to parse all the osc messages on the microcontroller.

  this is a fairly novel approach. osc doesn't specifically rely on having a network, but everyone uses it over udp. my teensy looks like an osc device sorta. i have to parse all the osc traffic on my teeny. this has to be the highest priority task and cannot be delayed. these usb / serial buffers will overrun quickly and i need the hits to be perfectly sync'd (<5ms) .

  doing all this osc parsing in c is kind of maddening, but afforded me only having to manage the message formats in one place. (DRY: don't repeat yourself)

  ---

  ok, SHADERS

  
  

  their use wasn't strictly required. i have GPU. I probably wasn't even implemented correctly. I use the term "Shader" in this case to explain the design pattern and division of responsibility. i knew i'd need to add patterns fairly quickly and have lots of data driven configurability.

  basically you can get a ton of different behavior by implementing this virtual method:

    virtual uint32_t shade (float height, uint32_t color, uint32_t currentColor, float remaining, uint32_t secondaryColor);

  that is all. here is one of the more complex ones.

  inline uint32_t shade (float height, uint32_t color, uint32_t currentColor, float remaining, uint32_t secondaryColor) {
  
      if(remaining > 0.85) {
        if(2 > random(100)) {
          return color;
        }
      } 
  
      if(remaining > 0.7) {
        if(2 > random(100)) {
          return secondaryColor;
        }
      } 
  
       if(5 > random(100)) {
        return colorByBrightness(0.9, currentColor);
      }
  
      return currentColor;
    }  
  };

  right. not all that complex. check em all out here : https://github.com/mpinner/PurityRingGems/tree/master/Arduino/Gems_HitSync

  the trick is in how you think about the context and task.

  each led is essentially complete responsible for only itself and i know how to write simple code to control one led.

  i provide myself a rich context for each led to live within. things like timing, colors, and position are all normalized from 0.0 - 1.0. this makes writing code extremely predictable, easy, and inefficient.

  ---

  I am doing so much floating point math. it is almost irresponsible and completely insane for what could be ALL integers

  
  

  ALMOST INSANE:

  the only things that makes it ok:

  - having plenty of spare cycles on my Teensy's Freescale

  - being able to accept a new OSC Message ANYTIME , even between calculations for neighboring pixels

  - Measuring my effective frame rate to ensure it always looked GOOOOOOD . initially i was pushing 200fps. once i started adding more and more and more features and cross gem patterns, my frame rate dipped to just over 60fps.. sweet!

  one might argue it looks even better this way because you are constantly calculating the most accurate colors. im not sure that's quite true, but you'll have to see it live.

  a fun side effect was being able to bring in and compare previous pixel values to have feedback like effects. i didn't play with this nearly as much as i should have, but it is very apparent when you start using the touchosc interface to simulate hits very very fast.

  well, i hope this helps

  please review the code and comment as needed. learn what you can. no elitism please. i did this all under no sleep and serious duress.

• octows2811

  mpinner • 02/27/2015 at 19:17 • 0 comments

  midi and osc and octows2811... oh my.

  there are sooooo many ways to get from a midi device to a teensy running octows2811, im boggled.

  also, my target system runs ableton and windows;( so that doesn't make midi handling all that less complex

  thus far my stack is

  midi -> ableton -> live grabber -> processing -> oscuinoSerial -> teensy serial

  i might simplify this by compiling teensy as a midi device, but im really in love with the scripting language i've built upon OSC and the debug info i can get back...

  more on this to follow..

• next step... output

  mpinner • 02/24/2015 at 08:22 • 0 comments

  the next step is evolving... the output!

View all 4 project logs