slow AND smooth?

[DIGIlized]

As far as I can tell, the only way to slow down the speed of milkdrop is to limit framerate, the problem is that the animation becomes choppy/not smooth. Is the anyway you could make milkdrop slow down and keep it smooth, when using it in desktop mode it could be nice to have something a bit more "peacefull" :D. That's all, thnx for a great plug-in :)

[Krash]

You can slow down MD to a limited extent without making it choppy. Running it at 24fps appears (on many presets) much slower than 80fps.
Beyond that, you need to be selective with your presets. Many presets will be quick and jittery no matter what you do, so if you're after a "peaceful" experience, best eliminate those presets. Presets are small enough (only a couple of kB), that you can have multiple copies of presets in different folders. Put copies of all your calm presets in a separate folder, and you can run just those.

- Krash

[bitcore]

I think there is a better way to make the presets's speeds more linear from preset to preset. Instead of just "dealing with it" and removing presets that seem to run too fast or too slow, I propose a modification to milkdrop's configuration.

Timescales. Simple. In configuration, there can be a multiplier, say, defaulting to zero (which will correlate to no time shift) and can be varied from -1 to 1. What this multiplier will do is slow down the time that the preset's code perceives, making it render slower, but just as fluid as before.
If a person has a slow machine and is limited to running say, 25 fps, then the person would shift the timescale accordingly to make the presets run faster to make them all seem "normal. If a person has a really nice rig with the fastest equipment out there, then that person could set the frame limiter to say, 60-90 fps and shift the timescale down to make the presets run slower, while maintain its fluid appearance. This could be viewed as a cheep hack, but it would do the trick. Any other ideas?

Another entitie to this problem is that I find many preset authors are creating presets on a wide variety of systems, some authors have slow systems, and run at a low frame rate so their presets run extremely fast on good computers, and otherscreate theirs at a high frame rate, so theirs run normally on a fast system. There ought to be a standard preset authoring framerate cap that all authors create their presets at. Maby, a fair 40-50 fps. The author can simply adjust quality settings to obtain that frame rate and create the motion aspects of the preset in that mode, and then later (if they have a slow system) raise quality settings to tweak visuals. That way, there won't be a huge discrepancy in preset's movement speed between authors. This combined with the timescale shift could produce a very fluid preset collection.

One easy fix for all of the older presets after this timescale variable has been enacted would be a simple static variable inserted into old presets which would be an old timescale value which some gracious person with no time and a decent system could set for all the old presets. This way we can force the old presets to run slower or faster without having to get into the nitty-gritty intricate parts of the preset.
(I'm up for doing that to some of the really nice presets, I already have selected some great trippy ones for a stoner package from http://www.milkdrop.co.uk/ I haven’t viewed the oldest package on that site yet, I’m still working on this collection.)

What's everyone think? This plugin is so close to perfection we can't let large things like this slide.

[Rovastar]

It sounds eay in theory but there are a lot of factors in the presets that govern the preceived speed. It sometimes stops the movemnt completely and things at are not changed like zzoom, etc will have be be added for spoem presets where is there no code in the per_frame and per_pixel equations.

You cannot treat all presets as the same each of them has to be looked at in turn. And some there is no sure fire way of getting the perfect speed that you designed (esp with teh different mesh settings, etc). Although many now can be tweaked using the fps variable in many presets it is not all that easy to be honest and definatly no magic bullet.

Remember often the presets are *designed* to work at the faster speed presonaly I like 50 fps or so for most of my ones. SO everything has to be reworked and I do not see that happeneing as it will all take sooooo long.

[bitcore]

well is there any possible way to get the preset speed to be constant for the framerate? There's got to be some way other than simple framerate limiting.

[Rovastar]

i suppose there is a solution of working calculating each scene multiple times but would require a major change to the infrastructue of MD and that sort of devolpement is unlikely to happen in the next year or so.

[BSL]

Slow and smooth Eh ? Well my Pc only has a AMD K6-2 450 cpu. And I am no expert when it comes to the tech stuff. This is what I have done to get a nice smooth peaceful flow at about 28 fps. I run my monitor at 1280x1024 32bit refresh rate at 75HZ and MD at xrgb-640x480 32bit. I have taken out all presets that are choppy,uneven,unbalanced,out of wack and not very relaxing to watch. I edited about 100 out of the set that comes with winamp5. I am using about 30 out of a pkg of 169 presets from the MD website. The idea of having multiple folders with your presets sorted in each one is a great idea.Especially with 3600 presets available. At first I thought that the rating system would set up the changes like I wanted, but it is easier to edit the rough one's out. I get a nice consistent flow and all the changes are smooth and it is getting better everytime I add some more sorted presets. Thanks For Winamp5 Nullsoft winamp2x didn't seem to want to run MilkDrop at all on my 450. But know I am a happy Winamper :D

[Krash]

Bitcore - I like the way you're thinking. If you were around 6 months or so ago, you could have had a great input into MD's development.
As it stands, Ryan Geiss is no longer an employee of AOL (the parent company of Nullsoft), and isn't paid to do vis work anymore (last we heard he was contracting for nVidia).
AOL owns the code to Milkdrop now, and further development (by Geiss, by a third party, or open source) is entirely at their discretion. Sadly, I doubt the execs at AOL will ever look at it again.

- Krash

[bitcore]

Oh my god are you serious? AOL owns the code (along with ryan) and might just dump it if ryan doesn’t keep up with it?
I can't believe that, I knew Geiss was signing on to nvidia and the lack of work that comes along with that always occurs but i never thought that it might be abandoned totally...
This is terrible.

I've noticed a lot of other vis programs were strictly frame based on their timings instead of using a clock so that things don’t go super fast in the future when the processing power is readily available.
My laptop has a native LCD resolution of 1600x1200 and can run a solid 50 fps. I am upgrading the graphics card and expect to have a stable native 60 fps. I run many of the presets like this and the entire experience becomes distractive and unrealistic. :(

There's nothing I can do as I don’t program in C. I just think that if the speed was a constant between computers (well, framerates) and owning a really badass system, it would make for a very surreal experience and there would be almost no need for a framerate limiter if a "dynamic timescaler" could be devised.

Just my 2 cents of how I would go about the situation, given that I dont know how MD's intricate framework is. I think way too programatically for my own good.