It'd be awesome if the default front-end settings were documented. I'm still in high school and my knowledge is terribly limited, but damn it, I'd be more than eager to learn to learn the basics regarding shaders and mess around with it.

Most of the effects are based on one of my early abominations, so they're generally hacky, undocumented and inefficient, so I'm not overly surprised that one'd get lost in them. Heck, I get lost, most of the time.

In essence, the effect runs once per pixel. Most of the work is to determine where in the viewport that particular fragment is, and query the information available (waveform texture, parameters, colors).In most of the effects, there's things like measuring "how many pixels are we above the upper side of the waveform", "how far below the low side are we", "are we occupying a position that needs part of a bar rendered". Once you have the numeric or logic facts, you can start combining them to get something that looks awesome.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

I had to use a debug build to tell if it was working at all while developing, as I couldn't be bothered digging up multi-hour files. There are formats that are quite costly to decode though, which is one of the purposes.

This post has been edited by Zao: Apr 2 2013, 23:49

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

You could fake a smooth reveal of the data by looking at the ... odd, I could've sworn I had a "current-time" and "duration" semantic binding.If I had semantics for those, you could look at the current time and the duration of the track, and do your own fades based on their relation, and other sweet-ass time-dependent effects, like sparkling and whatever

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

I had to use a debug build to tell if it was working at all while developing, as I couldn't be bothered digging up multi-hour files. There are formats that are quite costly to decode though, which is one of the purposes.

I have plenty of 60 or 80 min 24/88.2 and 24/96, etc. flac files. The incremental display is great.

I updated to 0.2.34 and the high cpu usage is still up to 70% for a few seconds. Reverted back to .29, because it doesn't have this problem and the scanning runs smooth in the background (also being pretty fast)

A future release, probably 0.2.35, will have three additional float effect parameters to play with, TRACKTIME, TRACKDURATION and REALTIME, corresponding to the number of seconds elapsed, number of seconds in the track, and a second count from some point in time since the startup of the frontend.

An example video of what one then can do with time-varying parameters, a cute wave:y position indicator.

I updated to 0.2.34 and the high cpu usage is still up to 70% for a few seconds. Reverted back to .29, because it doesn't have this problem and the scanning runs smooth in the background (also being pretty fast)

Could you please use Process Explorer when this happens and see what threads are consuming CPU, like shown in the following image?The three threads that mention foo_wave_seekbar.dll are likely the waveform extraction threads, or possibly worker threads for GDI/Direct2D, if you use those frontends.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

I updated to 0.2.34 and the high cpu usage is still up to 70% for a few seconds. Reverted back to .29, because it doesn't have this problem and the scanning runs smooth in the background (also being pretty fast)

Could you please use Process Explorer when this happens and see what threads are consuming CPU, like shown in the following image?The three threads that mention foo_wave_seekbar.dll are likely the waveform extraction threads, or possibly worker threads for GDI/Direct2D, if you use those frontends.

It happens mostly on long files (dj sets or whole-file albums). Also 0.2.29 does it, so i guess it's the cpu needed to render the file. Although it would be nice to have a different approach on resolution/granularization for large files. Or, if possible to limit the amount of CPU it takes to scan.

The majority of the scan cost is in actually decoding the file. My code accounts for maybe 10-20% of the time taken to analyse it.If you don't want bursts of work while using the player normally, consider extracting the waveforms ahead-of-time through the context menu.

As for artificially taking more time, I don't really see much point in that. The analysis runs at idle priority already, so it shouldn't affect any competing processes adversedly. If anything, it'd make things worse as dynamic frequency scaling wouldn't kick in, or kick in erratically.

Do you have an actual adverse effect by this usage of a resource that's mean to be used as needed, or is it some kind of mindset of yours? There is work that needs to be done, and it doesn't do (much) excess work.

The only known problem is that the predictive analysis might cause the same track to be scanned multiple times if started while a scan is in progress, but that's about it.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

i have loads of 2-3 hour DJ sets and it's not adversely affected anything i'm doing while it's working. i did time my longest file (3h20m mp3) just for giggles and it took 36 seconds .... and i have a celeron as well.

I have done some pondering on whether it's beneficial to seek and only decode equally spaced parts of the tracks, but it's very hard to beat the speed you get from pure decoding if you try to seek around.

If my memory is right, the cutoff point was somewhere around 30-50% content analysed if you did the seek-and-decode-chunks dance. This means that you gain nothing at all and lose over half of the information in the tracj, resulting in a significantly inaccurate waveform, and it only gets worse once you try to look at even less than that.

It's inevitable that you need to decode the whole track, so there's a base time cost I cannot get around.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

a little bug in 0.2.34: when shuffling, it displays the wave of the last played song for 1-2 seconds until it decodes the current one. Looks kinda weird and can be misleading on long files Also I got used to the blank screen from .29.

Everyone has different feelings about blanking/flat/previous waveform when encountering a track that doesn't have a waveform. I don't really see much point in working anything out there, as there's a very simple solution.Just scan your tracks ahead of time.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

Everyone has different feelings about blanking/flat/previous waveform when encountering a track that doesn't have a waveform. I don't really see much point in working anything out there, as there's a very simple solution.Just scan your tracks ahead of time.

Just to let you know, I have had the Direct3D Frontend Settings not opening any window problem reported by NullString here. There are however 3 important differences. I had not the DirectX runtime installed, and I'm using CUI. Also, after having selected Direct3D and started to play a track, I've noticed that WS reverted automatically to the GDI frontend. Obviously, Direct3D was not working correctly on my machine.

After some searches, I've found that it is necessary to install the DX runtime, and I've installed it. That solved the problem. So, I guess that the DX runtime is not correctly installed on NullStream's machine. And I suggest, if it's possible, to write an error message in the log when WS detects that the DX runtime is not installed or, more important, not working correctly. (Maybe it's already the case, I haven't verified.)

I have also a question. Currently, the frontend script is loaded via the window. Does that means that the old effects directory in appdata is not used any more and that it can safely be deleted? Thanks in advance.

throw std::runtime_error("DirectX redistributable not found. Run the DirectX August 2009 web setup or later.");

Yes, there should be an error printed to the console, but it's inaccurate. The redist you need is February 2010 (or June 2010).

See the very first post in the thread for the requirements:

QUOTE

The Direct3D 9.0c mode requires the DirectX end-user runtime dated earliest February 2010, which can be installed through use of the DirectX end-user Runtime Web Installer (make sure to not accidentally install the Bing Bar they try to force on you).Note that the DirectX redistributable is required on all OSes no matter whether you think you "have DirectX installed already, lol" or not.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.