Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_wave_seekbar (Read 797197 times) previous topic - next topic
0 Members and 6 Guests are viewing this topic.

foo_wave_seekbar

Reply #1275
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.
Stay sane, exile.

foo_wave_seekbar

Reply #1276
i like that incremental effect but most people will never see it as it's too fast. you need 1h+ long files at least.

foo_wave_seekbar

Reply #1277
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.
Stay sane, exile.

foo_wave_seekbar

Reply #1278
so you can mimic the effect on files that don't need it? any chance that could be implemented?

edit: just seen your edit. i did not know about that.

foo_wave_seekbar

Reply #1279
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
Stay sane, exile.

foo_wave_seekbar

Reply #1280
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.

foo_wave_seekbar

Reply #1281
Zao, version 0.2.30.1 causes some really high CPU usage even after playing stops, i had to go back to 0.2.29 (since 0.2.33 doesn't display waveforms for me)

Most of the versions released in the last few weeks has tons of fun bugs, discovered by friendly people like you all.
You're probably triggering the bug that's fixed by 0.2.31's change "Rewrite scan logic to cope with tracks having strange and unpredictable lengths, once and for all."

The changelog is always available at this Github wiki page.



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)

foo_wave_seekbar

Reply #1282
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.
Code: [Select]
float4 bar( float pos, float2 tc, float4 fg, float4 bg, float width, bool show )
{
    float y = tc.y - 0.3*sin(3.14*real_time) + 0.5*cos(1.1*real_time);
    float x_dist = abs(pos - tc.x);
    float y_dist = abs(y) * 0.005;
    float4 c = (show && x_dist < width)
        ? lerp(fg, bg, smoothstep(0, width, x_dist))
        + lerp(fg, float4(0, 0, 0, 0), smoothstep(1.0/200, 0, y_dist))
        : bg;
    return c;
}
Stay sane, exile.

foo_wave_seekbar

Reply #1283
Direct2D mode seems to be broken as of latest version, D3D and GDI works properly

foo_wave_seekbar

Reply #1284
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.
Stay sane, exile.

foo_wave_seekbar

Reply #1285
Direct2D mode seems to be broken as of latest version, D3D and GDI works properly

Elaborate on "broken". Doesn't display, crashes and burns, disintegrates your pet food? On what OS? With what kind of GPU? What foobar2000 version?
Stay sane, exile.

foo_wave_seekbar

Reply #1286
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.


foo_wave_seekbar

Reply #1287
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.
Stay sane, exile.

foo_wave_seekbar

Reply #1288
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.

foo_wave_seekbar

Reply #1289
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.
Stay sane, exile.

foo_wave_seekbar

Reply #1290
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.

foo_wave_seekbar

Reply #1291
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.
Stay sane, exile.

foo_wave_seekbar

Reply #1292
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.


ok

foo_wave_seekbar

Reply #1293
Is there any place where I can still download valid v .29?

EDIT:
THX marc that was so easy, I feel like a dumb


foo_wave_seekbar

Reply #1295
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.

foo_wave_seekbar

Reply #1296
Yes the effects folder can safely be removed. It isn't used anymore.

foo_wave_seekbar

Reply #1297
Thanks for the confirmation. 

foo_wave_seekbar

Reply #1298
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.
Stay sane, exile.

 

foo_wave_seekbar

Reply #1299
While it is possible to privately deploy the DLLs needed, I'm not going to do that. It'd bloat each and every release archive by 1.7 MiB and the installation by 3.91 MiB.

It's bad enough having to bundle the editor component already.
Stay sane, exile.