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 864093 times) previous topic - next topic
0 Members and 5 Guests are viewing this topic.

foo_wave_seekbar

Reply #1375 –
Just an update on my issue. I installed the suggested/required runtime and it's now working correctly. Strange that I still don't see anything related to this component in my fb2k's component folder.

foo_wave_seekbar

Reply #1376 –
That's because components you install yourself are put in the user-components folder. The components folder is only for default components included in the standard Foobar2000 installation.

foo_wave_seekbar

Reply #1377 –
In particular, user-installed components end up in your foobar2000 profile directory, which for a non-portable install (or a regular one without user profiles) isn't the same as the application directory.
There's one profile for each user that runs the shared foobar2000 installation, each containing an user-components directory.
You can access this mysterious profile directory by holding the shift key and clicking File -> Browse configuration folder.
Stay sane, exile.

foo_wave_seekbar

Reply #1378 –
Thanks to both of you for the clarification and especially Zao for the component and the handy tip!

foo_wave_seekbar

Reply #1380 –
I have a portable install of the latest version of Foobar on Vista and all components are apparently up to date.

I have now installed both Visual Studio 2012 Update 1 (x86) & DirectX June 2011. I've copied the .DLL files to the Foobar application folder (\Foobar2000\) & have uninstalled and reinstalled the component.

But I'm afraid the seekbar has effectively disappeared for me... any idea on how to get it back?

foo_wave_seekbar

Reply #1381 –
Zao, I found something that is bit annoying for me. It is connected with playing CD-DA tracks. I understand why waveform seekbar isn't created for CD-DA tracks - that is perfectly OK. But why waveform isn't flushed and seekbar doesn't become empty when I play CD-DA track after some FLAC or mp3? It shows waveform of last played track from HDD instead... It's misleading. Especially because when I play all tracks from CD-DA, that waveform persists on all of them... I propose simply flushing waveform or adding some text label on seekbar like "CD-DA track detected - no waveform will be created". But simply flushing is also good resolution.
Info:
I am using last version of wave_seekbar (0.2.36.1) under the last version of foobar (1.2.6 final) under Win7 x64 SP1 MSDNAA PL, with several vc_redist packets installed (including that for 2012) and last DX9 redist package installed (June 2010, version 1974).

foo_wave_seekbar

Reply #1382 –
already reported just a few posts up. known bug.

foo_wave_seekbar

Reply #1383 –
The reason for the CD-DA block is because scanning a physical CD will completely destroy real-time playback and scanning, and likely end up ruining the lifetime of the drive due to constant interleaved seeking. Considering that pretty much all CD-DA tracks are from a physical CD and not an ISO, it's utterly impossible to scan anything in the background from a disc while playing it.

Similarly, if I allowed scans of discs that are not currently played, the concurrent scans would end up doing the same constant-seeking problem.

As for waveforms remaining, yes, it's painfully known, and it's not trivial to add in rejection notifications of formats in the codebase.
Stay sane, exile.

foo_wave_seekbar

Reply #1385 –
... also had the issue with MS-Visual-Studio dependency.

foo_wave_seekbar

Reply #1386 –
0.2.37 has some fancy new changes now.

First of all, I've started moving some stuff out of the UI element to make it a bit less fat and brittle, now sharing playback callbacks between multiple seekbar instances. This might cause some instabilities in corner cases, please report any new crashes.

I've implemented blanking of the waveform for unknown and forbidden/unscannable tracks, so whenever you play a stream or an unscanned track, the previous waveform will be hidden from view.

Finally, I've disabled the pre-emptive scanning of the next track in the playback order due to the aforementioned splitting out of playlist events, this should not be too noticeable.
Stay sane, exile.

foo_wave_seekbar

Reply #1387 –
Quote from: Blasphemy13 on
... also had the issue with MS-Visual-Studio dependency.

While it might be slightly inconveniencing for you all, it's a necessary thing for me if you all want me to keep targetting XP.

I've got to jump through more and more hoops to keep it building for the platform. Heck, I have to use a virtual machine now to build it using experimental Visual Studio updates. Reworking this to use the static runtime would be tons of work to get my dependencies to behave.
Stay sane, exile.

foo_wave_seekbar

Reply #1388 –
XP is very old... In my opinion it would be fair enough to label a 0.2 version which you deem stable enough as 'final'. Then from 0.3 you could drop XP (legacy!) support.

On a sidenote: for those running XP with the argument it runs better on low spec hardware...A win 7 install generally runs better (!) on old hardware than XP does. (see http://hardforum.com/showthread.php?t=1582487)

foo_wave_seekbar

Reply #1389 –
A 'classic' version has been on my mind occasionally, but I'd still have to maintain and patch it. There is no such thing as "stable enough" in the long run.

I'd have to make 0.3 something more than just "doesn't run on XP" too, as otherwise there's no reason to migrate to it. I'd also lose all the brand inertia and would not be able to automatically migrate existing users, as it can't be an auto-upgrade or force-deprecation. A proper v3 would have to be a superset of what the current bard does to be worth it.

I've got vague ideas of what features would be in a v3, but nothing that's properly thought out. Things that have crossed my mind is things like:

  Drop all the frontends, instead having a single element onto which logical layers of decoration can be added, in a seekbar-construction-kit kind of manner, to allow for things like time indicator ticks, labels with timepoints, without exploding the amount of things the configuration dialogue has to handle.

  Add more kinds of data sources, like spectrum data and other insane analysis methods existing in the wild, like song mood or feel, or whatever people feel they can deduce from a stream of PCM data.

  Not being a big honking pile of mud inside.
Stay sane, exile.

foo_wave_seekbar

Reply #1390 –
Quote from: Zao on
Drop all the frontends, instead having a single element onto which logical layers of decoration can be added, in a seekbar-construction-kit kind of manner, to allow for things like time indicator ticks, labels with timepoints, without exploding the amount of things the configuration dialogue has to handle.

That would be awesome! Maybe using a XAML template/user control, so you could avoid writing any layout parsing, and easily sharing different templates? Even the shader FX could be a parameter. As it currently is, editing the shader is an advanced feature, so editing it inside an XML file doesn't change much from editing it on a stand alone .fx file and it feels more natural for your code.

foo_wave_seekbar

Reply #1391 –
XAML will never happen, not from me.
It's XML, it's flavor-of-the-year, and I'm trying to get less horrible vendor tie-in, not more.
Stay sane, exile.

foo_wave_seekbar

Reply #1392 –
IMHO, XP support shouldn't be dropped because AFAIK fb2k still supports it (at least SP2 and up) but of course that is up to Zao. Seems like the current hoops Zao is jumping through is already enough, I doubt a separate branch would make it any easier.

foo_wave_seekbar

Reply #1393 –
I wish this would scroll [seek into the song] if the mouse wheel was turned above it, at least as an option.

edit: PS. and not a whole full minute like the default one 

foo_wave_seekbar

Reply #1394 –
There's a minor issue where if DirectX9 is not installed, the Direct3D 9.0c frontend option is still available to be chosen. However, the Frontend settings button does nothing, and selecting Direct3D 9.0c button is actually enabling GDI mode; if you close and reopen the configuration window, GDI will be selected. Ideally, if Direct3D isn't going to work, it shouldn't be selectable at all.
 

foo_wave_seekbar

Reply #1395 –
mjb2006: It's a proper rats nest of conditions around there. The current behavior you see is what I ended up with after plugging all the crashes and handling all the fallout from people who had D3D or D2D in their configurations and bringing the player to a new machine. While sure, it might be possible to improve it slightly, it comes at a major cost of sanity to touch anything related to GUI programming.
Stay sane, exile.

foo_wave_seekbar

Reply #1396 –
I've been keeping up with your waveform seekbar releases and appreciate your work, but I just noticed that apparently it uses all of my CPUs even if I have the "Number of concurrent scanning threads" set to 1.  I don't know if I misunderstand the intent of the option or not, but my goal was to keep the fan from coming on on my laptop while I am listening to music, even if I chance on a huge track (which is happening more and more these days  )

foo_wave_seekbar

Reply #1397 –
While I can constrain the number of threads that are used to scan tracks, I cannot control whether the decoder used is threaded in some way, which the new fancy ffmpeg-based ones probably are.
Please verify the number of threads that belong to the component, either by launching/attaching foobar2000 from the VS debugger or by using Process Explorer to enumerate the threads.



If you're using the D2D frontend subtract one as it uses a worker thread to prepare the display.
Stay sane, exile.

foo_wave_seekbar

Reply #1398 –
Quote from: Zao on
While I can constrain the number of threads that are used to scan tracks, I cannot control whether the decoder used is threaded in some way, which the new fancy ffmpeg-based ones probably are.
Please verify the number of threads that belong to the component, either by launching/attaching foobar2000 from the VS debugger or by using Process Explorer to enumerate the threads.

If you're using the D2D frontend subtract one as it uses a worker thread to prepare the display.

Good call.  It's foo_input_sacd that is the culprit instead.  Sorry. (In addition I tried a 2G flac and it only used one CPU.) Thanks.

foo_wave_seekbar

Reply #1399 –
Quote from: tedsmith on
Good call.  It's foo_input_sacd that is the culprit instead.  Sorry. (In addition I tried a 2G flac and it only used one CPU.) Thanks.

If you really want to ensure that foobar2000 only ever uses one core you could find a tool to launch the program with a processor mask pinning the program to a single core.
Stay sane, exile.