search

skotchvail / Love-Potion-Camp

Code related to the Burning Man camp called "Love Potion"
8 stars 3 forks source link

Better Beat Detection with Equilizer Sketch #14

Open skotchvail opened 11 years ago

skotchvail commented 11 years ago

Last year beat detection looked iffy. It seemed to work okay on some music and not great on others. It never felt very crisp. It is not clear if our beat detection code is flawed, or if it was the color changing code, or the various scaled inputs that controlled the detection, or the animations themselves.

Focus on the beat detection and get the code working well for various kinds of music. Create an Equalizer Sketch that does not use the color changing code or the scaled inputs to isolate the problems and prove that the beat detection is now crisp and solid.

bfuller01 commented 11 years ago

Skotch,

I'm working on this, sign me up...

rdosser commented 11 years ago

I've been getting to know the code, and have a question: is there anything I need to do to get it to detect any audio sources on my laptop? Or is there a way to fake an audio source? The AudioBuffer object being passed to BeatDetect.update() is a series of extremely low numbers that I'm assuming are line noise or the digital equivalent.

skotchvail commented 11 years ago

Yes, I get emails for anything that I authored. My laptop seems to use the microphone as its audiosource. So whatever music I am playing or whatever I have playing in the room is what it picks up. I have no idea if they are low numbers for me or not, but if true that would make beat detection less sensitive. Are they supposed to be between 0.0 and 1.0?

rdosser commented 11 years ago

I don't know what the useable range is, but I think anything that ends in "E-6" or smaller is probably off the raster. I'm getting really small numbers.

68f3e903231fdd843d8b92acf011921d

rdosser commented 11 years ago

I tried using my microphone jack - I plugged my earbuds into it and talked into them, but got the same general results. I don't think I tried talking directly to the laptop mic, I'll try that.

skotchvail commented 11 years ago

Yeah, I think this shows how little any of understand about that code. I am pretty sure that my laptop is using its builtin mike for this. I recall clapping at one point and seeing the Sketches react to that. And on the playa, the laptop was just picking up the music playing in the environment.

bfuller01 commented 11 years ago

I looked into this code a month ago in some detail. Ralph, lets discuss this.

skotchvail commented 11 years ago

I put in the "equalizer" on the screen, it is not sketch, it is just always there. I looks like we have two problems: 1) our beat detection sucks 2) when the sound is very low, we try to do beat detection and just get a bunch of noise. We should reject beats when there is not much sound.

rdosser commented 11 years ago

Bill and I have a date tonight for him to bring me up to speed on the beat detection code, which will be a lot faster than me trying to suss it out myself.

skotchvail commented 11 years ago

We should also consider using this library instead, it might be better: http://code.compartmental.net/minim/javadoc/ddf/minim/analysis/BeatDetect.html

It is the same library used by this animation, which seemed to be better when we looked at it last year.

http://www.openprocessing.org/sketch/1820

rdosser commented 11 years ago

I was looking at that last night!

Personally, I think we should make sure we can't make the current code work first - we've got some time sunk into it and have pretty decent understanding as a result. Unless this other library is dead simple to plug in, I'd hate to start from scratch.

bfuller01 commented 11 years ago

I played with this abunch. a lot of little apps out there using it. This one is no better out of the box using isKick, isSnare, and isHat. isRange has possibilities.

bfuller01 commented 11 years ago

oh yeah!!! http://motscousus.com/stuff/2008-02_Processing.org_patterns/test_beat.pde

This WORKS!

bfuller01 commented 11 years ago

I would also like to suggest control by a human. a control surface with the ability to select programs on the fly and have control of program variables including beat detect variables. Set them up next to the DJ... A visual DJ so to speak...

rdosser commented 11 years ago

It truly does work, right out of the box. Looks really great too, not just sharp graphics but its beat detection seems to be pretty spot-on. So ignore everything I said before - and get used to doing that, BTW - and how about if I look at adapting that code for our BeatDetector?

skotchvail commented 11 years ago

Yes please integrate it. Anything has to be better than what we have now. I'll check out the Sketch today.

rdosser commented 11 years ago

It's really rough: more of a proof-of-concept than a finished class. It has lots of commented out code, and one really heinous god-method. I spent last night making things worse and worse just trying to get it to play with our stuff. But I'm still hopeful I can pull the logic out of it and fit it into ours.

skotchvail commented 11 years ago

If you are having any problems updating all of our sketches, don't worry about. If all you do is get the equalizer on the screen working with the new code, then I can covert the rest of the code over.

Also, this "sharp looking graphics" is already in our "Equilizer3D" sketch, but once you shrink things down to our tiny resolution things get less awesome looking.

rdosser commented 11 years ago

I've got the test_beat logic integrated into our stuff. It's definitely better than it was, but the integrated behavior isn't matching the behavior of the original - it's missing beats that the original catches. I am continuing to try to isolate this.

In the meantime, I'm working in a local branch right now. Do we want to plan on me making a pull request when my stuff is ready for review?

skotchvail commented 11 years ago

Just merge into your branch, push up your branch, and then do the pull request or just email me.

On Jun 15, 2013, at 5:27 PM, Ralph Dosser notifications@github.com wrote:

I've got the test_beat logic integrated into our stuff. It's definitely better than it was, but the integrated behavior isn't matching the behavior of the original - it's missing beats that the original catches. I am continuing to try to isolate this.

In the meantime, I'm working in a local branch right now. Do we want to plan on me making a pull request when my stuff is ready for review?

— Reply to this email directly or view it on GitHub.

rdosser commented 11 years ago

Will do.

rdosser commented 11 years ago

I've just pushed a new branch called rdosser03_beatdetect. I think it does a pretty good job, but we may need to tweak some of the settings. Please review and comment.

Thanks, R

rdosser commented 11 years ago

I've been thinking about it, and I think I can restore the low/medium/high band values pretty easily. They're currently all populated with the same data,

skotchvail commented 11 years ago

Ralph, it looks good.

I have merged your code in, so you can delete all of your branches now. I did the merge a little bit weird, so double check, but I think it worked out okay in the end.

The beat detection is not perfect, but it sure is a whole lot better than what we had before. If you are able to split that up into 3 different beats, that would be a nice to have.

I see that you have a bunch of delays during launch? Why is that? 

System.out.println("0.1");
delay(5);

and so on.....

Can you remove them?

rdosser commented 11 years ago

So my to-do:

  1. Review merge
  2. Split into three bands
  3. Remove dumb-ass debugging stuff

Will do