Skip to main content

Topic: Winamp-VIS-plugs in foobar (Read 148741 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • ep0ch
  • [*][*][*]
Winamp-VIS-plugs in foobar
Reply #250
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

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #251
Quote
And what about foo_vis_ham for sonique plugins?
Did you make any progress?
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.

Quote
An extension for the new version of ui_columns would be cool
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?

Quote
a foobar version of projectM would be good (when the windows source is available)
Yes, a native version would be extremely good.

  • ep0ch
  • [*][*][*]
Winamp-VIS-plugs in foobar
Reply #252
Quote
You were asking about a panel containing the visualization, right?


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?

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #253
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.
  • Last Edit: 02 September, 2004, 10:26:07 AM by bleh

  • ep0ch
  • [*][*][*]
Winamp-VIS-plugs in foobar
Reply #254
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!!

Winamp-VIS-plugs in foobar
Reply #255
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

  • p0wder
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #256
Did you put msvcr71.dll in your foobar2000 directory?

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #257
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.

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #258
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?

  • ep0ch
  • [*][*][*]
Winamp-VIS-plugs in foobar
Reply #259
Quote
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

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #260
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.

  • deus-ex
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #261
Quote
...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.
Best regards
deus-ex

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #262
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.

  • dylan¤vp
  • [*]
Winamp-VIS-plugs in foobar
Reply #263
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.

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #264
Quote
Hi! Good to see some action over there  Back from holidays, huh?
Never left; I'm just lazy.

Quote
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).
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.

Quote
I was willing to take a look at the source some time in the future, specifically to tackle the speed issue I mentioned earlier.
I thought minus0.29 was up to par speed-wise.  I didn't notice much of any difference, at least.

Quote
Now I'll wait for the clean, easy-to-read rewrite
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.

Quote
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.
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.
  • Last Edit: 16 September, 2004, 09:47:13 PM by bleh

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #265
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:
Code: [Select]
    for (unsigned int i = 0; i < waveform_samples; i++)
    {
 left_waveform_data.read(left_wave_buffer, waveform_samples);
 right_waveform_data.read(right_wave_buffer, waveform_samples);
    }
    //     >_<;;


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.

  • dylan¤vp
  • [*]
Winamp-VIS-plugs in foobar
Reply #266
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.

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #267
foo_vis_bacon minus0.2 is now available for everyone to test and possibly enjoy.

  • The Link
  • [*][*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #268
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

  • deus-ex
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #269
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
Best regards
deus-ex

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #270
Quote
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
[a href="index.php?act=findpost&pid=243928"][{POST_SNAPBACK}][/a]
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.

  • The Link
  • [*][*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #271
@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

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #272
Quote
@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
[a href="index.php?act=findpost&pid=243948"][{POST_SNAPBACK}][/a]

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

  • The Link
  • [*][*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #273
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?

  • bleh
  • [*][*][*][*]
Winamp-VIS-plugs in foobar
Reply #274
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.