Prototyping – Third Iteration

The third version of my visualizer addresses the previously mentioned issue, that the top and bottom lines were overlapping into the wrong sides of the screen.

import ddf.minim.*;

Minim minim;
AudioPlayer player;

int col1 = 100;
int col2 = 100;
int x ;
int y ;

void setup()
{
  frameRate(30);
  size(1280, 620, P3D);
  background(0) ;
  smooth ();
  float x = 6;
  minim = new Minim(this);
  player = minim.loadFile("time.mp3");
  player.loop();
}

void draw()
{
  translate(0, 310);
  
  for (int i = 0; i < player.bufferSize () - 1; i++) {
    
   if (col1 < 255) {
     col1 = 100+int(((1+(player.right.get(i+1)))/2)*155) ;
    } else {
    col1 = 0;
  }
  
   if (col2 < 255) {
     col2 = 100+int(((1+(player.left.get(i+1)))/2)*155) ;
    } else {
      col2 = 0;
  }
  
  int y1 = int(((1+(player.left.get(i+1)))/2)*305);
  int y2 = int(((1+(player.right.get(i+1)))/2)*305);
    
    if (i == 0) {
      
      strokeWeight(5);
      
      //top line
      stroke(col1,0,0);
      line(x,0,x,0-y1);
      
      //bottom line
      stroke(0,0,col2);
      line(x,0,x,y2);
      
      //seperator
      strokeWeight(2);
      stroke(0);
      line(0,0,1280,0);
    
    }
  }
  
  //Fade lines into background
  fill(0,15);
  noStroke();
  rect(0,-310,width,height);
  
  if (x < width) {
    x = x + 6;
  } else {
    x = 6;
  }
  
}

void mousePressed (){
  background (0);
}

The changes in this iteration keep the left and right audio values to their own side of the screen. As the lines were previously drawn using the same colors, I changed the top lines to be predominantly red and the bottom to be blue. The shade and brightness were still determined by the opposite side’s value, however keeping the two sides’ colors separate made it clearer when testing to see if the overlapping issue solved – additionally, I felt it had a nicer contrasting aesthetic with vivid red and dark blue.

When working on this iteration I realized that the values returned by player.left.get and player.right.get were on a scale of -1 to 1. The value returned was not technically the amplitude, but instead a value of the actual audio wave, whereas a silent input would be 0. The amplitude, technically, is the difference between the peak and trough of the audio wave. To fix this, I tweaked the way col1, col2, y1 and y2 are calculated (see lines 29-42). In this version, adding 1 to each calculation of player.left/right.get resulted on the scale being from 0 to 2 instead of -1 to 1, and then I simply divided the values by 2 so values went from 0 to 1.

third iteration
A new aesthetic shows the top and bottom lines keep to their own sides.

This iteration has resulted in a much more refined, functional audio visualizer with a more aesthetically appealing design in my opinion. The top and bottom sides of the screen now draw their own amplitude waves over time, without crossing over. However, as I calculated the player.left/right.get values from 0 to 1 now, it appears the base value for a quiet audio wave is 0.5, not 0, as negative values are now from 0 to 0.5. Converting these values into a true representation of amplitude is something to address in the next iteration.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s