Milkdrop2 Beat Detection Auto Adjusting

[Talwick]

Hi there. I'm relatively new to creating Milkdrop presets, majorly because I learnt by "tinkering" and reverse engineering existing ones.

I'm currently working on one, and I'm having a small programming issue I'd like help with.

In a nutshell, what is happening, is as the music plays, the animations are "scaling to" what is playing, and the become less/more depending on the music, until a sudden change (or loud-point) occurs. This is most evident when changing to a new "loud" song where the animations will be very pronounced at first, and then wile down to nothing (even though it may be very loud drum and bass playing for example). Or a new "quiet" song, and then will slowly increase until a tiny sound causes massive animations.

Feel free to look through and modify the code, as I have tried modifying it somewhat to no avail. Any help would be legendary of you, and if it's a setting within Milkdrop2, I'd like to know how to change it so I can "tune" my preset accordingly afterwards.

[Nitorami]

Hi Talwick

This is normal, as the bass, mid and treb signale are auto-gain adjusted. That means milkdrop calculates the smoothed average volume over a certain time, and calculates bass, mid, treb in relation to that. I.e.

bass = instantaneous bass volume / smoothed average bass volume

After a period of silence, the average will have become rather low, and then a loud peak will cause a very high signal, and vice versa. Same for the slightly smoothed signals bass_att, mid_att and treb_att.

This was done to adjust to the overall signal level which may depend on the source. The presets should work reasonably well regardless whether you listen to CD or a radio stream.
But, it means the overall volume information is lost, and the signals do not contain information about the overall loudness, rather its changes.

Ways to reduce the freaking out of signals is to clip them, e.g. such as

mybass = min (bass, 3);

or use the logarithm as "soft clipper"

mybass = log (bass+1);

or the root

mybass = sqrt(bass)

Alternatively, you may try to revert the auto-gain algorithm but this is probably more complex than you can currently handle, and it does not work 100% anyway, as the true volume information is not available.

Alternatively, use the true volume information which is available from the waves section. I can tell you how if you are really interested. Not recommended though fro the reason above, your preset would then depend on the signal strength of the source.

Martin

[Talwick]

Thanks Martin,

I'll have a look around for some solutions now that I know the problem. Perhaps increasing the delay, or finding a way to amplify/multiply the values that the visualizer is using to animate will achieve what I'm looking for.

I would be willing to try using "true volume information", but I wouldn't want to waste your time. If there's a page on which I can find out how to do so, I'm sure I can work it out from there. I'm a fast learner, thankfully.

[Nitorami]

Talwick

I am currently with my parents and do not have winamp on this machine. I will provide you a sample code when I'm back. It is rather simple but not so easy to explain ...

In principle, the raw music information is available via one of the waves section, either as time signal (oscilloscope) or spectrum. You need the spectrum, so set spectrum ON. The values are available in the wave code section as "value1" and "value2" for the left and right channel. The way to transfer them upwards to the "per frame" section is via the 100 global "reg" variables (reg00 to reg99), or via the unlimited global array gmegabuf[].

But of course, you don't want only one "value1" per frame, but at least three, for bass, mid and treb. This is easy but not readily apparent - each waves code section is repeated n times per frame, where n is the number of dots per frame (the first parameter in the waves section). The loop is however implicit and not visible in code, you need to know it... so you'll need a separate loop counter, add up the "value1" and "value2" and assign them to the reg variables... aw, that is really shitty to explain. I'll come back in a few days with an example.

[Talwick]

Martin,

Thanks again. It's no rush at all for you to reply. I had a look through the Preset Editing Menu (I now assume you're opening the file in Notepad, not sure if anything if visible there that isn't in Winamp).

From what I could tell, my skin is dependant on the "Drawing: Custom Shapes" menu to generate the visualization, as all the "Custom Waves" are turned off. I did fine the lines of code for bass_att(ack) mid_att and treb_att in the Per Frame equations in the Per-Frame equations, as well as the Wave_x and Wave_y (perhaps the Value 1 and 2 you mentioned) so I'll try playing with them in a copy of the skin.

So again, like I said, you can take your time. This skin was kind of modified to work this way by chance, so I can understand if it's not a simple change of values, and cut/paste of lines of code. Thankyou for your help and replies though

[Talwick]

I've made a discovery. It seems the Per Frame equations have very little effect on the skin's animation, and mainly adjust reaction amounts. But In the Warp Shader code, I found a line of code which is having a massive change, at least to the skins "breathing in and out" animation where the orb in the centre grows in and out, seemingly to an inaccurate beat detection.

float1 sand = dot(noise2, abs(GetBlur1(uv)-GetBlur2(uv)-GetBlur3(uv)));

If I change the value of "noise2" to "noise1", the "cloud animations" that you'll see around the orb in the centre become solid, and no longer "breathe" with the orb in the centre, but Milkdrop does notify me that is because of an undeclared identifyer, so I'm assuing the "noise" file/texture/source is causing this problem with my skin, and it now no longer auto-adjusts. And upon deleting all the code for the Warp Shader, the centre still remains (as a Custom Shape) and continues to "breathe".

I'm just trying to keep the cloud like effect it had, so I'll see what I can do within this code. I hope that this'll help you somehow

[Nitorami]

Talwick

The bass, mid and treb variables are globally available in MD and they are auto gain adjusted.

What you describe is an optical effect. The warp shader can manipulate pixels directly, and it has a memory, i.e. it can process past images (from the previous frame), and thereby create a decay or smear effect which can be globally controlled by the zoom, rot, dx, dy, warp etc. variables (from the per frame section), or locally, directly in the shader as in your case.
You cannot simply use "noise1" if it has not been declared before; doing so will cause an error message and effectively disable the warp shader.

If you delete the warp code entirely, milkdrop may fall back to version 1, and use the simple video echo effect which is controlled by different variables. This may become a bit messy. For compatibility, Milkdrop 2 still interprets the old variables for the simple video effects although they are now effectively obsolete when explicitly using shaders.

You need to understand a bit more about the principles rather than just try and error. I recommend you read the preset authoring guide that comes with MD.

[Talwick]

Alright, I will do. Thanks for the advice. I knew about the processing from previous frames, but I'll have to do some learning as to not resort to trial and error. But thanks for steering me in the right direction.

I've already made some improvements to the code, and seemingly eliminated the auto-gain adjustment. I just need to find the last culprit which is animating independently to any audio input (which I found by playing a "silent" audio file).

[Phil31169]

Great question.

The only thing i have ever disliked about milkdrop is the auto volumizing thing it does. After wrapping my head around your q&a on the subject i see clearly that i wont be doing anything about it. Milkdrop along with winamp is in my opinion the best option for music on pc that has ever been written. That auto scaling/volumizing is bothersome enough that i think i have explored all other options. Always come back to milkdrop goodness. Please keep me in the loop on your progress, i look forward to this thread expanding and will be checking in from time to time.
Phil.

[Talwick]

New Version of Preset

Thankyou Phil. It's good to hear that someone's experimented with trying different music players, and settled for Winamp and Milkdrop. It reassures me of my rather less researched choice.

As for the auto volumizing. I've tried experimenting with the code for my preset, and settings for the visualizer to no avail. But I have managed to stumble upon the settings that more accurately react to the music being played.

Here's a couple new versions of my previous preset:

http://djollie.deviantart.com/art/Sonic-Boom-Milkdrop-2-Preset-560793862

(bear in mind the preview image is still of the old preset. I was a bit too lazy to make a new one)

I recommend the "Day" and "Night" versions as they feature this updated code, and look alot nicer in my opinion. I fiddled with the shaders, light sources, and colours to achieve their differing styles.

I will take another crack at improving the preset at some point, and finding the root (if any) for the auto adjusting, but for now I think this is good enough. Hope you all enjoy

[Nitorami]

Talwick

Something I just noted - You modulate the global zoom with volume for the bumping effect, but there is still zoom when setting zoom=1. This is unexpected and it took me a while to find the reason: milkdrop knows two other variables sx and sy (where the s stands for "stretch"). They allow to set individual zoom factors in x- and y-direction and they add to the zoom variable. They are currently set to 1.0201 in the milk file, probably a relict of an earlier edit. If you do not need them, you should set them to 1, either directly in the milk file or in the per frame section. They will then no longer interfere with zoom.

And if you do not want extreme zoom values, I recommend to apply a limiter of some sort.
vol=vol*vol; does the contrary, better omit the squaring. And because you do not seem to use the q variables anywhere, you might replace the entire per frame section by something simple like

code:


vol = bass+mid+treb;

zoom = 1.01 + 0.006*min(8,vol);

sx = sy = 1;

[Talwick]

Thanks for that code. I'll be sure to give it a try, since I have very little knowledge of coding, and mostly learnt from "fiddling" and "reverse engineering" other presets.