Chun-Yu
Feb 26 2004, 09:26
Spectrum analyzer data is b0rk (either that or else the example WA plugin only draws 1/2 of it):
Image <-- Look at built in vis and compare
/me is looking into it
Chun-Yu
Feb 26 2004, 09:43
Silly me, the example vis only draws 1/2 of the spectrum :B
ssamadhi97
Feb 26 2004, 15:34
QUOTE(bleh @ Feb 25 2004, 06:10 AM)
- A one-second timer has been implemented on flush like in foo_vis_simple_spectrum.
I checked back w/ foosion and he suggested to look at foo_vis_vu_meter source instead because he solved the problem in a less messy way there.
source is buried somewhere
here
Hmm, foosion's page currently isn't coming up for me, but I'll look at it when it does.
kode54, I'm going to have to agree with you that we need some sort of synchronization before releases... I'm just not sure what the best way to do that would be. Hmm :/.
Skates
Feb 26 2004, 17:16
Some type of CVS system, but this plug-in is to small of a project to be housed on SourceForge!
I'm not sure CVS is necessary... just some way of getting the changes planned for the next release established so people don't keep having to download the latest build and merge all of their almost-completed changes into the new source. The release frequency has slowed down a lot, though, which helps with that.
kode54
Feb 26 2004, 17:36
Simply put, the vis is kept open as long as it is enabled, whether it is receiving audio or not. In that case, it might be wise to update the wannabe deque class to keep track of how many samples are in its buffer, subtracted on every read() operation, and if there isn't enough for read(), fill the output with zeroes... or maybe notify the caller and it can stop rendering frames until there is enough... Meh.
Hmm, I don't know. It'd make full-screen visualizations slightly more annoying because they'd have to be manually exited when playback stops. On the other hand, the timer is kind of messy, so eh.
As for the deque, I think it'd be enough to just fill it with zeroes on flush if we left the window open (it would effectively accomplish the same thing). To be honest, I've never been huge on the deque as a way of keeping exact synchronization (it just doesn't seem like it should work even though, as it turns out, it mostly does), but the code was so simple that I haven't looked very hard into coming up with a new solution. I'm not even sure there really is a way to keep everything exactly synchronized anyway.
kode54
Feb 26 2004, 19:04
Especially considering that even in Winamp itself, the vis just runs on its own in its thread, while Winamp fills the vis sample/spectrum buffers whenever, all without any synchronization whatsoever.
Their "API" sucks.
...and the first time they attempted a rewrite from scratch, the majority of developers avoided it. Of course, it wasn't really designed to be easy to program for...
hartwork
Feb 27 2004, 03:00
A) somehow i can't get 0.389 to compile: i get several dll-manager-related link errors.
B) kode54's interpolated spectrum is more informative but i think what we got to achieve is a spectrum that looks exactly like the one winamp would give them if we want the plugins to run like in winamp. i hope it is possible: i got the impression the vis-data sent by by foobar is of much worse quality than winamp's.
C) on my machine bacon does not really run fluently. even with the cheapest winamp-plugins. i got 1600 mhz so i don't really understand why. i think it's not the interpolation. what else could it be? does it run like in winamp on your machines?
D) maybe the project should be split into more files so everyone works on a different file and only this file is to be updated!?
A) Hmm, weird. You did add dll_manager.cpp to your Visual Studio project, right? Out of curiosity, what kinds of errors are they?
B) We can't get it to look exactly like Winamp's simply because we don't get exactly the same number of data points. I'm not sure I'd say foobar's data is lower quality, but the number of spectrum points is indeed lower, so we can't really tell what would go there unless we somehow tried to calculate spectrum values ourself (messy and probably not worth it).
C) It may be a bit slower on my machine (933 MHz Pentium 3), but it's not that bad. When you say it doesn't run fluently, do you mean that if you use, say, the Winamp example oscilliscope plugin, you get visualization stuttering? That'd be something to look into :|.
D) Well, I'm not sure if that would help with synchronization or not, since it's very possible that we'd all make changes in the same file in the process of doing different things, but I think it may be a good idea to somehow split up foo_vis_bacon.cpp. It's gotten pretty huge.
While I'm posting, does anyone have any ideas for stuff to go into the next release besides miscellaneous code clean-ups or bugfixes?
QUOTE(hartwork @ Feb 27 2004, 04:00 AM)
C) on my machine bacon does not really run fluently. even with the cheapest winamp-plugins. i got 1600 mhz so i don't really understand why. i think it's not the interpolation. what else could it be? does it run like in winamp on your machines?
Runs perfect here.
AthlonXP 1500+
p0wder
Feb 27 2004, 11:59
QUOTE(bleh @ Feb 27 2004, 07:39 AM)
B) We can't get it to look exactly like Winamp's simply because we don't get exactly the same number of data points. I'm not sure I'd say foobar's data is lower quality, but the number of spectrum points is indeed lower, so we can't really tell what would go there unless we somehow tried to calculate spectrum values ourself (messy and probably not worth it).
So in other words the data sent to the VIS is not as updated in foobar2000 as it is in Winamp?
hartwork
Feb 27 2004, 12:46
QUOTE(bleh @ Feb 27 2004, 04:39 PM)
A) Hmm, weird. You did add dll_manager.cpp to your Visual Studio project, right? Out of curiosity, what kinds of errors are they?
i switched to 0.8 final sdk and now it works. i got no idea why...
QUOTE(bleh @ Feb 27 2004, 04:39 PM)
B) We can't get it to look exactly like Winamp's simply because we don't get exactly the same number of data points. I'm not sure I'd say foobar's data is lower quality, but the number of spectrum points is indeed lower, so we can't really tell what would go there unless we somehow tried to calculate spectrum values ourself (messy and probably not worth it).
i didn't mean the number of data points. one and the same song produces much higher spectrum-amplitudes in winamp. either winamp postprocesses vis-data sent to a vis-plug or foo's and wa's decoder makes that difference.
QUOTE(bleh @ Feb 27 2004, 04:39 PM)
C) It may be a bit slower on my machine (933 MHz Pentium 3), but it's not that bad. When you say it doesn't run fluently, do you mean that if you use, say, the Winamp example oscilliscope plugin, you get visualization stuttering? That'd be something to look into :|.
it seems to me as if winamp-plugs run with bacon refresh half as often as in winamp. i suppose foobar does not send vis-data as often as winamp. the stuttering i have is like you work on a high-memory-load machine. 1-2-3-hang-1-2-3-...
QUOTE(bleh @ Feb 27 2004, 04:39 PM)
D) Well, I'm not sure if that would help with synchronization or not, since it's very possible that we'd all make changes in the same file in the process of doing different things, but I think it may be a good idea to somehow split up foo_vis_bacon.cpp. It's gotten pretty huge.
that's a good idea.
QUOTE(bleh @ Feb 27 2004, 04:39 PM)
While I'm posting, does anyone have any ideas for stuff to go into the next release besides miscellaneous code clean-ups or bugfixes?
i think we should focus on the vis-data problem first.
Chun-Yu
Feb 27 2004, 12:46
QUOTE(hartwork @ Feb 27 2004, 04:00 AM)
C) on my machine bacon does not really run fluently. even with the cheapest winamp-plugins. i got 1600 mhz so i don't really understand why. i think it's not the interpolation. what else could it be? does it run like in winamp on your machines?
This is from the 2nd thread looping without sleeping to check the time. I stuck a Sleep(1) in and that reduced CPU usage on simple plugins by about 1/5 here.
Here we run into one of the several issues in translating foobar2000-style vis to Winamp-style vis.
Foobar's visualizations are either tightly synchronized to or part of the main thread (my memory tells me it's the latter, but I'm not certain). Foobar calls a certain number of updates per second. This allows foobar to control the FPS of the visualization. Because it's doing this, it can also fourier transform the data to obtain the most information possible. We may be able to get better results by transforming the PCM data in Bacon itself rather than relying on Foobar's fourier transformer. I'm a little skeptical that coding our own transform will be worthwhile, because Peter appears to use the best code possible for the job wherever possible.
Winamp, on the other hand, has much less structure. It shows the plugin where to find the spectrum/osc data, and relies upon the plugin to call it at will. The input plugins are tied tightly to the spectrum data to provice raw information about the current frequencies.
The short version of this is: Foobar refreshes the spectrum data at intervals. Winamp refreshes the spectrum data constantly. Due to the intervals, Foobar's visualization can appear "jumpy".
Thus, we need bilinear interpolation on the spectrum data: interpolate between both the frequencies retrieved and the packets of frequency data. This means we may need to buffer one "frame" of spectrum data so that we can interpolate nicely.
kode54
Feb 27 2004, 14:20
It might also produce an ugly effect, but perhaps we also need to keep track of how many samples are left over in the circular buffer(s) and linear stretch them to fill Winamp's buffers upon request. Of course, this will probably produce a much worse effect than the stuttering seen when the Winamp vis renders a frame or two without a sample/spectrum update.
Hmm, I'm really not noticing any stuttering. Maybe my machine's slow enough that the lack of synchronization gets smoothed out. Would increasing the visualization framerate in the foobar2000 settings help with this? It'd be closer to continuous updates... at the expense of hogging your CPU :/.
The only other way I've thought up of getting samples over to the other thread would be to buffer a lot of them, then figure out at which point in the present buffer a Render to Winamp would fall and pass that interval of samples, throwing out any samples too old to be used in the process. Thing is, the current method of having the foobar2000 main thread stream samples through a buffer and then the Winamp plugin thread grab snapshots does the same thing in principle and the code is simpler, so it's a question of whether, "in principle," is good enough or whether we should try to get everything perfectly lined up.
@hartwork (on the spectrum data height issue) :
I think I may just start running test tones through both programs and seeing what kind of spectrum values I get because we really should know how both programs generate the spectrum data and, at the moment, I don't.
@Canar:
You know, you may be right about this. The Winamp plugins are only getting 576 samples, while the foobar2000 spectrum is being calculated for however many samples are in each batch (which seems to be something like the sample rate divided by 45, though we really can't make any assumptions about it), so it's possible for the same spectrum data to be handed out for different samples.
@kode54:
I'm not sure what you mean by, "left over." The samples aren't getting thrown away, so if the Winamp plugin calls a lot between foobar updates, it'll just get the same data.
See, this is why I had hack warnings all over when I posted the first build (well, that and the crashing :B ).
kode54
Feb 28 2004, 08:44
"Left over" assuming that on_data is getting more samples than the vis thread can handle. Of course, stuttering would only occur if the vis is swallowing samples faster than they are being updated.
The sample count will always be the sample rate divided by the vis frame rate, I think... I'm not sure about the number of samples fed to the FFT library.
Spaceboy
Feb 28 2004, 21:29
Works fine here in both Windowed and Full Screen modes. It stutters big time in Destop mode though. Tried running Milkdrop in Winamp as well, and same thing happens in Desktop Mode. Using Geforce 2 MX400, Athon 2000 with 512 DDR 2700 RAM. Running Win Server 2003 with DirectX 9.0b.
yathosho
Mar 3 2004, 06:07
QUOTE(hartwork @ Feb 18 2004, 11:47 AM)
-- WHAT ELSE --
i am interested in any source code from previous attempts! please send me a copy - your code is highly appreciated!
you might wanna ask around the
vj forumspersonally i'm stuck between loading exisiting visualizations (avs, milkdrop) or getting some new kick-ass plugin
DaCypher
Mar 3 2004, 11:05
I am probably missing something here, but I downloaded foo_vis_bacon.dll (-0.389) and put it in my components directory. When I select BACON from the components context menu the console comes up with: "ERROR (foo_vis_bacon) : Couldn't load DLL". What am I doing wrong?
Which Foobar version are you using?
You're getting that error because you haven't yet configured foo_vis_bacon to use any Winamp plugins. If you go into the configuration menu, direct foo_vis_bacon to a directory with Winamp visualization plugins in it, and select the plugin you want to use from the combo boxes there, things should work.
DaCypher
Mar 3 2004, 11:37
Ok, now I configured bacon to point to the plugin directory and selected the one I want from the pulldown menus. Now I go back to select BACON from Components | Visualizations and I get the same error. Using foobar2000 v0.8 final.
hartwork
Mar 3 2004, 11:49
version minus038. [
binary][
source]
spectrum looks much more like winamp now. i implemented to different modes: one with interpolation and without. we just got to decide which one to choose (or give the user the option to choose at config). compiled version uses the interpolated one.
WITH interpolation (upper = foo, lower = winamp)

WITHOUT interpolation (upper = foo, lower = winamp)

the screenshots are from my last nullsoft-vis-minisdk-mod which displays all 576 spectrum entries. download it
HERE.
sorry, but i haven't split foo_vis_bacon.cpp for now...
Hmm, I can reproduce this if I don't touch the drop-down menus (meaning I leave it as the default choice), but as soon as I bring up the drop-down menu and select a new plugin, it works again. If you actually mess with the combo boxes, does the problem persist (and also if you restart foobar after messing with the boxes) ? If you still have problems, I can probably get you a build that prints the filename of the current plugin to the console (or, depending on your programming knowledge, you could try it yourself, too :).
I'm starting to question the overall practicality of maintaining this Winamp-style combo box selection dialog given the variable plugin directory. I wonder if having the plugins selected individually by a file open common dialog box might be better... :|.
DaCypher
Mar 3 2004, 11:53
I also tried adding another winamp plugin to the specified directory and chose it from the bacon configuration screen. I then selected bacon from the context menu again, but nothing happened so I attempted to close foobar2k and my entire machine locked up forcing a hard reboot (damn, haven't had to reboot in over a month, WinXP SP1).
This isn't meant as a complaint (I understand this is very early development stages), just trying to get it to work...
WTF :/. I've noticed the issues with bacon sometimes not enabling if you reselect it; I need to look at the source and see which variable isn't always getting set properly, but it really shouldn't be locking up. I guess you can try starting foobar again, going into the configuration dialog and making sure the plugin you want is selected, then closing the configuration dialog, starting playback, and enabling bacon in that order and see if the situation improves, but this is really weird.
As for not being a complaint, well, it should be, since it's evidence of the current behavior simply not working intuitively. I'll look for a bugfix and add some more console info at some point, I guess.
Oh, and thanks for the spectrum work, hartwork

.
DaCypher
Mar 3 2004, 12:01
Ok, got it to work. Not quite sure what I did (combo of messing with combo boxes, selected BACON from context menu, and restarting foobar). Anyways, really cool plugin, thanks.

(now I gotta rebuild all my playlists that seemed to have disappeared after the crash

).
Chun-Yu
Mar 3 2004, 13:02
QUOTE(hartwork @ Mar 3 2004, 12:49 PM)
spectrum looks much more like winamp now. i implemented to different modes: one with interpolation and without. we just got to decide which one to choose (or give the user the option to choose at config). compiled version uses the interpolated one.
Or, vis_bacon can do the analysis by itself and look even more like Winamp :B I may look into using something like FFTW or something for this if I have time
jeffery_901
Mar 5 2004, 11:15
for the mean time,
geiss is availible as a screen saver and works with foobar2000 very well
I use it a parties, screen save set to 1min
avalible at
http://www.geisswerks.com/enJoY !!
seanyseansean
Mar 5 2004, 12:37
Can I be a pain and ask for a new feature?
I have a server and media pc at home, the latter is in the lounge and the former is in the office. Foobar autoloads on the media pc and the vis (milkdrop) is on by default.
Sometimes if I go to the office down the hall, I want to change the tune playing on the media pc. So I Remote Desktop or VNC in and change via the Foobar gui. Problem is, the plugin detects a screen change and comes up with a dialog box saying it can't find Direct X, probably because it's not supported over RD. You can't get rid of these boxes, you have to kill Foobar.
Is it possible for the plugin to detect RD or VNC (I think there's an API, other programs do it) and gracefully shut down the vis? I can dig out the relevent API docs if you like.
Thanks for a quality plugin,
sean
PhrostByte
Mar 6 2004, 14:28
After clicking on "Baconwrap" in preferances.
Illegal operation:
Code: C0000005h, flags: 00000000h, address: 59FF1485h
Access violation, operation: read, address: 00000034h
Call path:
WinMain=>app_mainloop
This is the first crash logged by this instance.
Code bytes (59FF1485h):
59FF1445h: 05 00 E9 56 36 00 00 B8 F0 00 00 C0 E9 9C 36 00
59FF1455h: 00 B8 05 00 00 80 E9 91 36 00 00 8B DF E9 5D 2B
59FF1465h: 00 00 2B DF 83 E8 40 8B F7 2B D7 E9 78 2B 00 00
59FF1475h: 90 90 90 90 90 64 8B 0D 18 00 00 00 8B 54 24 04
59FF1485h: 83 7A 14 00 75 54 90 90 90 90 90 F0 FF 42 04 75
59FF1495h: 19 8B 41 24 89 42 0C C7 42 08 01 00 00 00 33 C0
59FF14A5h: C2 04 00 8D A4 24 00 00 00 00 8B 41 24 39 42 0C
59FF14B5h: 75 08 FF 42 08 33 C0 C2 04 00 52 E8 D2 C8 01 00
Stack (0012F62Ch):
0012F60Ch: 00000000 00000000 00000000 00000000
0012F61Ch: 00000000 00000000 00000000 00000000
0012F62Ch: 77C3B84D 00000020 0012F670 77C40D6B
0012F63Ch: 00000000 00000000 010191F8 0012F71C
0012F64Ch: 00000000 00000000 00000000 0012F640
0012F65Ch: 0012F250 0012F698 77C35BE0 77C14610
0012F66Ch: FFFFFFFF 77C40D53 01003CFF 00000000
0012F67Ch: 01018324 00C9F0F8 00C9EE48 00C9F07C
0012F68Ch: 0012F6C4 010191F8 00C9F0F8 0012F6CC
0012F69Ch: 01012070 00000001 0100434C 00C9F120
0012F6ACh: 01018340 00C9EFFC 00C9ED58 00C9F0D0
0012F6BCh: 00C9F0A8 00C9EDC0 00C9F098 0012F6A8
0012F6CCh: 0012F6FC 01012190 00000005 010046C9
0012F6DCh: 00C9F038 00C9F078 00C47890 00C4784C
0012F6ECh: 0012F7A0 0000000E 0012F71C 0012F6DC
0012F6FCh: 0012F724 01012208 00000002 01010ECB
0012F70Ch: 00C9ED58 00C9EFF8 00000000 0012F70C
0012F71Ch: 00C9ED78 00000040 0012F828 01013618
0012F72Ch: 00000000 00C41345 00000000 000003E9
0012F73Ch: 00C41B21 00C9E530 00C4784C 0012F808
Registers:
EAX: 00000020, EBX: 0012F71C, ECX: 7FFDD000, EDX: 00000020
ESI: 00000000, EDI: 00000000, EBP: 0012F634, ESP: 0012F62C
Crash location: "ntdll", loaded at 59FF0000h - 5A0A4000h
Symbol: "RtlEnterCriticalSection" (+0000000Bh)
Loaded modules:
foobar2000 loaded at 00400000h - 00451000h
ntdll loaded at 59FF0000h - 5A0A4000h
kernel32 loaded at 77E60000h - 77F50000h
USER32 loaded at 76200000h - 76291000h
GDI32 loaded at 73A40000h - 73A86000h
ole32 loaded at 76620000h - 7675D000h
msvcrt loaded at 77C10000h - 77C68000h
ADVAPI32 loaded at 73160000h - 731FB000h
RPCRT4 loaded at 58D80000h - 58E0C000h
COMCTL32 loaded at 5B9F0000h - 5BADC000h
SHLWAPI loaded at 772D0000h - 7731E000h
utf8api loaded at 10000000h - 1000D000h
comdlg32 loaded at 763B0000h - 763F9000h
SHELL32 loaded at 7C800000h - 7D010000h
foo_albumlist loaded at 008D0000h - 008DA000h
foo_ape loaded at 008E0000h - 008FF000h
foo_cdda loaded at 00900000h - 0090E000h
foo_console loaded at 00910000h - 00918000h
foo_diskwriter loaded at 00920000h - 00931000h
WINMM loaded at 76B40000h - 76B6D000h
foo_dsp_extra loaded at 009C0000h - 009D5000h
foo_flac loaded at 009E0000h - 009F6000h
foo_id3v2 loaded at 00A00000h - 00A26000h
MSVCP60 loaded at 76080000h - 760E5000h
foo_input_std loaded at 00A30000h - 00AC9000h
MSACM32 loaded at 77BE0000h - 77BF5000h
foo_masstag loaded at 00AD0000h - 00AE0000h
foo_mod loaded at 00AE0000h - 00AE9000h
BASS loaded at 00AF0000h - 00B4A000h
foo_output_std loaded at 00B50000h - 00B59000h
foo_out_dsound_ex loaded at 00B60000h - 00B69000h
DSOUND loaded at 73F10000h - 73F6C000h
VERSION loaded at 77C00000h - 77C08000h
foo_out_ks loaded at 00B80000h - 00B8B000h
SETUPAPI loaded at 5FB10000h - 5FC03000h
foo_read_http loaded at 00B90000h - 00B99000h
WS2_32 loaded at 71AB0000h - 71AC7000h
WS2HELP loaded at 71AA0000h - 71AA8000h
foo_rgscan loaded at 00BA0000h - 00BAB000h
foo_spc loaded at 00BB0000h - 00BBF000h
foo_speex loaded at 00BC0000h - 00BD8000h
foo_ui_std loaded at 00BE0000h - 00BF7000h
foo_unpack loaded at 00C00000h - 00C31000h
OLEAUT32 loaded at 77120000h - 771A7000h
foo_vis_bacon loaded at 00C40000h - 00C4B000h
foo_vis_manager loaded at 00C50000h - 00C58000h
foo_vis_simple_spectrum loaded at 00C60000h - 00C6A000h
foo_vis_vu_meter loaded at 00C70000h - 00C78000h
foo_wavpack loaded at 00C80000h - 00C8B000h
UxTheme loaded at 5AD70000h - 5ADA5000h
OPENGL32 loaded at 5ED00000h - 5EDCB000h
GLU32 loaded at 68B20000h - 68B3E000h
DDRAW loaded at 73760000h - 737AB000h
DCIMAN32 loaded at 73BC0000h - 73BC6000h
QuickTime loaded at 66800000h - 66D20000h
OLEPRO32 loaded at 5EDD0000h - 5EDE7000h
WININET loaded at 5B7F0000h - 5B893000h
CRYPT32 loaded at 75550000h - 755E5000h
MSASN1 loaded at 61610000h - 61621000h
rsaenh loaded at 0FFD0000h - 0FFF7000h
QuickTime3GPP loaded at 676D0000h - 67761000h
QuickTimeAuthoring loaded at 66FE0000h - 67171000h
QuickTimeEssentials loaded at 67430000h - 674AD000h
QuickTimeInternetExtras loaded at 66F00000h - 66FD7000h
QuickTimeMPEG loaded at 673C0000h - 6742A000h
QuickTimeMPEG4 loaded at 674B0000h - 67523000h
QuickTimeStreaming loaded at 66D20000h - 66DD9000h
WSOCK32 loaded at 71AD0000h - 71AD9000h
QuickTimeStreamingAuthoring loaded at 67800000h - 6784C000h
QuickTimeStreamingExtras loaded at 67850000h - 6786F000h
IPIXSupport loaded at 01120000h - 0118C000h
QuickTimeVR loaded at 66E40000h - 66EA0000h
vis_synesth loaded at 01000000h - 0101E000h
ptc loaded at 01020000h - 01059000h
Hermes loaded at 095D0000h - 095EC000h
MFC42 loaded at 73DD0000h - 73ED0000h
MSVCP50 loaded at 780C0000h - 7814D000h
imagehlp loaded at 76C90000h - 76CB4000h
DBGHELP loaded at 6D6E0000h - 6D765000h
Stack dump analysis:
Address: 77C3B84Dh, location: "msvcrt", loaded at 77C10000h - 77C68000h
Symbol: "lock" (+0000134Ah)
Address: 77C40D6Bh, location: "msvcrt", loaded at 77C10000h - 77C68000h
Symbol: "fprintf" (+00000018h)
Address: 010191F8h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 77C35BE0h, location: "msvcrt", loaded at 77C10000h - 77C68000h
Symbol: "except_handler3" (+00000000h)
Address: 77C14610h, location: "msvcrt", loaded at 77C10000h - 77C68000h
Symbol: "ctype" (+00001D70h)
Address: 77C40D53h, location: "msvcrt", loaded at 77C10000h - 77C68000h
Symbol: "fprintf" (+00000000h)
Address: 01003CFFh, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 01018324h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 010191F8h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 01012070h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 0100434Ch, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 01018340h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 01012190h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 010046C9h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 00C47890h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C4784Ch, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 01012208h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 01010ECBh, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 01013618h, location: "vis_synesth", loaded at 01000000h - 0101E000h
Address: 00C41345h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C41B21h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C4784Ch, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 5BA162CEh, location: "COMCTL32", loaded at 5B9F0000h - 5BADC000h
Symbol: "Ordinal384" (+0000A4D1h)
Address: 5BA163B5h, location: "COMCTL32", loaded at 5B9F0000h - 5BADC000h
Symbol: "Ordinal384" (+0000A5B8h)
Address: 76208821h, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "GetWindowLongW" (+00000034h)
Address: 00450556h, location: "foobar2000", loaded at 00400000h - 00451000h
Address: 5BA146E5h, location: "COMCTL32", loaded at 5B9F0000h - 5BADC000h
Symbol: "Ordinal384" (+000088E8h)
Address: 7620857Bh, location: "USER32", loaded at 76200000h - 76291000h
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 76214183h, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "OemToCharBuffA" (+0000027Ah)
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 76232516h, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "GetClipboardData" (+000002BDh)
Address: 762141A8h, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "OemToCharBuffA" (+0000029Fh)
Address: 76213FEDh, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "OemToCharBuffA" (+000000E4h)
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 76224CC3h, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "UpdatePerUserSystemParameters" (+00000E54h)
Address: 762201FEh, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "SetForegroundWindow" (+0000071Ch)
Address: 00C49060h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C40000h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C40000h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C494A2h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C40000h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C40190h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 762205F5h, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "CreateDialogIndirectParamAorW" (+00000033h)
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 7622F94Ah, location: "USER32", loaded at 76200000h - 76291000h
Symbol: "CreateDialogParamW" (+00000049h)
Address: 00C40000h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C49060h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C47800h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 1000303Fh, location: "utf8api", loaded at 10000000h - 1000D000h
Symbol: "uCreateDialog" (+0000001Ah)
Address: 00C40000h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C44B16h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C40000h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C416A3h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00C416A9h, location: "foo_vis_bacon", loaded at 00C40000h - 00C4B000h
Address: 00404894h, location: "foobar2000", loaded at 00400000h - 00451000h
Address: 004044F0h, location: "foobar2000", loaded at 00400000h - 00451000h
Version info:
foobar2000 v0.8
UNICODE
Synesthesia doesn't seem to be playing nicely. I'll see if I can figure out what it's doing. If you'd like to experiment with other Winamp plugins, try renaming vis_synesth.dll to something like vis_sysnesth.b0rked until I or someone else finds a fix.
[EDIT]: Grrrrr.... the call to winampVisGetHeader is blowing something up and I don't know why. It'd probably help if I could get the Synesthesia source to build :/.
Boomp. I've figured out what caused that crash and the problem isn't with foo_vis_bacon, but rather with the general ugliness of its purpose.
PhrostByte, here's how to get Synesthesia to work:
1. Create a new directory called Plugins in the same directory as foobar2000.exe. The directory for vis_synesth.dll has nothing to do with this.
2. In that Plugins directory, create a file called synesth.log. Without this file, Synesthesia will crash. Why? Because it doesn't bother to check whether the file pointer for the log file actually exists or not and because it doesn't create files to open them; it only appends.
3. Next, copy the program synconfig.exe, probably already installed your Winamp directory (Winamp main directory, not the Plugins directory), into the same directory as foobar2000.exe (again, not the Plugins folder). This is necessary to configure Synesthesia and therefore to get it to select any plugins.
4. Go into the Synesthesia directory and make sure the ini file and Sonique vis directory paths are correct. I really don't know why these point to Winamp for me when the other paths here don't :/. If you don't have Winamp installed, I'm not sure what these paths will look like... you may need to create empty text files manually with the same names to avoid more crashing, but it's hard to say.
5. Please configure Synesthesia before trying to use it.
If anyone else gets crashes with vis_synesth referenced in the crash log, take a look at these instructions.
I hope this helps >_<
No, it's not the ugliness of its purpose. Don't blame yourself. Blame the idiot who wrote that software. I suppose you can't really blame Nullsoft for writing a crappy API, as they didn't know much then, did they? Hmm, maybe they don't now either. Then, blame all the idiots that Nullsoft didn't dare alienate by ever breaking that API to make it cleaner. Then blame them again for rejecting the first and only attempt by Nullsoft to rewrite that API from scratch. Oh wait, haven't I already said this?
PhrostByte
Mar 7 2004, 19:50
Hey cool thanks a lot bleh. I've got a new problem. I ran climax and now I can't close it without crashing foobar. Log:
Illegal operation:
Code: 0EEDFADEh, flags: 00000001h, address: 77E8877Ah
Call path:
WinMain=>app_mainloop
This is the first crash logged by this instance.
Code bytes (77E8877Ah):
77E8873Ah: 08 83 65 B8 00 89 45 B0 8B 45 0C 56 8B 75 14 83
77E8874Ah: E0 01 85 F6 89 45 B4 C7 45 BC 30 87 E8 77 74 25
77E8875Ah: 8B 4D 10 83 F9 0F 77 C4 85 C9 89 4D C0 74 07 57
77E8876Ah: 8D 7D C4 F3 A5 5F 8D 45 B0 50 FF 15 04 15 E6 77
77E8877Ah: 5E C9 C2 10 00 83 65 C0 00 EB EB 90 90 90 90 90
77E8878Ah: 8B FF 55 8B EC 83 EC 1C 6A 00 6A 1C 8D 45 E4 50
77E8879Ah: 6A 00 FF 75 08 FF 15 24 11 E6 77 85 C0 7C 0F 8B
77E887AAh: 45 0C 8B 4D E4 89 08 33 C0 40 C9 C2 08 00 50 E8
Stack (00254830h):
00254810h: 00720065 0064002E 006C006C 00000000
00254820h: 0009000B 00080163 002548E8 00254788
00254830h: 00251EA4 00254790 00251EAC 00254798
00254840h: 73EE0000 73EE1021 00004000 003E003C
00254850h: 002547E0 00160014 00254808 00084004
00254860h: 00000001 5A06EDB0 00251FFC 40342726
00254870h: 00000000 00000000 000B000D 00080168
00254880h: 003A0043 0050005C 006F0072 00720067
00254890h: 006D0061 00460020 006C0069 00730065
002548A0h: 0057005C 006E0069 006D0061 005C0070
002548B0h: 006C0050 00670075 006E0069 005C0073
002548C0h: 00490056 005F0053 004C0043 004D0049
002548D0h: 00580041 0064002E 006C006C 00000000
002548E0h: 000D000B 0008017B 00254990 00254828
002548F0h: 00000000 00254830 00251EAC 002549A0
00254900h: 01780000 017F6B08 000BB000 0060005C
00254910h: 00254880 0020001C 002548C0 00284004
00254920h: 00000000 0012FD0C 0012FD0C 2A425E19
00254930h: 00000000 00000000 000B000A 000E0140
00254940h: 003A0043 0057005C 004E0049 004F0044
Registers:
EAX: 00000002, EBX: 00254924, ECX: 00000100, EDX: 00E78A30
ESI: 00000002, EDI: 00251EA4, EBP: 002549A0, ESP: 00254830
Crash location: "kernel32", loaded at 77E60000h - 77F50000h
Symbol: "RaiseException" (+0000004Ah)
Loaded modules:
foobar2000 loaded at 00400000h - 00451000h
ntdll loaded at 59FF0000h - 5A0A4000h
kernel32 loaded at 77E60000h - 77F50000h
USER32 loaded at 76200000h - 76291000h
GDI32 loaded at 73A40000h - 73A86000h
ole32 loaded at 76620000h - 7675D000h
msvcrt loaded at 77C10000h - 77C68000h
ADVAPI32 loaded at 73160000h - 731FB000h
RPCRT4 loaded at 58D80000h - 58E0C000h
COMCTL32 loaded at 5B9F0000h - 5BADC000h
SHLWAPI loaded at 772D0000h - 7731E000h
utf8api loaded at 10000000h - 1000D000h
comdlg32 loaded at 763B0000h - 763F9000h
SHELL32 loaded at 7C800000h - 7D010000h
foo_albumlist loaded at 008D0000h - 008DA000h
foo_ape loaded at 008E0000h - 008FF000h
foo_cdda loaded at 00900000h - 0090E000h
foo_console loaded at 00910000h - 00918000h
foo_diskwriter loaded at 00920000h - 00931000h
WINMM loaded at 76B40000h - 76B6D000h
foo_dsp_extra loaded at 009C0000h - 009D5000h
foo_flac loaded at 009E0000h - 009F6000h
foo_id3v2 loaded at 00A00000h - 00A26000h
MSVCP60 loaded at 76080000h - 760E5000h
foo_input_std loaded at 00A30000h - 00AC9000h
MSACM32 loaded at 77BE0000h - 77BF5000h
foo_masstag loaded at 00AD0000h - 00AE0000h
foo_mod loaded at 00AE0000h - 00AE9000h
BASS loaded at 00AF0000h - 00B4A000h
foo_output_std loaded at 00B50000h - 00B59000h
foo_out_dsound_ex loaded at 00B60000h - 00B69000h
DSOUND loaded at 73F10000h - 73F6C000h
VERSION loaded at 77C00000h - 77C08000h
foo_out_ks loaded at 00B80000h - 00B8B000h
SETUPAPI loaded at 5FB10000h - 5FC03000h
foo_read_http loaded at 00B90000h - 00B99000h
WS2_32 loaded at 71AB0000h - 71AC7000h
WS2HELP loaded at 71AA0000h - 71AA8000h
foo_rgscan loaded at 00BA0000h - 00BAB000h
foo_spc loaded at 00BB0000h - 00BBF000h
foo_speex loaded at 00BC0000h - 00BD8000h
foo_ui_std loaded at 00BE0000h - 00BF7000h
foo_unpack loaded at 00C00000h - 00C31000h
OLEAUT32 loaded at 77120000h - 771A7000h
foo_vis_bacon loaded at 00C40000h - 00C4B000h
foo_vis_manager loaded at 00C50000h - 00C58000h
foo_vis_simple_spectrum loaded at 00C60000h - 00C6A000h
foo_vis_vu_meter loaded at 00C70000h - 00C78000h
foo_wavpack loaded at 00C80000h - 00C8B000h
UxTheme loaded at 5AD70000h - 5ADA5000h
wdmaud loaded at 72D20000h - 72D29000h
WINTRUST loaded at 76C30000h - 76C5D000h
CRYPT32 loaded at 75550000h - 755E5000h
MSASN1 loaded at 61610000h - 61621000h
IMAGEHLP loaded at 76C90000h - 76CB4000h
msacm32 loaded at 72D10000h - 72D18000h
midimap loaded at 77BD0000h - 77BD7000h
KsUser loaded at 73EE0000h - 73EE4000h
VIS_CLIMAX loaded at 01780000h - 0183B000h
winspool loaded at 73000000h - 73026000h
DBGHELP loaded at 6D6E0000h - 6D765000h
Stack dump analysis:
Address: 73EE0000h, location: "KsUser", loaded at 73EE0000h - 73EE4000h
Address: 73EE1021h, location: "KsUser", loaded at 73EE0000h - 73EE4000h
Address: 5A06EDB0h, location: "ntdll", loaded at 59FF0000h - 5A0A4000h
Address: 01780000h, location: "VIS_CLIMAX", loaded at 01780000h - 0183B000h
Address: 017F6B08h, location: "VIS_CLIMAX", loaded at 01780000h - 0183B000h
Address: 73000000h, location: "winspool", loaded at 73000000h - 73026000h
Address: 7301DBC7h, location: "winspool", loaded at 73000000h - 73026000h
Address: 00420040h, location: "foobar2000", loaded at 00400000h - 00451000h
Address: 5A06E3B0h, location: "ntdll", loaded at 59FF0000h - 5A0A4000h
Address: 5A06E3B0h, location: "ntdll", loaded at 59FF0000h - 5A0A4000h
Address: 00420044h, location: "foobar2000", loaded at 00400000h - 00451000h
Address: 6D6E0000h, location: "DBGHELP", loaded at 6D6E0000h - 6D765000h
Address: 6D70B8F4h, location: "DBGHELP", loaded at 6D6E0000h - 6D765000h
Address: 0040003Eh, location: "foobar2000", loaded at 00400000h - 00451000h
Address: 5A06ED78h, location: "ntdll", loaded at 59FF0000h - 5A0A4000h
Version info:
foobar2000 v0.8
UNICODE
But oh well, as long as geiss's plugins work I'm a happy boy.
Ooh, fun. More crashing plugins!
...
Eh, debugging this is easier than trying to deduce how this FFT stuff works from whatever pages Google barfs up :/.
[EDIT]: It doesn't crash for me, but it does try to kill foobar and then lock up. I wonder what it's doing.
[EDIT EDIT]: Instead of creating its visualization window as a child window like it's supposed to, Climax makes its own standalone window and then probably uses some weird hack. I managed to crash Winamp with it, too. I'm really not sure what else I can say about this plugin except that it's probably not worth using.
PhrostByte
Mar 8 2004, 09:33
Yeah.. it isn't.. I was just testing stuff out, but yea thanks again
Yay, bugfix release (version minus0.37).
Source (requires the
KISS FFT library to compile, but I may decide to distribute that along with this at some point.
BinaryThe infamous MSVCR71.DLL. Put it in the same directory as foobar2000.exe if you don't already have it. This is only necessary for builds I release since my version of Visual Studio is too new - binaries from kode54 and hartwork should be fine without it.
What's new (-ish):
- If the plugin fails to start up, it should turn itself off and then resume trying to work normally the next time you try to enable it (bugfix).
- If you enable the display of debug messages, the filename of the DLL being loaded to do visualization will now be displayed, which should make it easier to debug weird problems where you think you've got everything configured properly but it still tells you the DLL won't load.
- Fixed irritating bug where foobar2000 would hang if you tried to close it without stopping visualization first.
- Spectrum data is now calculated for the samples being sent to the Winamp plugin using KISS FFT; however, the resulting spectrum still doesn't look like the one Winamp generates. Joy! I would have held off on releasing this until I figured out why this is happening, but I considered the above bug serious enough to justify shoving a build out the door.
- I started splitting up foo_vis_bacon.cpp, but then got lazy and stopped :/.
p0wder
Mar 10 2004, 17:29
Thanks for the update bleh. Hope you can get the spectrum data thing worked out.
pineapples10
Mar 22 2004, 13:12
can someone please make a tutorial, or compile appropriate versions of plug-ins and files that would allow me to get milkdrop/bacon working in foobar. Ive tried and tried, but I keep get an error message saying bacon cant be initialized. Any help would be greatly appreciated.
Chris
I'm too lazy to put together a web page now, but here's a brief summary:
1. If you do not have Winamp installed, create a directory somewhere to hold your Winamp plugins and install a bunch of Winamp plugins there. I don't know if you do or not, but if you don't have Winamp installed and you're having problems with this step, let me know and I'll see if I can make it easier for you... some plugins require extra effort to install without Winamp (I should make a list or something :| ).
2. Download the binary linked to in my earlier post and extract foo_vis_bacon.dll to your foobar2000 components directory.
3. If you do not have Visual Studio .NET 2003 installed on your system, you'll probably also need to download MSVCR71.DLL (also linked to in my previous post, though it is zipped), and put it in the same directory as foobar2000.exe. Without this, you'll get error messages about not being able to load foo_vis_bacon.dll, which I suspect is what happened to you, but I'm not sure.
4. Go into the foobar2000 Preferences menu and select. "Baconwrap," under the Visualizations group. Ignore any messages about not being able to find any plugins for now.
5. At the top of the foo_vis_bacon configuration screen is the directory currently being scanned for plugins. If you have Winamp installed, this should hopefully be pointing to your Winamp plugins dir. If not, you'll have to click the ... button and select the directory to search. For now, it will only detect Winamp plugins named something like vis_PLUGINNAME.dll, but I could decide to make this an option for people who really like having every DLL in a directory scanned. If you get an error message after selecting the directory here and you're certain you have plugins in it, let me know.
6. Next, look at the two combo boxes below it. The top combo box tells you which plugin is currently being used. If you drop it down, you should be able to select Milkdrop without any problems. The combo box below it is for setting the plugin module to use, which is useful for some plugins like the Nullsoft Tiny Fullscreen visualization, but doesn't matter for Milkdrop because Milkdrop only has one module.
7. Once you've selected the plugin you want, you can configure it by clicking the, "Configure Module," button. It should bring up the configuration dialog for the plugin exactly like in Winamp.
8. Now that you have everything all configured, close the preferences dialog. In the main menu, check to Components -> Visualization -> Bacon. That should make foo_vis_bacon run whenever foobar's playing audio.
9. Play something and see if it works.
Also, for anyone who's wondering, the reason I haven't released an update recently is that Winamp's spectrum analysis confuses me, possibly because I don't really know anything about spectrum analysis. If I feed it, say, a 1500 Hz sine wave at a sampling rate of 48000 Hz, it should produce a single, vertical line, since 48000 / 1500 = 32, so the sine wave gets repeated exactly once every 32 samples. This is what I get from the FFT, foobar's visualization, and Winamp's MP3 decoding plugin. However, the visualization Winamp uses for WAV files and other stuff displays absolutely nothing at all. I feel like I missed something.
pineapples10
Mar 25 2004, 19:56
thanks...I got it to work..only now I have a large problem. After playing for about 2 mins with Milkdrop on fullscreen, my computer freezes! Ive tried this both in Winamp and Foobar, and it hapens with both....nyone have any dea what the problem i?
Hmm, that's kinda weird. You might want to look at updating your video card drivers or upgrading DirectX if you have a really old version. I suppose it could also be a corrupted Milkdrop installation. Do you have any issues with running 3D games or other visualizations like AVS?
NEMO7538
Mar 26 2004, 16:00
I have this error at step 8 :
INFO (foo_out_dsound_ex) : Created stream: 44100Hz 32bps 2ch
INFO (foo_vis_bacon) : Attempting to load bacon\vis_milk
ERROR (foo_vis_bacon) : Couldn't load DLL
Edit : Seems to work now. I just reselected milkdrop in the combo box (which I did'nt do first time because they were positionned to MilkDrop by default, it's the only one plugin I have)
Yeah, the reselection thing is a bug I keep forgetting. I need to take a look at each step of the plugin selection process sometime. Sorry about that.
NEMO7538
Mar 27 2004, 02:29
QUOTE(bleh @ Mar 26 2004, 02:27 PM)
Yeah, the reselection thing is a bug I keep forgetting. I need to take a look at each step of the plugin selection process sometime. Sorry about that.
Small bug .... Thanks anyway for the plugin. I'm not a vis addict but Milkdrop is nice !
Plugin urpdaetd.
BinaryMSVCR71.DLL (put this in the same directory as foobar2000.exe if you don't already have it; it doesn't get updated)
SourceWhat's newish:
- Undid idiocy in the changes I made to the spectrum last time. However, the spectrum still doesn't look anything like the one in Winamp, mainly because Winamp's spectrum is weird.
- Set up embed windows so they get created big enough to have a client area of the size requested by the Winamp plugin. Weirdness: I'm not sure Winamp 5.02 does this :|.
- Handling of flushes is now configurable: People who like responsiveness can have visualizations killed immediately, people who run visualizations like R4 that take a million years to load can have the vis stay open on flush, and the delay option is still present. The delay before vis-killing is also configurable to between 0 and 30 seconds.
- If you switch directories for plugins, the first plugin to show up in the list should now be the one configured to use, so issues with having to select plugins to make them work should be gone.
- Due to the surprising number of plugins with weird SDK versions, I've added an option to load any of them. This is technically a bad idea, but it's needed to load Startle, Tripex, Space, etc.
- Slight code reorganization... bugs may have gotten introduced in the process. Please test the hell out of this.