Martins collection of milkdrop presets

[Nitorami]

Hi there !

Long time no visit here. I am pleased to see that my old login still works, and that there is now a visualisation section. Great !

I'll take this opportunity to post my collection of milkdrop presets I made over the years. They were originally published on the winamp forum starting in 2008, but the future of that forum is uncertain, the owner does not seem to be interested and it was close to being shut down a couple of times already.

So... this pack includes not only new works but (most of) my early attempts... oh my  !
I went through all of them and made minor corrections where necessary to cope with the much faster modern GPUs, or to fix odd bugs. So if you happen to use my presets already, I recommend to replace them. They should all run ok with milkdrop v2.25c, although there's a few caveats:

- Do not use milkdrop v2.25d (comes with winamp 5.9x). It has no benefit, but it is buggy and cannot handle float to integer conversion.
- Shader model PSVERSION 4 (see at the top of the .milk files) does not work with ATI video cards, due to an old bug in the milkdrop dll I am unable to fix. Therefore I avoided model 4 where possible but there is one exception:

My latest work "emergency power supply only" is based on Nivush's ray marching code and needs PSVERSION_COMP=4, so won't run on ATI. Sorry for that. And it will take a few seconds to compile, so I recommed not to store it in your standard presets folder, as it will interrupt the smooth transition between presets. Other than that, it needs its "skin" martin_skin_emergency_power_supply.jpg, and loads three random textures found in its own folder or under the milkdrop textures folder.

If you find a problem or a missing image, please report here.

Enjoy!
Martin

[dro]

- Shader model PSVERSION 4 (see at the top of the .milk files) does not work with ATI video cards, due to an old bug in the milkdrop dll I am unable to fix.

Shader Model 3 should work with AMD cards as it's what DX9.0c implies though I vaguely remember having to tweak something with the SM compilation steps to get it behaving for the WACUP build of milkdrop when I had an AMD card to test against so I might be misremembering something here. No idea about anything from "winamp" as I'm not touching their versions though most problems likely stem from trying to update the nseel implementation & how that might be different depending on the version of it that's being used in the dll.

[Nitorami]

Hi DrO
The common notion of shader models is not congruent with milkdrop's numbering, i.e. PSVERSION 4 may refer to something different that commonly understood as "shader model 4"... I don't remember the details but the ATI problem definitely occurs with the shader model that allows 1024 instructions rather than 512. I think that is model 3.

Back 2010, Eo.S posted an idea why this does not work, and proposed an easy fix. Sounds quite plausible but I am not an expert. Citation:

"Having run milkdrop through Microsoft's directx debugging tool PIX, I noticed that for presets that are running in pixel shader 3.0 mode, the vertex shader's are all compiled as shader model 1.1, while the pixel shaders are compiled as model 3.0.
ATI cards will not run ver 3.0 pixel shaders with non 3.0 vertex shaders. Any version of pixel shader below 3.0 can be combined with lesser versions of vertex shader, which is why 2.0 and 2.x presets still work in Milkdrop 2.

DirectX will actually issue a warning in regards to this, but not an actual error so it can be missed during development if using NVidia GPUs. I'm familiar with the error because Rendermonkey issues the warning. When I use Rendermonkey on our ATI GPU computers I have to set the vertex shader to compile for vs3.0 whenever I set the pixel shader to use PS3.0 or it doesn't render. On our Nvidia GPU computers it still issues the warning, but the GPU allows it and still renders.

This is a very easy fix codewise, as the fxc compiler just needs to be given the flag to compile VS as 3.0 for PS3 presets, so hopefully a winamp developer with access to the MD2 source can implement this fix.

It's possible this may not be the only issue, but having spent the last 6 years programming on both ATI/Nvidia GPUs I'm pretty positive this should be the whole of it.

Eo.S. "

[dro]

I know that the PSVERSION vs SM used isn't aligned due to it needing to account for either nothing, SM1, SM2, SM2.1 & SM3. There's also a pre-emptive SM4 define in the code but it was never hooked up to be used. As for the quoted part from Eo.S. I don't think I've come across milkdrop not trying to use the SM version but I also can't remember what exactly I did to my build of the plug-in without trying to find some of my old notes when I had more interest to work on vis plug-ins. All I know is presets that didn't work with AMD worked ok after whatever I did (maybe it was something about the flags passed to compiler) but it likely doesn't matter if most people now seem to be on nvidia cards.

[Nitorami]

Interesting. Alright, once I can get hold of an ATI card, I'll try.

[Aminifu]

Hi Nitorami,

I really enjoy using your Milkdrop presets. Thank you for this package of updates. They do run better with the Nvidia graphics card I'm using. I'm using version 2.39 of Milkdrop that comes with the current x86 beta build #21066 of WACUP.

[hatecubed]

Thanks Martin, appreciated as always. Somehow you still manage to take presets to new heights!

[Nitorami]

@DrO for info:
Regarding the compatibility of PS4 presets with AMD video cards, I tried WACUP's milkdrop implementation on my father's AMD Ryzen 3 5300U with Radeon graphics. Unlike winamp, it does not crash or show a black screen, but it neither works as it should, it seems the PS4 shader parts are simply deactivated. So in case of PSVERSION COMP=4 the comp shader is skipped and the output of the warp shader is displayed instead.

[dro]

I don't have AMD based gpu hardware to test it on so I don't know why it's broken when as afaict it worked with what I did have years ago. Maybe the AMD / OS drivers have changed much more in that time since I think I'd done those patches on my old Win7 dev machine. Unless I'm provided with a better patch than what I'd attempted (am not expecting that'll happen) I've no plans on looking into it any time soon as I'm not in a position to by buying hardware just for a vis plug-in.

[Nitorami]

My note was informative only, as I had promised to check this out. I did NOT mean to ask you for fixes of sorts. I know your ressources are limited and visualisation is not on your list of top priorities.
Not a big issue, there are now standalone milkdrop visualisers which simply listen at linein:// and can play all milkdrop presets, plus offer a lot more features, e.g. serge000's milkdrop3. And as far as I can tell from my own tests, serge000 has resolved the AMD issue.

[Nitorami]

Look. This is a beautiful atmospheric milkdrop preset I made over the past weeks. It features a variety of random scenes, random textures and a strictly rhythmic light pattern.  The screenshots don't really do it justice, you need to see it in motion.

Unlike my earlier presets, this one needs a bit more GPU power, and requires a half decent gamer's video card. Nothing too fancy, something like a mainstream GTX1650 of 2019 should run it smoothly. It does not require a high frame rate BUT BUT BUT the GPU power should suffice to keep it constant. The GPU load varies, depending on the scene shown, and if the GPU is too weak, the frame rate will change, causing unpleasant speed changes and stuttering. My own old GT710 does exactly that, and as a workaround I set the Canvas Stretch to 1.67 and limit the frame rate to 25 in the milkdrop settings, to get it running ok, albeit at lower resolution. Not satisfying really.

Note - On loading, the code will take a few seconds to compile, interrupting the usually smooth flow of visuals. If this is unacceptable, consider using third party milkdrop derivates like milkdrop3 or beatdrop. They have solved the issue by precompiling and caching presets, resulting in virtually zero loading time.

An on AMD video cards: Neither winamp nor WACUP support PSVERSION 4 on AMD video cards. But milkdrop3 and beatdrop have solved this.

A note when you use beatdrop: Beatdrop ignores the preset's aspect ratio correction, causing an unsightly disproportional stretch on wide monitors. To avoid this, I strongly suggest to set bScreenDependentRenderMode=0 in beatdrop.ini. And to leave it at that.

Best
Martin

[Incubo_]

Hey! The inverse aspect ratio correction is 1 because it depends on screen (has Screen-Dependent Render Mode ON). That's why it does look stretched, but try this trick:
In a warp/comp shader code, multiply the uv with

Code: [Select]

float2(1, texsize.y/texsize.x) This is the most efficient way to aspect correct without problems.

So it goes like:

Code: [Select]

...
float2 aspect_ts = float2 (1, texsize.y/texsize.x);
rd = RotXYZ(float3 ((uv_orig-.5)*aspect_ts.xy/zoom*float2(torusdir,1),1), scenerot);
...

Let me see if it works for you.

...or I'll look into the code and I'll fix the ignored aspect ratio correction for shaders. Someday, somehow...

EDIT: I did look at milkdropfs.cpp and I see that both aspect vars were initialized with 1: https://github.com/OfficialIncubo/BeatDrop-Music-Visualizer/blob/master/vis_milk2/milkdropfs.cpp#L4951-L4957
I'll have a fix when I have time.

EDIT 2: Fixed: https://github.com/OfficialIncubo/BeatDrop-Music-Visualizer/commit/b6b9ea0665067027e23829dab133d5f051080f79
I'll update the BeatDrop beta test package shortly, so you can try.

EDIT 3: Updated! You can try to test with your presets if it works.

[dro]

So everyone else has working amd support I take it but haven't passed any of that knowledge back, how nice.

[Nitorami]

DrO: You made it rather clear that visualisation is very much at the bottom of your priority list, so I don't quite understand the intent of your comment. Anyway, the code is on github.

Incubo: We talked about that before per PM. I told you that you got the aspect wrong / different from milkdrop. You answered that this was because of an issue with vertex coordinates, and I should set bScreenDependentRenderMode=0 in the ini file. Well, that worked for me, although I was annoyed that you left the default setting at 1, breaking milkdrop compatibility. Why don't you simply set bScreenDependentRenderMode=0 per default ? It seems to do the job.
Anyway, the latest beta does it correctly, and independent of bScreenDependentRenderMode.

[Incubo_]

With Screen-Dependent Render Mode, it fixes the incomfortable behavior of old MilkDrop Presets, ex: Eo.S, yin, Che, Zylot etc.
And glad it's working with its feature on and shader aspect variable ignore fix.

Did you see my edits from the post I've told earlier?

Maybe I'll have an ability to turn on/off this feature with hotkey later...