Album Art

[vigorousjammer]

I'd like to see more album Art support in Milkdrop.

Let us use it in the background, maybe have an option for it to show up when the song title does.

I love looking at album art while listening to my music, and this would be a cool alternative way to let me do that.

[MadnessR]

Does anyone know if this is even a possibility? I think it would be great to have it in the lower left corner with the song title and time.

[gasbag]

Please :-)

[ravermeister]

+1

[MadnessR]

I was told by the people over at www.soundspectrum.com that winamp doesn't allow plugins to access information such as album artwork. So probably won't happen.

[DrO]

that's a load of bullshit and i'd have expected them to have done some research since plug-ins can access the albumart and there are api's in place to do it. Milkdrop has not had added any support to do this via the native Winamp api's.

-daz

[MadnessR]

If it's possible, why hasn't this feature been added?

[DrO]

because no one has the time or no one has thought about doing it or no one cares.

i really don't know and i really wouldn't expect anything to change any time soon as there's not been a large Milkdrop (or even proper Winamp) update in a while and all of the changes in the last year have only been for fixing localisation issues.

-daz

[ravermeister]

I really can't understand why Milkdrop2 is closed source
if the responsible developer has no time to implement those features...
if we had somehow the possibility to contribute code to MD, I Think
the guys from Morphyre/ProjectM/Soundspectrum would contribute some of
their knowledge back to MD. I as a Java Developer would try it for sure

[DrO]

just like how well the open sourcing of MD1 went? as that really turned out great for Winamp... not. the MD1 and AVS open sourcing was the experiment to see if it was worth it on certain areas and as it never worked due to a number of reasons, i doubt there is going to be any consideration to do the same again for MD2.

open sourcing things is not a wonderful magical thing which suddenly gets things fixed or features added, etc. and considering how people even actively do things for Winamp plug-ins, just expecting it all to be magically sorted is just naive with how things are.

yes i probably sound bitter / pessimistic about it but as i'm going on what i've seen, i have little faith in open source helping. i'd love to see people on the team working on things for the proper Winamp (not the Android verison) but that's not how it goes at the moment and that's just how it goes - you get what you pay for (and before anyone says it, Milkdrop is not covered as part of the 'pro' license).

-daz

[ravermeister]

but in fact there is NO WAY for Supporting the Developer of MD2 in any kind of way,
meaning you can not donate money ca not Contribute code nor post bug reports or anything
similar, which could help,
this led me come to the opinion that simply no one cares about MD2, and I Think
this is the reason why so many Payd alternatives are outside
(Morphyre / G-Force / Aeon / ProjectM...)
which got some bugs as well.

If I'd the Chance for Donating money for an Feature Request of MD I'd chosen this way
instead of Buying one of the Above Visualizer...

[Nitorami]

It's probably true that going open source does not automatically solve problems, but on the other hand I cannot really disagree with Ravermeister on the apparent lack of care for MD. I personally put a lot of effort into making presets, and I find it just absurd how even utterly trivial flaws would not be rectified over years... such as the malfunction of the pow() function for instance.

[DrO]

MD2 was a one off contracted job to my understanding, everything else done after ryan did his MD2 stuff has been done by whoever was on the dev team at the time, be it localisation additions or minor configuration fixes to the changes which came in 2.2. as such donating to development on MD2 wouldn't really be something which is feasible.

i understand that people using it and who have spent time making presets want more things / more support. but the same is from the people using AVS or using the library or podcasts or other features.

and that's then not forgetting people now using the Android app (which seems to be the main priority). i'd love to see everything on Winamp proper being worked on / improved / added to but that's just being unrealistic with what is deemed as the priority for the dev team to work on. if that's not liked, other going off and making your own, putting up with it or using something else instead, there's not much that can be done to change that unless it's decided by higher up the chain.

as for the 'trivial flaws' i know both myself and benski have tried to look into them but if they cannot be reproduced on a dev side then it's nigh on impossible to properly fix them and yes i know that's no excuse but wasting 2 days and not getting an resolution on the issue is not an acceptable usage of time (especially when i tried doing it off my own back) on something which is provided for free (MD2 does not count under the pro features).

-daz

[Nitorami]

DrO - I know how difficult it is to find problems that cannot be reproduced on a dev site, but that is not quite to the point because definitely Benski confirmed that he could reproduce some of the serious issues such as the crash on the A key. However, while it makes me rather angry that a music player can crash my entire system, I sort of understand that the problem is difficult to trace because it may be hidden deeply within the innards of DirectX or some other MS mammoth programming platform where the source is not available.
I just don't understand how it is difficult to find a straightforward error in the expression evaluator, which yields bollocks results such as pow (0.9,1) = 0.9049.

[DrO]

Originally Posted by Nitorami

I just don't understand how it is difficult to find a straightforward error in the expression evaluator, which yields bollocks results such as pow (0.9,1) = 0.9049.

i wouldn't know as i wasn't aware of that as i don't remember seeing it sent to betalist and i generally don't bother paying attention to the vis sub-forums (is usually only when i've got to remove spam from in here that i then look at recent posts).

so is there a simple example / preset which shows this issue? (so i can try to look into it whilst i finish off the localisation-blank screen issue i need to finish fixing)

-daz

[Nitorami]

I sent it to the list ages ago but the guys seem to be totally absorbed by localisation issues... just enter

monitor = pow (x, y);

where x is smaller than but close to 1, and y is close to zero, into the per frame section, and see the result. The problem with this is that we use factors such as

decay = pow (0.96, 1/fps);

to make presets run fps independantly, but the error will cause this to become >1 on high fps machines and the preset will freak out and become unstable.

martin

[DrO]

well that backs up one of my previous points in that different people using Winamp in different ways want to have different things prioritised and most of the time at least someone is going to be annoyed / frustrated / upset that their most important feature is not being fixed / worked on.

for example, should i have spent time finishing off the Shift+F10 / Windows App key handling patch i've been sitting on for a while for the library? may be not by most people's views but as something i personally use then i thought it more worthwhile to speed up my means of using Winamp. yet i'm sure more people would never notice it and it'll just be deemed as a waste of time / bloat by others.


anyway, i've just given it a go (now that i know how to view the values - didn't really know about the 'N' option) and can confirm the issue. though quite why ns-eel2 is mis-handling things seems very strange... will see what i can try to find out what i can / see if i can fix it. is that the only one that is causing issues or are other functions doing the same sort of thing as well?

[edit]
ergh, assembler code... might take me a bit longer as i'm extremely rusty on such things nowadays.

-daz

[Nitorami]

DrO

I am not attacking you, and I recognize there are priorities. I also recognize that for most users the viz is certainly not the most important feature of MD. But as I put my spare time into it and point out potentially critical flaws, I just do not like this to be ignored. If I am told to shut up because things won't be fixed anyway for whatever reason, fair enough, I can live with that. In which case I'll stop bothering. But to get no response from the list and see unresolved issues lingering for years is not too motivating.

I am also not requesting fancy features but bring to attention certain problems I consider critical. While the error of the pow() function will just make the vis unstable, the A key issue has the potential take your machine down, which I find rather unacceptable, particularly for users who have paid for the pro version. Benski has confirmed the problem (for XP) and looked into it two years ago but he could not solve it, so that is probably a difficult one.

If you'd like to try - run milkdrop under XP with any preset, press the A key for a mini-mashup, then terminate MD. On the next start of MD or after terminating winamp, you'll be likely to get an error message and in one of ten cases, winamp will then hang. If you should still manage to call up the task manager - takes a lot of patience - you'll see 99% processor load, the windows processing queue is virtually dead, and you should be so lucky to be able to kill the process. Using the A key definitely has a russian roulette feeling for me.

On the assembler: I thought MD was written after 2000 ? Who would still use assembler ? It may be worth pointing out that the issue was, to my recollection, NOT introduced with the ns-eel language extensions a while ago. Unlike loops, megabufs etc., the pow() function existed in older versions already and it always had the error.

I am not aware of errors in other functions, and even the pow() function works ok in most cases, just NOT when the first argument is close to 1. Strange, I would have expected that MD would just pass the arguments on to the numerical coprocessor but apparently this is not the case.

Cheers
Martin

[DrO]

i know what you're doing and it's the same as the people sending things to the list about localisation issue.

i can no longer properly attempt to look at the 'A' issue since i don't have a true XP install anymore and doing it via a limited XP VM is not something i really want to do. i did try to look into it as well when i had a real XP machine and was _never_ able to reproduce it.

Originally Posted by Nitorami

On the assembler: I thought MD was written after 2000 ? Who would still use assembler ? It may be worth pointing out that the issue was, to my recollection, NOT introduced with the ns-eel language extensions a while ago. Unlike loops, megabufs etc., the pow() function existed in older versions already and it always had the error.

most of the plug-in is c/c++ but as ns-eel uses assembler to do certain aspects in an attempt to do things faster or something like that - it's just how it's implemented. things still are written in assembler if trying to achieve a certain type of performance, etc so just because of where we are, doesn't mean assembler is not relevant - it's just i'm somewhat rusty on such things and i'd prefer to fix the implementation used without having to try to change everything else in ns-eel2 (as that's far far outside of the remit of what i can warrant doing off my own back considering the list of things i actually need to work on).

it does seem to be it's only with < 1 values where things are being incorrectly rounded (have spent more time messing around looking at it instead of working on what i should really have been doing) though i need to properly see what is / isn't being passed through the internal function to work out the cause of the issue (which my gut makes me think it's how rounding of the values is handled).

-daz

[MadnessR]

So, now that MD2 is open-source, how long before you expert programmers out there get us some album artwork? :-)

[DrO]

you can get the code, so you can start on adding it...

[Prenso]

I think it will be at least a year or two before we start seeing any real progress towards a new version or Mod. Ive had so many ideas over the years i swept under the rug since it was not opensource. I am sure everyone has had some badass add-on ideas that they forgot about since it was not readily doable. Just a matter of time before milkdroppers, old and new, start breathing life into these old ideas.