Hi,

An extension for the new version of ui_columns would be cool and also a foobar version of projectM would be good (when the windows source is available)

Cheers

Um, well, I mostly forgot about that one, so progress would be... zero. Damn.

I guess that would be something I could consider actually developing in the future.

It'd be hard to do as I'd have to find some way of forcing any window created by a Winamp visualization plugin into the panel. It may be possible, but I'm not sure; I'll have to browse the MSDN docs sometime and see if anything looks promising. You were asking about a panel containing the visualization, right?

Yes, a native version would be extremely good.

Yup, that's what i meant. I think alot of people will see it as being extremely cool.
Technically it might be possible... doesn't Winamp5 do something similar with having the VIS integrated as part of the GUI albeit skinned?

Yes, but only if a visualization specifically tries to embed itself into the Winamp window. Most older plugins make their own non-integrated window and that would kill the idea of having the vis go into the panel. What I'm wondering is whether it's possible, using ordinary Windows API calls, to shove any window created by the visualization into the panel space.

EDIT - In addition, I'd have to figure out how UI extension plugin is supposed to get the visualization data. That's something on which I'm not too clear.

well I'd be happy if you manged to just get the newer plugins that embed themselves into the gui to work as a panel.

good luck!!

okay so i downloaded this bacon plugin, and i put it in my components folder, and when i click the BACON option in the vis part of the components toolbar, i get a message that says 'visualization manager not present, please reinstall'

i do not know what to do from here

Did you put msvcr71.dll in your foobar2000 directory?

When you installed foobar2000, support for visualizations was not included or you somehow lost the foo_vis_manger.dll component. Reinstalling foobar2000 should fix this.

poke.

foo_vis_ham is effectively dead. I tried hacking something together really quickly just to see how it would go and Aorta ended up being slower than Synaethesia in foo_vis_bacon. Also, Smear displayed the same issues with paths that Synaethesia did (everything has to be in a specific place relative to the executable or it crashes), which kind of kills it since that's one of the big Sonique visualizations. I may make a page for getting Synaesthesia to work with foo_vis_bacon instead.

foo_vis_bacon - Nothing much planned in the future pending a rewrite or a big cleanup, since I can't remember exactly how all of my badly-named variables for signaling things across threads were supposed to work and that annoys me. However, looking at how things worked again did make me think of a question which I thought was interesting enough to be worth the thread bump:

Would it terribly offend anyone if the framerate specified in the Winamp plugin configurations were ignored and the framerate specified in the foobar2000 visualization config were used instead?

Not at all, I thought it did that already :s

Kind of... the data gets updated at the speed set in foobar, but the plugin gets told to render at the rate it specifies, which leads to asynchrony. I thought I'd fixed it, but I really didn't and I can't think of any feasible ways of getting around the problem. Anyway, thanks for supporting the easier-to-implement solution.

I support this solution, too. Heh, now that there are three of us no one can stop us.


Did you now that Xmplay has build in support for Sonique Visualizations?
Xmplay users asking for Winamp Vis-plugin support since quite a long time. Ian, the author of Xmplay, seems to be not very interested since he does'nt like Winamps Vis-plugin structure (he looked into it once).

Conclusion:
¯¯¯¯¯¯¯¯¯
You have something he might want, he's got something you might want.
How about getting in contact and talking about possibe exchange of sources?

You can pay his site a visit here: XMPLAY Homepage

Regards, deus-ex.

Thanks for the suggestion, but it doesn't quite work like that, unfortunately.

• Even though I was able to get Winamp visualizations to mostly work with foobar, some of them are glitchy or crash for no apparent reason.
• If Ian doesn't like the way the Winamp visualizations are structured, then the fact that it's possible to wrap them in a foobar2000 visualization isn't going to change that; in fact, I don't even like how Winamp visualizations work.
• I don't know how XMPlay's architecture is structured, but depending on how different it is, what I've learned from developing foo_vis_bacon may be of no use to him.
• I have no interest in maintaining another visualization wrapper after my experiences with foo_vis_bacon - I'm in the process of rewriting it because the way I had things structured before got too convoluted and I have no idea when I'm going to get done. I suspect Ian has no interest in maintaining two separate visualization wrappers, either.

Hi! Good to see some action over there Back from holidays, huh?

Some remarks about what has been said recently.

About the integration of visualizations within the player, I must say I'm rather against this idea. Except for tiny components that could replace the little spectrum viewer or waveform viewer in a small window a few dozen pix wide, I don't see the point. If you want to enjoy a nice vis with a lot of effects and stuff, chances are you will use a rather large window (not necessarily the entire desktop, but at least say a third of it or more). In this case, the 'integration' is gone, from a skin/appearance design point of view. Branding the title bar and borders seems artificial to me. But that's just me

As to how to force a window into the player, I was thinking about that myself when I wrote my plugin. I don't think it's practically doable. You probably would have to override the window style (what if the plugin creates a popup style window? an overlapped window? a toolbox window?). Plus you would have to intercept messages, and redispatch. SIZE and MOVE messages come to mind. If the plugin does unexpected things in response to these messages, you're in trouble (well at least the nicely integrated visualization is).

About the status of the bacon thingy , I was willing to take a look at the source some time in the future, specifically to tackle the speed issue I mentioned earlier. Now I'll wait for the clean, easy-to-read rewrite Seriously, the few tidbits given recently more or less give me an answer on this subject.
I'm currently working on my next plugin, and I am not terribly offended by the framerate being set by the bacon. In fact, it won't matter that much.
I was wondering if there was a point releasing a native version for foobar2000 if the winamp version works with the bacon. I have absolutely no idea how the foobar SDK looks like.

Never left; I'm just lazy.

Yeah, that's basically the gist of it. I still haven't getting around to seeing if this sort of thing is possible, though, because I'm still not sure what the best way to make visualization panel is.

I thought minus0.29 was up to par speed-wise. I didn't notice much of any difference, at least.

It hasn't turned out any cleaner or easier to read, it just splits things across more files so it's easier to ignore the really ugly stuff as long as nothing needs fixing. I ended up reusing more code than I expected, too.

Actually, you probably wouldn't care too much for the rewrite as it seems noticably slower. I'm not sure exactly what the reason for this is yet, but I'm putting off another test release until I can figure out what did it. The really annoying thing about this is that the way I changed things, a few plugins that wouldn't disable themselves when their windows were closed with previous versions suddenly cooperate and work normally, so if I go back to the older, faster method, I lose some stability.

A native version would definitely be better from a usability standpoint as people wouldn't have to sit and wait forever for foo_vis_bacon to scan their plugin directory just to change the texture settings or something. It's also likely to be more stable. The main difference you would have to adapt to going from Winamp to foobar is that you have no control over the number of waveform and spectrum samples you get at any given time; you just have to figure out some way of working with what you get. Also, the latency reporting function is kinda counter-intuitive - it expects a negative return value.


EDIT: I've figured out why the new version seems slower (like 20 fps in foobar vs. around 70 in Winamp). To convert from the data foobar gives me to the data Winamp expectes, I have to run a 1152-point FFT to get the 576-point spectrum, then convert the spectrum and waveform data from floating-point to char, which means 2304 conversions if the audio output is stereo. This takes a while. With the revision, the Winamp plugin is told to render only after this is done, so the Winamp plugin rendering is very CPU-limited; with the old version, the Winamp plugin didn't care if the data it was getting was remotely up-to-date as long as it got to draw stuff on time. foobar2000 will tell visualization plugins to skip over data if the previous stuff got backed up, so the old version was probably updating the actual data only around 10 or 15 times per second even though the plugin got to render a lot more.

So it looks like I'm going to have to play the workaround game.

Sorry for the double post, but you know, when you start coding before you've completely decided on a given implementation, your code picks up nice little gems like this:


Mirage gets 40 fps now when tied to the data from foobar and about 70 fps when I decouple it, and for some reason, Eonic and Tripex aren't being asinine about closing their windows anymore even with the rendering decoupled from the data, so I may just continue letting the data be out of sync. Now that I think some more about it, that's probably how Winamp does it, since the visualization data is added 576 samples at a time by the input plugin.

Nice find

I think you're spot on regarding how Winamp works. I thought about it some time ago. 44100 samples per second / 576 samples per buffer = 76.5 buffers per second. If your getting any faster than this, either you sometime get the same buffer several times in a row, or you get partially updated buffers. So my guess is the following : whenever the Render() function is called (by the Winamp-managed vis thread), the plugin gets whatever audio data is there at that time. Winamp does not wait until new audio data is available, I don't even think it's capable of partial updates on these buffers, but I'll have to check that to be sure.

foo_vis_bacon minus0.2 is now available for everyone to test and possibly enjoy.

Thanks for the new version!
One thing: When manually changing tracks the plugin leaves fullscreen mode. I think that with the previous version this wasn't the case (not sure though).
I'm using MilkDrop 1.04.

Regards,
The Link

Hello bleh,
checked new foo_vis_bacon minus-0.2. Everythings cool here as with the previous releases. But there's one thing that doesn't work right ever since. As it wasn't fixed with current release i investigated the problem and this is what i found:

This AVS-Plugin Preset, S_Kupers - Spirit Realm (Degnic's Plasmoid Rmx).avs, does'nt look right with foo_vis_bacon. To display its effect it needs an additional binary called "Texer.ape" and an texturefile named "Whacko6-07.bmp". AVS structure has it that files belonging to an Preset are stored in Winamps AVS directory, Presets usually reside in a subfolder in the AVS dir.
When the AVS Plugin runs under foo_vis_bacon the requiered files are not found by the Plugin/Preset and the effect is rendered without them (if possible). To verify i deleted the aformentioned .ape and .bmp file in the AVS directory and ran AVS trough Winamp, which then renders the effect with the same wrong output as foo_vis_bacon does.

In conclusion the solution probably is to set some environment variable storing the path to Winamp or change directory at startup of foo_vis_beacon (loud guessing).

deus-ex

If you have the flush handling set to immediately shut down the plugin, try changing it to use a delay. One second should be fine for most types, but Monkey's Audio extra high seems to need two or three and I don't even want to know about insane. If you do have it set to delay and it's leaving fullscreen, then this is an interesting problem as it's not reproducible on my end.


deus-ex:
I'll experiment with SetCurrentDirectory and see if I can get it to work.

@bleh: hmm...you were right! I had to set it to 3 seconds. I don't think that I had to set it that high in the previous version ... but who cares?
Thanks again!

The Link

3 whole seconds? What kind of files are you playing back?

The files were in the musepack format.
Could it be that the buffer of my output device which is set to 2 sec. has sth. to do with it? Or the usage of the convolver?

To be honest, I'm not sure since I don't have any Musepack files lying around. I was just a little surprised.

Anyway, if it works for you with a slightly higher delay, then you might as well enjoy your present setup the way it is.

Phear no more, redemption is here.
Found this cute little Sonique to Wincrap wrapper, foo_vis_bacon wrapps it again into foobar2000 just nicely. Visual quality and speed is very good and can easily be adjusted, so give it a shot. Plus several cool Sonique Vis classics (Aorta, Rabbit Hole, Cosmic Belt, Acidspunk...) are allready included!

Sadly the authors main page is abbandoned, last life sign is from mid 2002. Links on the site are broken, i webhunt for him was unsuccessful.

deus-ex

Seems to work a little better, though it's hard for me to say because I haven't experimented too much with Synaesthesia lately. If I get a chance to mess around on a computer other than my own, I'll be able to do a better comparison of the two. Thanks for pointing that plugin out.

Also, with regards to that AVS preset that's not working, I'm pretty sure AVS sets the directory of its files to be relative to the path of the current executable. Unless someone knows how to override GetModuleFileName, the only way to get that to work will be to create a directory called, "Plugins," in the same directory as foobar2000.exe, then copy the AVS directory into that one. At least AVS is relatively robust about it and doesn't crash or anything...

Another Winamp Visual, this time a leet spectrum analyzer. Ultra flexible, ultra configurable, ultra fast, ultra sexy.
The name? Sexy Attached Analyzers 1.61a.
I'm providing a profile with it since it is tricky to config the colors. Play around and find out for yourself.

sexy deus-ex

I've actually seen that one. As noted on the list of plugins test with foo_vis_bacon, it's a nice analyzer, but it doesn't work too well with foo_vis_bacon, possibly because there's no window with the Winamp classname and definitely because the parent window for the Winamp plugins is kept from ever becoming visible. The result is that it just kind of sits in the middle of the screen.

Heh, if you give the download including the profile i provided a try you'll see that's not true.
Funny though, i didn't got to see any screen of it with current Wincrap, but it immediately showed up with bacon. Should make you feel proud.

Actually, this sexy thing has three different ways to draw its output screen:
Rightclick in its screen, select "Properties..", then third tab named "Style". On the lower left you'll find "Window" settings offering three options. With "Window" set to "screen" the "Location" option right below becomes active which lets you decide between top or bottom ocation of the plugin screen. Thats what i set up in the included profile.

As i said, Sexy Attached Analyzers is ultra-configurable, then again ultra-confusing to see through all the options.

deus-ex

Ah, you are correct. I will update the plugin list to make it clear that setting the attach mode to something other than, "WinAmp," will allow people to enjoy this exceedingly sexy analyzer.

Also, I may have just noticed a bug in foo_vis_bacon involving switching between modules and possibly plugins while a plugin is currently running. I'll see about getting it fixed as soon as I can figure out how to reproduce it reliably.

EDIT: Bleeeeecccccchhhhhhhh, it crashes if you configure it from the foo_vis_bacon Configuration page while it's running and then hit, "cancel," or shut down the visualization before closing the config window. The problem appears to be that if you configure it while it's running, the call to Config returns immediately after creating the window instead of after the window is closed (how most plugins do it), so there's a chance for the DLL to get freed too early. This will be an interesting problem to resolve as I'd need to figure out some way of knowing when the config window gets closed even though the plugin does nothing to signal it to me. I suppose I could just make it keep every single plugin DLL persistently loaded like Winamp does, but, well, I think that way of doing it smells. Grrr...

[Deleted, didn't check the date]

I just noticed that it's also possible to have the Sexy Attached Analyzers crash Winamp by configuring while the plugin is running, then stopping the plugin. I wonder if I should implement some sort of blacklist system for plugins that act up like this...

Rabidhamster's R4 vis plugin was recently updated to v1.10. It has a revised soundcard detection and an improved beat responsivnes (now user configurable). Startup speed was increased a couple times. Though loading is still not perfect (it escapes me why the plugin loads/scans all including files at startup instead on first demand during runtime) its bearable now, it doesn't take the time to make a cup of coffee now.

IMHO it's the most beatiful and most impressive vis plugin at the moment.

deus-ex

Yes, the new version seems to load within a much more reasonable amount of time. However, it seems his solution for fixing the issue with crashes due to switching between windowed and mode and fullscreen during loading by pressing, "F1," was to unbind the key by default instead of fixing the actual crash. Silly. :|

And yes, I really ought to get going on that blacklist thing. I thought I could avoid the issue with the Sexy Attached Analyzers by hacking around with the way the setup for calling the config dialog works, but then I realized that what I was doing wasn't working and I'm too lazy to unmerge my changes there or to remerge the very minor changes I made since minus0.2. Now I feel mildly ill and close Visual Studio whenever I consider doing any work on it. Bleah.

Sometimes you have to lay things aside for a while and work on something different. Then when you're in the mood to revisit the code often fresh ideas come to mind. Btw., i think "beacon" doesn't deserve to hold the minus in the version number anymore. IMHO it runs pretty well, not only since the latest release.

deus-ex

is it possible to force the plugin window to "Stay on top mode"?

Eg. Milkshape 3D has no stay on top option.

It should be possible for plugins that embed themselves like Milkdrop and AVS because foo_vis_bacon actually creates the window for those. It might be possible for some other plugins, but I need to get a better grasp of how setting the Z-order of an owner window to HWND_TOPMOST affects the windows it owns.

minus0.19 posted with a few plugins blacklisted out, configuration while running disabled for vis_satan.dll, and experimental topmost windowing that doesn't seem to work with everything.

Hi Bleh, I like the plug-in.. do you think it is possible to create a BACON panel to integrate it in foo_ui_columns?

The mockup is based on foo_ui_columns + foo_uie_tabs:
http://mattiasdh.fastmail.fm/Bacon-Panel.gif

I personally think it would rock!

mattias

Yes, yes, that would be brilliant. I'd definitely probably download and use it if it was created...

There are two barriers right now to my doing such a thing:

1. I'm not particularly comfortable with the UI extension SDK. This could probably be changed if I sat down and played with it a little over the course of a few days.
2. I don't know of a good way to make the panel, "absorb," the Winamp plugin's visualization window instead of just letting it float around. There is an API that allows Winamp plugins to embed themselves in Winamp 2.9 and up and I could use it to accomplish the same thing it does in Winamp, but there are only a few plugins that actually use it and I'd feel really stupid working on an extension when I know full well it's not going to work with a lot of the stuff people try.

So, in short, it'd be cool, but I'm not convinced it's doable.

Sorry I can't be of any help, my programming skills go as far as PHP..

What about fooling the foobar Would it be possible to create a borderless window on top of the panel, based on its coordinates? Just thinking out loud...

Cheers
eph

The problem is that, with the exception of recent versions of Milkdrop, AVS, and the Winamp SDK example plugin, foo_vis_bacon doesn't create the visualization window - the Winamp plugin does. What I would need to do would be to change the properties of the window after it's been created so that it fits into the panel, which I'm not convinced will work cleanly and reliably.

some bug report
when i start the visualisation with the Sonique Visual Plugin Wrapper 2.0, then use search playlists, the visualisation will make the search very very slow.

Hrrmm.. I think the logical complement to fb2k would be an entirely separate program.. A program that loaded other vizualizations and sat in the tray. You wouldn't have to worry about the difficultys of a wrapper. You could just get the input from line, wav.. etc. This might have a higher overhead than just 1 process, but hey your going to use it on a vis so what the fuck right? That way you could keep foobar/ winamp api clusterfux0ring to a baseline 0. If you didn't need the viz you could just not load the loader. and if you didn't need foobar.. say you were doing visuals for a party you could use the line in.. Entirely within the realm of possibility and Already been done to a point. But nobody's done ever produced an entirely usable app yet. not even close.. thats whats needed. anyway just my dot oh two.

First, thanks for this component, bleh. I use it a lot!

Second, has there been any more thought on this front, or is it probably not going to happen?

I tried doing it and it worked neither cleanly nor reliably, so I scrapped it. Sorry if anyone was looking forward to this.

Good work on the plug-in anyways, was looking forward to it, but if it is not possible its not possible...

Thanks for the quick reply, bleh. Sorry to hear it didn't work out.