Sync several pixelblazes does not carry calculated variables?

Hello hello !

I’m currently working on synchronizing 2 pixelblazes. Let’s call them PB1 (Leader) and PB2 (Follower).

The leader (PB1) has buttons and reads GPIO to adjust hue and luminosity.
Unfortunately the variables I use to “offset” the calculated hue and luminosity do not carry forward to the follower, so if i modify manually the color with the buttons on the leader, the follower does not move.

Am i missing something ? I’d really like to be able to adjust all followers with the physical button on one PB.

Thank you !

Example is the “Fireflies” pattern i adapted with a color picker: look at “hue” and “hBT”

/*  ______________BUTTON MANAGEMENT________________*/
// Buttons connected to GPIO input pins
var buttonOneValue, buttonTwoValue


//Initialize button adjust

export function getButtonsStatus(){
  buttonOneValue = digitalRead(BUTTON_ONE_PIN)
  buttonTwoValue = digitalRead(BUTTON_TWO_PIN)

export function processButtons(index) {
    if (index == 0) {
      if (buttonOneValue == 1) {
          hBT=hBT+0.0005      //Loop hue
          if (hBT>1){hBT=0}
    if (index == 1) {
        if (buttonTwoValue == 1) {
            vBT=vBT+0.001     //Loop luminosity
            if (vBT>1){vBT=0.01}
/*  _______________________________________________*/
  This is a fork of the sparks pattern where each spark is:
    - Slowed down 
    - Given a longer lifetime 
    - Allowed to loop from one end to the other
  This is a highly upvoted pattern generously contributed to the community
  pattern library by an unknown person. Please reach out if you'd like an
  attribution link here!

// Add a color picker control to make it easy to change the color
// Set up variables to store the chosen color
var hue = 0, saturation = 0, value = 1
export function hsvPickerColor(_h, _s, _v) {
  sparkHue = _h
  sparkSaturation = _s
  value = _v
  hBT=0 //Reset manual hue offset to make sure the color selected is accurate

sparkHue = hue       // Set the hue for each spark
sparkSaturation = 1  // Set the saturation for each spark (0 = white)
numSparks = 1 + floor(pixelCount / 10)  // Scale number of sparks based on # LEDs
decay = .99          // Decay their energy/speed. Use .999 for slower
maxSpeed = .4        // The maximum initial speed of any spark / firefly
newThreshhold = .01  // Recycle any spark under this energy

sparks = array(numSparks)
sparkX = array(numSparks)
pixels = array(pixelCount)

export function beforeRender(delta) {
  delta *= .1
  for (i = 0; i < pixelCount; i++) pixels[i] *= .9 // Air cooling
  for (i = 0; i < numSparks; i++) {
    // Recycle dead sparks
    if (abs(sparks[i]) <= newThreshhold) {
      sparks[i] = (maxSpeed / 2) - random(maxSpeed)
      sparkX[i] = random(pixelCount)
    sparks[i] *= decay  // Spark energy decay
    sparkX[i] += sparks[i] * delta  // Advance each position ∝ its energy
    // Allow sparks to loop around each end
    if (sparkX[i] >= pixelCount) sparkX[i] = 0
    if (sparkX[i] < 0) sparkX[i] = pixelCount - 1
    // Heat up the pixel at this spark's X position
    pixels[floor(sparkX[i])] += sparks[i]
  hue=sparkHue+hBT  //Color is the picker selection + manual button offset

/* ---------------------------------------------------- RENDERING ------------------------------------------------------------ */
export function render(index) { render3D(index, 1, index / pixelCount, 1) }   //If pattern is 1D, it will use the y of the mapping as index, and z=1 by default
export function render2D(index, x, y) { render3D(index, x, y, 1) }            //If pattern is 2D, it will use z=1 by default
export function render3D(index, x, y, z) {
  if(z==0){rgb(0,0,0);return}   //Disables all the LED at coordinates z=0
  processButtons(index) //Does the cooking depending of buttons state
  v = pixels[index]
  hsv(hue, sparkSaturation, (v * v * 10)%1*vBT)

Currently only input from UI widgets (sliders etc) and external Sensor Board are replicated from the leader to the followers. So I don’t think there’s a way for PB board GPIO on the leader to reach the followers.

I’m pretty sure this will evolve next year, since so much more is possible if we have control over which data is sent, and especially if we can send it in all directions!


Thank you, i will do without it for the moment !
It would be amazing to be able to select in a mesh for example who is “master” or “slave” for sensors, GPIO…

Can’t wait !

It’s definitely going in that direction, since on the followers you can opt to use local SB or the master SB. I have specific plans so I’m waiting eagerly for this to be peer-to-peer.

1 Like

Amazing job once again !

These a quickly the gap to use Pixelblaze on professional solutions !
Is there a page somewhere where we can see some list of the current ideas in development, or planned to be developed at some point ?