Xion Community

I propose the following:

To be able to define what visualization plugin the skin should use, and to some extent, possibly alter it's settings.

I know it sounds really dictatorlike, but give me a moment to explain.

With the addition of the new visualization mode, the bars, making them got a whole lot easier. We have a full range, fully dynamic and great looking bars at our disposal. They look epic on our skins we've designed with those in mind. But here's the problem -- Somebody else might not be using the bars visualisation, but something else ( Which is VERY likely once other, Winamp's MilkDrop-like, or 3D vis plugins arrive ), and it makes the skin look awkward with it.

How to fix that? Well, that's the thing. Forcing people to use a specific plugin sounds trivial in itself, but on the other hand, the entirety of the skin is designed by the author, so why not allow the author be in charge of what visualization to show where he/she intends?

Technical solution:

Add keywords to the visualization layer that allow defining of the plugin and mode

Code: Select All Code

visualization default(spectrum) randomcolor noblur peaks

If the plugin that is defined is disabled, it should default to what the user has specified. If necessary, add an option to the global Xion settings to ignore all visualization keywords. That should provide the best of both worlds.

For a clear of example of why i'm asking for this, take a look at [url="http://xion.r2.com.au/index.php?page=skins&id=591"]Blackbird[/url], and fiddle around with the visualization settings. You'll notice that while it doesn't really matter what the settings are, it looks best if you set it to use the spectrum analyzer, with no color changes and no blur. Imagine if you were to try using a 3D vis plugin in that tiny space. The results would be rather tiny, or impossible to view.

So, whatdya say?

I can't think of a good way to set this up to allow for future expansion at all. The visualisation layer is supposed to be for visualisation plugins to render themselves into. As I've said many times in the past, I anticipate 3d plugins. I even expect support for Winamp, WMP, etc plugins. Visualisation Plugins will be able to render whatever they like in there.

There's absolutely no way I can have skin support as you suggest for each and every plugin. Imagine just trying to support AVS from Winamp!

Instead, what I suggest you do, is to use the visualisation layer as it was intended. Make it large enough so that no matter what plugin the end user chooses, it will at least be visible.

If you want more skin specific visualisations then use the VUmeters or the Animation layers. I'm thinking of adding more FFT data than just the Bass/Mid/Treble.

This way, if you want to have your skin specific visualisations you can. It will also allow the user to use the Visualisations that they want to use as well. (as long as you support a visualisation layer in your skin)

The idea of the options in the visualisation plugins is for the user to customize them to how they like, not to have the options forced by the skins. It's the same reason you provide multiple colours in skin files, you want the user to have choice.

If you find the current Bass/Mid/Treble, Left/Right/Center FFT data too limiting, then do request more, but what you've requested here won't be happening due to the infinite options that will become available soon.

Yes, there are two options now, but in the near future, I hope to change that with plenty of Visualisations available for the end user to choose from.

Cliff

How much FFT data do you think you could fit in, in that case?

Along with that, we'll probably have to figure out how to do decent peaks somehow, too.

Guess i'll make a new thread then.

I'm not saying you'll be able to reproduce what you see in all visualisation plugins, far from it. However I am saying you'll be able to build some custom visualisations that way, in addition to allowing the user to use their own with the visualisation layer. Essentially you will use the Animation layer sets that then respond to the audio data, similar to how you can now, just with more audio data to respond to.

Cliff

Well for my skin 'YABXS' I utilize JUST the line one (not the bars) intentionally as an element behind the progress bar.

also utilize the same idea in 'XSe7en' but its behind the buttons to be like an animated background kinda thing and this is fine with the bars or any kind of 2D vis.

So I propose that the plug-ins be separated and optional separately to keep bloating down.

Like Line scope, Oscilloscope, 3D types, AVS...all downloaded separately as different plug-ins and loaded separately depending on keyword that the plug-in can specify...

For example: Make a plug-in like 'Visualization 3D' and in that have a code that specifies the name (name="Vis3D") and in photoshop have something like "visualization ('Vis3D')" as a layer name and it will check for a plug-in in the Xion>Plug-ins folder on the system named Vis3D...

Now you might ask "What if they want all of them by clicking on the visualization and how this would effect current skins?"
Answer: if the layer name is "visualization" it will act as it does now the way your intending it Cliff. It will default to load all Plug-in's on start and cycle through them on click...this way the user has full control over what exact vis plug-ins to expect when cycling them AND the skinner can either specify a specific vis plug-in or have the default Or even have a custom button to switch between the two which would already be possible with modify() and id()...

Hows that sound for an idea?