Beat Experimental
 

Note: THIS IS NOT A FULL PRESET - IT'S JUST A DEMO

After reading alot of the recent posts, I was intrigued by Rozzor's comment that the holy grail of beat detection was a variable which is both stable and responsive. This made alot of sense to me, so I set out to make one :D

Now, the preset itself is nothing fancy - it's just a strobe on top of a blank preset. But I'm pretty happy with the beat detection I've managed to get into it.

As is usual with beat detection solutions, it works better with simple music, and falls apart if you throw something like Tool at it.
On the upside, the algorithm can stand up under short drum fills, and generally ignores vocals. It will occasionally skip a beat, but usually manages to keep on track. Where things fall apart is very "busy" music (think Linkin Park), or very quiet or flat patches of music (introductions to many songs). I've tested it under a variety of conditions, and it works best for slower, less complex beats:

hard rock, simple hip-hop, and old-skool techno (prodigy and the like) seem to work best, though I've had some success with rock ballads, metal, and electronica.

I don't have the enthusiasm to turn it into a full-blown preset right now, but if you have need of some beat detection, and aren't satisfied with what's currently available, have a go at working with this.

Your mileage may vary.

Beat Experimental
[preset00]
fRating=3.000000
fGammaAdj=2.000000
fDecay=0.900000
fVideoEchoZoom=1.000000
fVideoEchoAlpha=0.000000
nVideoEchoOrientation=0
nWaveMode=0
bAdditiveWaves=0
bWaveDots=0
bModWaveAlphaByVolume=0
bMaximizeWaveColor=0
bTexWrap=0
bDarkenCenter=0
bRedBlueStereo=0
bBrighten=0
bDarken=0
bSolarize=0
bInvert=0
fWaveAlpha=1.000000
fWaveScale=1.000000
fWaveSmoothing=0.750000
fWaveParam=0.000000
fModWaveAlphaStart=0.750000
fModWaveAlphaEnd=0.950000
fWarpAnimSpeed=1.000000
fWarpScale=1.000000
fZoomExponent=1.000000
fShader=0.000000
zoom=1.000000
rot=0.000000
cx=0.500000
cy=0.500000
dx=0.000000
dy=0.000000
warp=1.000000
sx=1.000000
sy=1.000000
wave_r=0.500000
wave_g=0.500000
wave_b=0.500000
wave_x=0.500000
wave_y=0.500000
ob_size=0.000000
ob_r=0.000000
ob_g=0.000000
ob_b=0.000000
ob_a=0.000000
ib_size=0.500000
ib_r=0.400000
ib_g=0.400000
ib_b=0.400000
ib_a=0.000000
nMotionVectorsX=12.000000
nMotionVectorsY=9.000000
mv_l=0.900000
mv_r=1.000000
mv_g=1.000000
mv_b=1.000000
mv_a=0.000000
per_frame_1=warp=0;
per_frame_2=dx=-0.0005;
per_frame_3=dy=-0.0005;
per_frame_4=volume = 0.3*(bass+mid+att);
per_frame_5=beatrate = if(equal(beatrate,0),1,if(below(volume,0.01),1,beatrate));
per_frame_6=lastbeat = if(equal(lastbeat,0),time,lastbeat);
per_frame_7=meanbass_att = 0.1*(meanbass_att*9 + bass_att);
per_frame_8=beat = if(above(volume,0.8),if(below(peakbass_att - bass_att, 0.05*peakbass_att),if(above(time - lastbeat,0.1+0.5*(beatrate-0.1)),1,0),0),0);
per_frame_9=beatrate = max(if(beat,if(below(time-lastbeat,2*beatrate),0.5*(beatrate + time - lastbeat),beatrate),beatrate),0.1);
per_frame_10=peakbass_att = if(equal(beat,0),if(above(time - lastbeat,2*beatrate),peakbass_att*0.95,peakbass_att*0.995),bass_att);
per_frame_11=lastbeat = if(beat,time,lastbeat);
per_frame_12=peakbass_att = max(if(beat,bass_att,peakbass_att),1.1*meanbass_att);
per_frame_13=ib_a = beat;
per_frame_14=monitor = beatrate;

EDIT - Removed per_frame_8, as it wasn't making a difference to the detection - old code. The lines have been renumbered now, obviously.
Knock yourselves out.

- Krash

A slight variation - the beatrate is calculated slightly differently.
The bad part is that it takes longer to pick up the beat, the good part is that it's less likely to lose it. Small mistakes become a bit more obvious though.
This version is a bit better if you want to be doing something with the beatrate variable, as it's more stable.

Beat Experimental - Slow Response
[preset00]
fRating=3.000000
fGammaAdj=2.000000
fDecay=0.900000
fVideoEchoZoom=1.000000
fVideoEchoAlpha=0.000000
nVideoEchoOrientation=0
nWaveMode=0
bAdditiveWaves=0
bWaveDots=0
bModWaveAlphaByVolume=0
bMaximizeWaveColor=0
bTexWrap=0
bDarkenCenter=0
bRedBlueStereo=0
bBrighten=0
bDarken=0
bSolarize=0
bInvert=0
fWaveAlpha=1.000000
fWaveScale=1.000000
fWaveSmoothing=0.750000
fWaveParam=0.000000
fModWaveAlphaStart=0.750000
fModWaveAlphaEnd=0.950000
fWarpAnimSpeed=1.000000
fWarpScale=1.000000
fZoomExponent=1.000000
fShader=0.000000
zoom=1.000000
rot=0.000000
cx=0.500000
cy=0.500000
dx=0.000000
dy=0.000000
warp=1.000000
sx=1.000000
sy=1.000000
wave_r=0.500000
wave_g=0.500000
wave_b=0.500000
wave_x=0.500000
wave_y=0.500000
ob_size=0.000000
ob_r=0.000000
ob_g=0.000000
ob_b=0.000000
ob_a=0.000000
ib_size=0.500000
ib_r=0.400000
ib_g=0.400000
ib_b=0.400000
ib_a=0.000000
nMotionVectorsX=12.000000
nMotionVectorsY=9.000000
mv_l=0.900000
mv_r=1.000000
mv_g=1.000000
mv_b=1.000000
mv_a=0.000000
per_frame_1=warp=0;
per_frame_2=dx=-0.0005;
per_frame_3=dy=-0.0005;
per_frame_4=volume = 0.3*(bass+mid+att);
per_frame_5=beatrate = if(equal(beatrate,0),1,if(below(volume,0.01),1,beatrate));
per_frame_6=lastbeat = if(equal(lastbeat,0),time,lastbeat);
per_frame_7=meanbass_att = 0.1*(meanbass_att*9 + bass_att);
per_frame_8=peakbass_att = if(above(bass_att,peakbass_att),bass_att,peakbass_att);
per_frame_9=beat = if(above(volume,0.8),if(below(peakbass_att - bass_att, 0.05*peakbass_att),if(above(time - lastbeat,0.1+0.5*(beatrate-0.1)),1,0),0),0);
per_frame_10=beatrate = max(if(beat,if(below(time-lastbeat,2*beatrate),0.1*(beatrate*9 + time - lastbeat),beatrate),beatrate),0.1);
per_frame_11=peakbass_att = if(equal(beat,0),if(above(time - lastbeat,2*beatrate),peakbass_att*0.95,peakbass_att*0.995),bass_att);
per_frame_12=lastbeat = if(beat,time,lastbeat);
per_frame_13=peakbass_att = max(if(beat,bass_att,peakbass_att),1.1*meanbass_att);
per_frame_14=ib_a = beat;
per_frame_15=monitor = beatrate;


- Krash

Sorry I have not replied before. I saved you file as a default .txt and forgot about it.:)

That is pretty good Krash. It is getting there with max att stuff. I am feelinga little left out this beat detect stuff so I have done an update. Well not detecting the beat update just counting the beat and then moving the circle waveform to this. I will keep playing. I have some ideas.......

A new one now it zooms in and out on the alternate beats. We are going to make some good presets with this code.:)

(goes for the foot in the mouth)

This is good Krash, and (as always) I can't find fault with the code itself. The thing that bugs me is, it's all stock...it could have come out of a textbook. As far as I can see, this is the same old "classic" beat detection that we started with.

What you've got here is stationary, but it's not ergodic. To get both at once real-time, the variable we're tying to pin down can't just range over a set interval, the interval itself has to change with the complexity of the music.

Just $.02 from the crackpot ;) I just got a few ideas, and I'll try to come up with some code tonight to show you what I mean...one or two more lines should do it.

Heh, if you say so. I did make it all up from scratch though - just worked through things that made sense to me. Maybe this is the sort of stuff that's in a textbook because it's the best available :p
It's not quite the same as the simple beat detection that is in "shift" et al. In shift, the beat threshold starts at 2, and falls, until the bass_att gets over the threshold. The difference here, is that I'm resetting the threshold to the level of the bass_att value which hit the threshold. Additionally, the threshold drops in two stages, slow normally, and quickly if it has been a while since the last detected beat (2 x the current estimated beat rate). Lastly, a beat will never be detected due to "ambient" sounds, as the threshold is always kept above the average bass_att level.

Oh, but it does. The beatrate is calculated as the average time between the last ten detected beats (it's not the true average, but its close). In addition, a beat is not detected when the time since the last beat is less than 50% of the current beatrate (ie, we don't detect lots of bass peaks close together). Also, the beatrate forces the detection of the beat if it has been more than twice the beatrate since the last detected beat. The beatrate isn't altered in this case. (This way, the algorithm doesn't lose the beat during quiet patches in the song... theoretically).
The only limitation I've placed on the beatrate is that it can't drop below 0.1 - as below this value, beats were being detected very quickly, and the algorithm couldn't escape the loop.

I'd like to see what you can come up with. Personally, I've always found your code to be too reactive. It seems to jump around at points where I can't hear a beat. I'm sure it's quite good with fast rhythms, but it's never been great for the music I listen to. Hence my coding this. I'm still pretty pleased with it.

- Krash

Here is my contribution for the evening. I thought you all would like to have a uniform and pleasing-to-the-eye way to look at the beat detection presets. Don't be offended by my doing a little messing with the code to get similar output for everyone.

I use the rozzorrate variable as a way to see how reactive a beat detection scheme is. In my opinion it should stay steady with a steady beat, increase and then level off if the beat goes from 4/4 to doubletime, climb steadily if the level of sound gets too low to detect well, etc.

More later....

nifty.

What would be cool, is if we could somehow have this effect displaying the beat detection of two methods at once. Ideally, we would combine any given beat detection with the "shift" style detection, so we could evaluate whether all that fancy code is doing anything noticeable.

- Krash

Here you go, Krash
 

Just replace foo in the attached preset with your variable of choice.

You could also assign something different to mv_y, but I can't count the number of times that seeing something sane like what Rovastar assigned to mv_y has kept me from going a long way down a wrong path.

This is tool that could -- and maybe should -- be improved by a lot of people. Note that I haven't added my name to the credit list. In my newbie opinion, Rovastar's name should stay on it because, well, because it's Rovastar, and EvilJim had the intial concept, one that makes me proud of newbies everywhere. Let Rovastar decide what form he wants to post on his web site; his name is on it and he can have every bit of code I put in it, gratus.

Of course, I might be the only one who ever uses it. But really, it can't be "beat" for something to stare at for the long periods of time it takes me to hack beat detection.

P.S. Newbie question: by "shift" style detection, you mean bass_thresh line in the shift preset, right?

yeah, bass_thresh.

I've been thinking - the things that are important to beat detection:

1. Consistency - the beats must be detected at the same intervals all the time - once a bar, twice a bar, four times a bar, etc.

2. Reproducability - the beat must be detected in a repeatable fashion

3. Stability - the algorithm should find the beatrate and stick to it

4. Accuracy - the detected beats should ALWAYS fall on actual beats in the music.

5. Precision - the detected beats should be very well defined - a "beat" is only a fraction of a second long - the detection should reflect that.

We can detect 1, 2, 3, and 5 with a computer. Four, we have to watch for ourselves.

Just some random thoughts.

- Krash

Rozzor,

I am confused. Your preset.

code:
 per_frame_1=warp=0;

per_frame_2=dx=dx-0.0005;

per_frame_3=dy=dy-0.0005;

per_frame_4=basseffect = max(max(bass,bass_att)-1,0);

per_frame_5=mv_y =4- min(((bass_att+bass)-2)*0.25,0.9);

per_frame_6=mv_r = basseffect*4;

per_frame_7=mv_b = basseffect*3;

per_frame_8=mv_g = basseffect*3.5;

per_frame_9=wave_y = if(beat,.5,.4);

per_frame_10=ib_a = foo;

per_frame_11=beatcount = beatcount + beat;

per_frame_12=initframe = if(below(beatcount,1),frame,initframe);

per_frame_13=rozzorrate = (frame-initframe)/beatcount;

per_frame_14=monitor = rozzorrate; 

beat is never assigned.

Me don't understand.

That's the code that belongs on the bottom of her version of my preset - obviouslt she just cut-and-pasted the code across, and forgot to change it appropriately.

- Krash

Neither is foo. It is a blank preset. Earlier in the thread I posted a group of presets with the Advanced Beat Monitor as the underlying preset and beat detection presets inserted. I usually use the shift key with the arrow keys to select and copy something in another preset and then insert it. Right now I have one going with parts of Krash's, parts of yours, parts of mine, and parts of unchained's. It is a big mess. Open the hood, phear, slam the hood down again.

If beat is either 0 or 1, using it as a basis for assigning .4 or .5 to wave_y usually works to make something where it is very easy to see if the beat is hitting the music right. EvilJim originally assigned a continuous variable to it, which works well, too.

Ok my turn
 

With aLL this code on beat detection i am still a little lost but i was able to put it to use in my newest preset.
The key thing here is the beat detection in action and i must say it has added that little something i was missing

Feel free to rename it becouse the code i used was from
Rovastar ver 3 in Rovastar's and Evil Jim's Advanced Beat Monitor

included are the before and after.

P.S takes a few sec to clear up on start and find the beat.

????The beat code thing from mainly Krash but some of mine in there and rozzers (in fact none of eviljims) so too many so do not worry about it.

It does not use any of the beat code at all.:confused: Did you post the correct version. It is all in there it is never called.

Also if you reduce the hue shader it stops that horrible chuncky waves coming over the screen.

This looks like anbiguity in the guise of scientific inquiry to me.. in 1-4, you state the same thing four different ways, without any statement actually serving to isolate an entity or property, or give any means of falsification. Five appears in much the same sad shape, though I get a sense that here you're actually groping for a different characteristic. An analysis isn't the place for this kind of sloppy thinking.

I get the sense that you picture a beat as some sort of atomic entity, equivalent to the notes on a piece of sheet music. Don't be mislead by notation; we're effectively doing a fourier analysis on a complicated wave. Beat detection is exactly itself, and nothing more..if you're not isolating the beats, how do you hope to quantify them with variables? Does the common (and in notation useful) conception of some nonexistant "metronomic" property actully gain us anything? I think not. (And also fail to think.)

1-4 aren't saying the same thing at all. They're saying four different aspects of a whole. The beats should be detected the same every time you play the same piece of music. They should be regular, and the regularity should conform to the music. The detected beats should also be accurate - it's no good to have 4 beats detected to a bar if they are detected at a time other than the actual beat.

Let me put it simply.
Imagine you have a standard pop-electronic song playing, in 4/4 time.
Good beat detection should have a "pulse" that occurs four times per bar, at exact intervals. No more, and no less.
If you want to be a bit pedantic, there should be a little bit of variation possible to account for the fact that human drummers can never keep an exactly constant beat.

If a beat isn't detected as a discrete entity, what's the point? It may be technically superb, but if the detection of a beat can be something other than 1 or 0, then you may as well simulate this "reactive" variable with something that varies within the same range, but doesn't take as many cpu cycles to calculate.

The whole point is that we produce a visible and discrete reaction to the beat on screen - nothing else will appear reactive to the casual viewer.

What we're doing has very little in common with fourier analysis. For those who don't know, fourier analysis is the mathematical process of breaking up a complex wave pattern into its component simple sine waves. What we are (at least, what I am) trying to do is not to break up the wave into its component parts, but to identify significant and spontaneous fluctuations in the wave (not even the wave per se - more like the derivative of the moving average of the wave, though even that's not right)

Oh, and we should stop using big words where simpler ones will do. It makes us sound pompous :p

- Krash

Silly me
 

Sorry about that rovastar i did post the wrong one thats the before version ..... meening before i made changes and assigned values to the wave. and since i thought it was the right one i have since deleted the other. I will get to work on fixing it.
Sorry guys/girls about that.

Should by what criterion? What actually works this way?

Ok, there's an obvious problem in terminology here. In what way is your "regularity" and "conformity" different from your "sameness", "accuracy", and your requirement of temporal coexistance? Differences in notation can indeed create differences in ontological commitments, but in this case, I don't see how your requirements serve to supply discernable elements.

A third time? For who's gratification?

If we're going to use it as a standard, perhaps it would be desirable to indicate some concrete instance? From what follows, your "standard" seems at variance with mine.

Not on breaks where a beat is intentionally skipped? What about backbeats? Dischordant interludes? Tonic refrains?

Why limit our generality there? Why not consider a non-human drummer? A drummer on acid? A drummer from mars? A drummer who's in fact playing a tuba? What about the (all to common with today's synthesis equipment) drummer who's playing too fast for the human ear to detect?

What is at issue here is not technique, but methodology. I'll grant that your code is technically superb, far more so than mine's ever been or is likely to become. Not all problems however succomb to mechanistic solutions. Reading your comments, I get the somewhat disquieting impression of a world in which music was something that had handles on it, projecting at predictable and consistant intervals, such that it could be connected to a system of ropes and pulleys so-as to act like a type of artificial puppeteer. Indeed, why not connect these handles to a piano, and use them to create music that detected its own beat? Then our job would be done with no work on our part whatsoever!

Theft over honest toil.

By the criterion that it's the same piece of music. A given piece of recorded music will be identical every time you play it. Hence the beat detection should also be identical. It's a mathematical process, after all. The process should be exact enough that it doesn't make mistakes, or skip beats on one play through that it picks up another time.

By regular, I mean temporally - the detected beats should be spaced evenly apart in time. By conformity, I mean that the number of beats which the algorithm detects should be the same as the number of beats detected by the average human listener (given the same parameters and definitions of "beat").
It could be that our definitions differ here. To me, the actual music shouldn't make any difference at all. If you really want an example, take "Closer" by Nine Inch Nails. This song (particularly for the first half) has very obvious beats to it. But I believe ANY song should work fine. Backstreet Boys to Bloodhound Gang, Metallica to Mariah Carey, Contemporary music right through to classical (though beat detection in classical music can be understandably difficult). All music can be written on a musical stave, with a designated time signature.

Correct. And this is probably where our definition of "beat" differs. Personally, I would like to have a beat variable that pulsed at precise intervals. It would be up to the application (preset, dancing vis plugin, audio analysis, whatever), as to what to do with this pulse, and how to modulate it. To use your example, you would probably not want a preset to react when a beat is intentionally skipped - this can be analysed by volume levels, etc - pretty much what I'm already trying to do. However, even though the preset doesn't react, it still knows that a beat was *supposed* to be there. Because the beatrate is known. Similarly, you may not want drastic visual response to very quiet music, or to crazy drum fills, or multiple instruments playing in different time signatures. The beat of the music, however, should still be pretty constant.

[quote]Why limit our generality there? Why not consider a non-human drummer? A drummer on acid? A drummer from mars? A drummer who's in fact playing a tuba? What about the (all to common with today's synthesis equipment) drummer who's playing too fast for the human ear to detect?[quote]

You're just raving now...

Um... I don't know about your music, but my music has always had handles on it. If it was intangible, you couldn't write it down. In fact, if you look at it in a certain light, music already does detect it's own beat. Music isn't a system - it's a collection of well-organised sound. The organisation defines the beat. Any sounds generated by humans will inherently have a beat - the human brain functions entirely on rhythms. Even something like applause has a rhythm to it - if you let the applause continue for long enough, the rhythm will become apparent (assuming there's no morons in the audience who are purposefully clapping out of rhythm just to ruin my point)

Personally, I think we're arguing semantics here, but I'm willing to continue if you are ;) :)

- Krash

Take, for example, a classic drum solo like:
http://www.rpi.net.au/~liniere/hotdrums.mp3

Not 4/4 time or any other consistant time signature, and my foot taps to the bass, not to the snare that the winamp presets react to because it is louder. I would want my beat detection code to allow effects the same as the wave amplitude if that is the best I could do, but having one that would pick out the bass would be cool. Different beat engines for different purposes, perhaps?

And play that mp3 to the attached preset and watch the monitor. Creepy how it stays steady. The differences between the different beat engines that are out there are subtle. I *think*, but I can't prove, that unchained's works better on a wide range of songs (low and high volume, classical and rock, etc.)

Bottom line for me is that they are fun to hack.

I haven't listened to the solo yet (give me time)

But personally, I've always found Unchained's presets to be a bit hyper-reactive. Not to criticise too much or anything (they still look cool, and I have profound respect), but they keep on jiggling about like a mad thing, even when the music is below audible volumes. It kinda irritates me, that's all =]

I'm getting to that mp3 and preset, just give me time...

EDIT: Right, having listened to it...

Firstly, it is in 4/4 time (believe it or not). It jumps back and forth between syncopation, cut common, and standard alot though, so it's hard to tell. Personally, I don't think many people could "tap their feet" to the solo (I'm an ex percussionist, and I had trouble). Appreciate it's skill, yeah. But tap your feet? quite difficult.

As far as the beat detections go, I'll definitely admit that unchained's beat engine seems to be able to pick out the beat in this solo. This is quite a miraculous feat, and although it's great, I'm not convinced that it's not a fluke. Still, it's quite an accomplishment.

My own beat detection, on the other hand, does fail quite miserably in this situation. It picks up the snares, as you said rather than the bass kicks. The preset is analysing bass over volume, however, so I don't know how I could make this better - we don't have a getspec function in milkdrop.

Unchained's code holds up well with this mp3, and I'm sure with alot of dance-y type music. This is, no doubt, because this is the music that unchained primarily listens to, and so he codes his beat detection to suit. It only makes sense. I listen to slower rock-type stuff, and made my code to suit that.

Out of curiosity, I tried both versions against some classical music - Johann Pachelbel's Canon in D Major.
Both of them basically sucked - Unchained's was too fast, and missed the beats more often than not
Mine was too slow, and picked up the plucking notes (not sure what instrument they're made on), which are off beat triplets.

It's definitely a case of different algorithms for different situations. We can't code something robust enough to work everywhere with a couple dozen lines of code.

- Krash

What beat?

Did you want to give that question some context, or are you just spamming again?

- Krash

Some classical pieces are better candidates for beat detection than others. An example of a good one is http://www.nvo.com/adagiotrio/nss-folder/publicfolder/Jesu Joy of Mans Desiring Bach_Adagio Trio.mp3 ]: http://www.nvo.com/adagiotrio/nss-fo...licfolder/Jesu Joy of Mans Desiring Bach_Adagio Trio.mp3 [/URL]

While it is true that slow pieces may not work as well for beat detection engines that were designed on faster music, I believe that is not the source of the "hyper-reactive" problem. I think that the problem is not too much reactivity but rather is a high level of sensitivity that has to be "tuned" to the preset effect. I did this with unchained's by using:

mybeat = if(above(pulse,3.2),1,0);

When I've put my beat engine in different presets, I've had to change a constant or two every time to get the effect I want. The sensitivity of unchained's presets comes from things like using the frame as the basis of the algorithm and not diluting the inputs much by multiplying them by values less than one.

I have this theory about how they work. I think they are state machines that are analogous to orbits. A sound can only escape the state machine if it is energetic enough. The variables "entropy" and "chaos" are like weights on the flywheel to slow it down.

Sensitivity is different from reactivity. There can't be such thing as too much sensitivity, and it can always be controlled. Another analogy: having enough sensitivity is like having good water pressure, then if you have too strong of a flow out of the tap all you have to do is turn down the faucet.

I was going to just let this die, but what the hell.. :)

Quoting Krash and Roz both, argue amongst yourselves as to who said what :P

I can't argue this at all, but I'd like to hope that this has at least lessened in recent versions. A lot of things contribute to this. The main factor is that I don't often actually tune the effects to the engine...you'll see in a lot of cases that (for example) the zoom reacts almost perfectly to the bass but the rotation seems quasi-random. I usually connect the various things I'm detecting to the effects without much thought, just trying to see how much I can squeeze out of a single variable.

Another factor (as you've pointed out) is tempo. You'll see that in the engine itself, I don't make any use of the time/frame/progress variables, and don't really attempt to determine a "tempo" for the music.

This, I think, is the heart of my contention. Certainly, any piece of music can be given a signature. A signature is, by nature, "after the fact" as it were. I want to say (and this might not be QUITE right) that this is something that can only be assigned to a piece as a whole, having heard the whole thing. With real-time beat detection, we're attempting to write the stave on-the-fly. We have no idea (save for predictions made from common musical practice) what the actual time signature is, or if so certainly NO idea how long it's going to stay that way. This is why I say we're not given handles, merely hints.

But isn't this what we already have with "AVS-style" beat detection? Here you're assigning a tempo, (in a way that I can only call arbitrary) and correcting it. Presumably by giving it a nudge on a "light beat" and a good solid shove on a "hard beat".

NOW I feel we're once again speaking the same language, and can perhaps be friends. I'm looking at something that is an "inner product" of the sound waves themselves up to a given point, as it were. Standard musical notation just doesn't handle (and wasn't designed to handle) the temporal factors we're dealing with here. We need to know the state of this internal rythms now, right this instant. We don't know that there are going to be three more beats in a given measure, unless we somehow "project" an end to the measure.

I've certainly tried to make it so, however there is some truth to Krash's comment that it works better with the music that I listen to most often. It's not so much that it reacts better to a given type of music, but that it reacts like ME to any given piece. I'm struck again and again by the uncomfortable feeling that I've somehow given my own musical tastes to a piece of code.

A very good analogy, and one that (at least to me) does it more justice than my own of waves lapping at the shore.

Another key issue here. For my end of things, I think that the sensitivity of my engine as it stands is "correct", and that the reactivity (manifested in my actual construction of effects) is what needs the most work. I'm not sure how much can be said though...as at this point the human factor enters, because after all aren't we hedging our bets not against how the computer will act, but how an observer will respond to the preset?

OK my turn
 

Not that i even close to being able to to code like you guys i have found the using the bass code i got from here called
Rovastar ver 3 in Rovastar's and Evil Jim's Advanced Beat Monitor;
is doing a fine job woth some clasical for example Carl Orff -carmina Burana - O Fortuna is a good one.

Excellent - it appears we agree on things here, and now we can stop arguing =]
I feel much better knowing that I don't have a detractor amongst the other preset authors ;) :p

Let's just let this one lie, take it as a learning experience, and be friends, k? :)

- Krash

It's my sad lot in life that I'd rather make observations than friends. No harm intended. (Save that which was done :p)

Just going through to get some help with my Beat WIP (that isnt really great and probably never will be).

Under blue moon i saw you.