Most severe Milkdrop problem!

[StudioMusic]

Quoted from Krash - For some really obscure reason, sometimes a prest will just not work. It has nothing to do with the preset's variables per se, but sometimes MD will just refuse to change some of the values the preset tells it to. The result is that you can get something which is supposed to change (say, the colours in TTWF), that simply doesn't change.
It happens in different things - sometimes a waveform will refuse to change colour, or the warp will be locked, or the rotation won't work, or whatever. The only solution we have right now is (as SM said) to close milkdrop and start it again,(end of quote) which can be extremly annoying if you just want to relax and enjoy Milkdrop the way the presets are meant to be. Ryan you are the best for making my favorite program ever, but this is the worst problem ever, and I think everyone that uses MD has it. I just might be much more particular than some. Therefore I think that any time you spend on improving MD should be first and foremost to resolve this problem. I will be happy once again if this can be done. If I had the knowledge needed I would spend all my free time to resolve this, but unfortionately this is not the case. Thanks, SM

[StudioMusic]

Forgot to mention that I will pray to god everyday for a fix to this problem, it could help. SM

[StudioMusic]

After futher inspection with this problem I believe this is only a windows 2000 and maybe XP, but has far has I can tell it is not a problem in windows ME, just tried to recreate the problem under ME and as of yet have not had this problem, so I can use ME and take approx a 20% drop in framerate and not use the P button and have MD run smoothly or use 2000 with much more speed and everything working but still have this problem so this makes things a little better for me, thank god I have a dual boot machine and can have a choice. SM

[StudioMusic]

Sorry everyone, scratch my last post, just found out it is probably a problem in all ops. Just had it happen in Me also. So to my belief everyone has this problem. SM

[Rovastar]

SM you said

If I had the knowledge needed I would spend all my free time to resolve this, but unfortionately this is not the case.

You can do things to help though.

The best thing to do from a problem solving point of veiw is to try and find a pattern to give Ryan soimething to go on.

If we can give Ryan a pattern to this he can hopefully get around solving it. It is sadly not as easy as just fixing it as it a spurious and sporadic problem. If we can find a preset that is small and relativly uncomplicated then we can go about finding the cause of the problem.
Also it seems to me at the moment that we MD goes wrong all the presets that go wrong will be wrong in that session. Which ones are these? it seems that the complex ones (unchained's ones, etc) are most vulnerable but the pattern might be that the problem only effects ones with video echo on or progress variables, wave_mystery, (I am thinking of the newer features to MD- does it only effect our presets) etc. if you think you have a pattren drop a note to forums to see if we all only get the problem those presets. This is what Ryan will have to do after all so we could help him out a bit.

AS this is the number one problem with MD at the moment I beleive that we could help.

Anyway that is what we can do to help. But sadly my computer is still broken so not for me at the moment but Tuesday I should be back on the case again.

Rovastar

I've actually never had a problem with a preset not working as yet. although I don't tend to leave MD running for more than an hour at a time. I will post any problems that I have should they ever come up though...

[StudioMusic]

Rovastar you are right. I do not have a pattern yet, except that there is quite a few presets that I have experience this problem with and that some will have the problem when others do not, what I mean by this is during one start of milkdrop say unchains has got the problem and then mine will not or vise versa, at this time it is all to sporadic for me to say, although sometimes everything is working just great. SM

[Rovastar]

OK my machine every 5 minutes or so seems to mess up with this it me be ok for some people but I download a new preset like I just did. Krash's old skool blend and it was all red. I though what a useless preset but MD 1.0 had gone all screwy again.

OK not many of mine presest do this. (I have presets in folders of the authors so it is easier to track). But the northern lights series were all wrong as Bellanluna (I checked a lot of them). Just the colour cycling but these are not complex presets and in the per_frame section they only deal with the colours. All the per_pixel was ok.

SO far it only affects the per_frame section of this. AGree everyone.

No it only appears to alter per_frame sections that have user defined variables in them now this is if the user defined variable is never even called.

For northern lights I had in the per frame section
tt = time/10;
per_frame_1=wave_r = sin(15*tt/2)/2+0.5;
per_frame_2=wave_g = cos(tt/3)/2+0.5;
per_frame_3=wave_b = cos(23*tt/2)/2+0.5;


(error: tt acted as 0 - could anyone else confirm this - it is possibly easier to tell with your own presets)

I changed this to:

per_frame_1=wave_r = sin(15*time/20)/2+0.5;
per_frame_2=wave_g = cos(time/30)/2+0.5;
per_frame_3=wave_b = cos(23*time/20)/2+0.5;

ANd all was fine changing back to the other 'wrong' presets proved that MD was still in the 'wrong' state.

Now if I had

tt = time/10;
per_frame_1=wave_r = sin(15*time/20)/2+0.5;
per_frame_2=wave_g = cos(time/30)/2+0.5;
per_frame_3=wave_b = cos(23*time/20)/2+0.5;

It still produces a 'wrong' reset even though the variable tt is never being called. But it deos not update time after initially being called - i think?!

Do people agree with my observation?

I understand that some of the presets are difficult monitor this error as they are so complex but these are relativly simple. When it screws up again I will investigate further.

ANy more input from everyone out there would help.

Also is it only effecting nvidia cards sounds odd but are some people not have this problam at all/ ever.

In the quest for correctness,

Rovastar

[StudioMusic]

Rovastar I have an ATI card that comes with my notebook and it effects it, so I think it is more a scatter problem then we think, but at this time I am very lucky for I have not had this problem in a while. I think it affects color too though because I have seen it, one to point out is one of mine Deviated boxes, but I do not have enough knowledge to say for sure so I will just have to hope it does not do it again for anyone, but then we know it will. Since I have not had this problem in a couple of days and I use MD frequently I will tell you what I have done that seems to have corrected this problem. The only change I had made to my pc in the last couple of days is upgrade my diskeeper from version 6 to 7 and then I did a complete defrag with the new version at reboot. I do not know if it fix my problem or not, but something happened. I always defrag everyday when I boot up, but with the new version it made things better. Can not say for sure but something happened. It is good though that you are trying to pinpoint the problem and help Ryan at the same time. I will let you know if the problem comes back for me or not, which I am sure it will, but hopefully not. Well see. SM

[StudioMusic]

Well Rovastar I told you I would let you know when it happened again and it did with this time with feeling, so I am upset all over again. Now it leads me to believe ( I can not say for sure ) that the harder your processor works or the hotter it is that this problem is more likely to happen. Because I was dong allot of things when this happended. This is only a speculation. SM

[StudioMusic]

One more thing Rovastar, I can not get A hard man to kill ( one of unchained's ) to do any more than spin in circles in grey in the middle of the screen, even if I shut down MD and restart. I am sure it did much more than that when I first saw it. Do u or anyone else have this problem with this one? SM

[Rovastar]

If a hard man to kill is always going wrong and the other known problem presets aren't then recopy it as it most likely a error in those million and one lines or per_* code. One error in there and the whole thing could stop working.

I am presuming that once MD goes wrong all the 'problem' presets then go wrong.

There are two issues here the symptoms of the problem and the cause of the problem I am trying to work out what the symptoms of these problems are. EG what presets go wrong, is it the user defined variables in them that are the problem ones. We do not know for sure.

The cause is another maybe more difficult task.

If anyone wants to help.........

I have added a zip with 3 presets that should all do the same thing they are my Bellaluna preset and when MD goes wrong again could leave MD runnig and open these presets to see if you get the same problem with them.

Bellaluna.milk no user defined variable in it at all. This will work regardless.
Bellaluna test1.milk one user defined variable never not called.
Bellaluna test2.milk one user defined variable called 3 times in the colour cycling.

Just unzipped them to a different directory and F8 to them when MD goes wrong.

This will tell us if it is the user defined variables.

As for the overheating thing sure we all cannot overheat around the world at the same time MD v1.0 came out.

MAybe Ryan changed some of the code for MD and it is not that efficent any more.

BUt lets determine what is going wrong first before we speculate.


Rovastar (in need of a fat joint)

PS SM added a hard man to kill for you in this zip.

[StudioMusic]

Rovastar all the presets in your test zip worked just fine except for A hard man to kill the Unchained-hard man to kill work just as I remember it, so what was the difference between the two again? Also I want to commend you on working on this problem to try to resolve it and as you said even if yu don't at least Ryan will have more data to work with. Also I am pretty sure you are right that when one of the problem presets go wrong they all do, and thanks for giving me back a working hard man to kill. AS for now I just smoke a pipeload with my bud and his girlfriend so I am going to take a break from all this typeing for a while and watch milkdrop to some killer music. SM

[Rovastar]

I wish I was smoking.

Tommorrow I will be

A bit confused at what you mean

The multiple copies of the Bullaluna are really only there for when MD goes wrong again instead of exiting out and restaring switch to these presets and let me know what you get.

They all should work the same but if the 2 'test' ones don't function correctly (or do work correctly) please let me know (I suspect that they will NOT work as they have user variables in them) because then I wil know it is not just my machine and these are realy simple presets and something then concrete to which Ryan can look at.

The hard man to kill preset problably got editted by accident on your machine. Could have been a blank line at the end of per_frame or per_pixel. Or a ; missing or something. MD does not sometimes tell you the per_* section has errors in the code.

Hope it all makes sense.

Rovastar

[StudioMusic]

Now it makes sence Rovastar, I will keep that folder separate and switch when it happens, hopefully I remember the folder, and let you know. I still don't know how my hard man to kill got screwed up? but it works now. Thanks, SM

[StudioMusic]

I have more imput to add to this problem. If one preset has the problem does not always mean that another will. For example, A generous offer could work fine, but deviated boxes will not, and vise versa. You can test this by playing deviated boxes then go to A generous offer and it will not work correctly and vise versa, this seems to always happened with these two presets and I have found similar examples with a few others. I have included a zip with these two and you can put them in a seperate folder and play them and see what ever one plays first the other will not work right. The zip is in another post called test, sorry had a problem posting this one. SM

[Krash]

I haven't gotten any closer to figuring out what's wrong yet, but I have been able to get the problem to occur 100% of the time.
Take four of my presets - dynamic borders (1 2 or 3), oldskool blend, vinyl disc, and windowframe to megaswirl 2.

Now, if you swap between these four presets, in whatever order, the fourth preset you come to will ALWAYS be screwed up somehow. In the case of dynamic borders, the borders wil be black. In vinyldisc, the decay will be 0 (ie - very fast), in oldskool blend, you get no colour, and in windowframe... you get a very fast decay.

My current guess is that it has to do with the number of DIFFERENT user-made variables that have been accessed since milkdrop started - when it gets to some limit, things stop working.

I plan to do some more experimenting with this...

- Krash

[Krash]

It DOES have to do with how many user-made variables have been referenced. The number of user-made variables that milk drop can handle is 23. Any user-defineds that it comes into contact with after the first 23, it completely ignores. Variables encountered before it hits the limit will still work.

This seems like it will have a very simple fix - if Ryan makes it so that after a blend is complete, Milkdrop forgets all the user variables of the previous preset.

At least now we have a solution - if only we can get Ryan's attention...

- Krash

[StudioMusic]

Krash, if Ryan fixes it this way will that mean you will not get the transition change from one preset to the other? What I mean by this is will milkdrop just jump right to the next preset without any variance in between? If this is the case I hope there is another way to fix it, because I like the changeovers. SM

[unchained]

Doubtful, SM. His more likely programatic approach would be to create a new namespace (the actual location in memory where the user variables are stored) for each user variable referenced, then when the blend is done he simply "lets go" of the old one.

As it stands, there's probably only one namespace for user variables (so they're shared during blends, and hang around even when a preset hasn't been shown for 5 minutes) and that namespace has a limit of 23 entries.

If Ryan doesn't respond to this quickly, it would only take me a few minutes to cobble together a script that goes through presets changing all of the user variables to names like User_1 User_2, etc or something like that (perhaps we could agree on a list of common ones like angval, timer, etc and leave those alone) but that would create the new problem of a value the preset can't handle being in that variable when it starts, and also probably cause issues with blending. (Of course, one might argue that such presets should be corrected anyway.)

I strongly suspected that the user variable namespace was somehow a problem, as I've ran into the situation when editing mega-presets where I often change names that past a certain point new names would simply stop working, but I had so many things on my mind I didn't think to mention it here. Sorry

[Krash]

Yeah, if I were writing it, I'd do it the same anyway.

And when making user defined variables, you generally assume that they will be zero (well, technically a null value, but same thing) on the first frame - bouncing ball in particular was built with this in mind.

Like I said, we just need to get Ryan's attention - it seems like a relatively simple problem, now I know what it is

- Krash

[Rovastar]

He have emailed Ryan with this problem so hopefully he will take a look.

[geiss]

Ok, Rovastar rocks for e-mailing me about this (I've been super busy lately), and Krash rocks for figuring out the problem - I can't express how cool & helpful that is.

So, good news: it's fixed (or should be). Give it a shot. 1.01 beta 1 will remain at <A HREF="http://www.geisswerks.com/vis_milk.dll">http://www.geisswerks.com/vis_milk.dll</A> and the bug should be fixed. I've been super busy lately on other projects, so I haven't been checking the forums much, but don't worry, one day soon I'll get some free time and do another big update, fix some other bugs that have popped up, and release 1.01. Should be sometime in the next month.

As far as the fix goes, it was very clean. There should be no problems transitioning (as StudioMusic mentioned); the namespaces for the two presets that are being blended are both preserved (they are separate, actually) until the blend is done, then the old preset's namespace and variable values are discarded. All should be well.

Please post here if you have any more troubles with this...

[geiss]

...and megathanks again to everyone who put their energy into 'finding a pattern' and figuring out the cause!

Peace,
Ryan

[StudioMusic]

Many thanks to Rovastar for emailing Ryan, and mucho thanks to Krash for figureing out the problem and tredmendmous thanks to Ryan for fixing the problem and making Milkdrop my favorite program ever. I am one very very happy camper once again, so far MD kicks butt. Unchained A generous offer is back in my folder, now you can let your self go to your heart is content as far as I am concerned. Milk is bug free on my end once again. Love to all, Studio Music

[Zylot]

HURRAY!

3 cheers to the collective effort of milkdrop authors, fans, and geiss as well! Once I am able to run Milkdrop again I can create presets without limits!

I can't wait!!

[unchained]

Hey! How come nobody thanked me for using 800 persistant user variables in a single preset and causing all of these problems in the first place, huh? :P

[StudioMusic]

Many thanks to Unchained too for creating a majority of the problems and making most of my favorite presets by one author, now I can fly with his and all others. SM

[Krash]

Many thanks for fixing the problem, Ryan - glad to be of service.

- Krash

Just like you asked, unchained, thanks for the insanely complicated presets that brought about this problem

And thanks heaps Ryan for fixing this problem, it is very much appreciated, just wondering whether you're still concentrating mainly on MD or are you spending time making your new plugin Smoke?

And Zylot, where have you been all this time? You, unchained and Krash have made some great stuff, but I haven't seen new stuff from your for ages....

Oh, just read your post on the preset forums Zylot, that sucks.. as you probably know I have a really lousy vid card and MD still runs, so I hope it gets up and running ASAP!

Will you be making up for lost time and posting 80 or 90 presets when you get a new vid card?

Thanks for your presets anyway, hope we can see more from you soon!

[Zylot]

80 or 90?

LoL, I dunno about that, but I can't wait to start makin' presets again.

Here my vid card suddenly is worthless, while on the other hand my roomie buys a TNT2 and finds a GE2 in the box.. go fig?

[Rovastar]

What about me Illusion?

Am I no fun anymore?

Zylot: It is not only you that can post more then 20 presets

Sorry v. drunk and will be v stoned soon.

Speak to you ppl in a couple of days time

It wasn't an exclusive list Rovastar... don't feel left out... I aplogise to anyone else I forgot to mention.. haha I really appreciate your work (and your efforts on the preset guide too)...

And Zylot, maybe you could switch vid cards with your roommate when he's not looking Either that or just swap computers...