Only fairly basic work done so far. Hoping to build AVS objects one by one and fill the gaps. What is working currently:

Very Basic Effectslist

OnBeat Clear

Mostly working Superscope

Dynamic Movement

Fadeout

Simple 3x3 Convolution

Image loader

Basic avs expressions. with avs expression to javascript/glsl parser

Presets are defined as JSON.
The demo loads a soundcloud track and runs the animation in the background.
Paste a soundcloud track url (or use the prefilled value) and hit "Play".
You can edit the JSON and hit "Run Preset" to reload it.

That said, this doesn't work in firefox as it spews a lot of security errors. (I assume it's due to cross domain file access)

I also broke it when I copied over some DM code from a jheriko preset. (I was using chrome)

But cool nevertheless.

Yeah there are some problems with firefox, for me it throws "HTTP "Content-Type" of "audio/mpeg" is not supported." so i was guessing it was some codec issue.

Yes the expression support is pretty basic right now. Only simple trigonometric and math functions are supported. Could you give me the DM code/Preset that broke? will be helpful in debugging.

The way im going about right now is picking Presets starting from simpler ones and then try to implement AVS objects and or make improvements such that they run on webvs. It will be useful if anyone can suggest some simple presets to work with.

Firefox supports system codecs now, I guess it's not supported on your system then.(Here's the bug for it, and you can quickly check what browsers support on your machine with the html5test)

Just testing a superscope now and the rand function is wrong, it should return an integer.
This should fix it:

code:return Math.floor(Math.random() * max) + 1;

Adding a randf function might be nice, in the future.

I've been out since I tested this earlier and I can't reproduce the error I had (it was function overloading related), so I wouldn't worry about that for now.
(It was the DM from the bottom of Jheriko - Pack VIII - Tachyon Based Data Hub)

For simple presets, winamp used to ship a pack called "newpicks", these presets are pretty ancient in AVS terms.
I've attached it for your convenience.

if only the format of avs was more understandable, would love to contribute a conversion tool

That is a brilliant idea, will be really useful, for debugging also.

I was checking the AVS cpp code to see how the files are read/written. Here is what i've understood so far, if its of any help to anyone. Will need more help from someone with better understanding of the code.

The basic preset reading starts at __LoadPreset method in r_list.cpp. From there it goes on to read a root effectlist, and subsequently all the effects in the preset,

The basic structure is something like this:

AVS Signature string - "Nullsoft AVS Preset 0.2\x1a"

Root Effectlist Config - Effectlist config contains the following

mode (1 BYTE + 1 optional INT depending on the value of the first byte) - Not exactly sure how this is used. but i think it determines how some of the effectlist settings are read.

several INT values containing effect list settings. These i think are optional depending on the mode

config data for all sub effects

The structure for each effect including effectlist (other than the root) is as follows.

EffectId INT - This indicates the effect type. There are three cases for this

if EffectId == LIST_ID (0xfffffffe) then this is an effectlist

if EffectId < DLLRENDERBASE (16384) then this is a built in effect and EffectId is the index in the effect initializer declarations ie. DECLARE_EFFECT calls in rlib.cpp.

if EffectId > DLLRENDERBASE then i think the effect is loaded externally. The EffectId in this case is followed by a 32 byte string identifying the effect.

Length INT - Length number of bytes that follow make the config for this effect.

Config Code (Length BYTES) - This data i think is passed to load_config method of corresponding effect classes to initialize each effect.

Further, for externally loaded effects, it seems that the Config Code Section again has a structure like

use_code INT - Not sure what this means exactly.

length INT - number of bytes of config data that follows.

actual config data?

Meanwhile, on WebVS side, i ve added more stuff

More Effects

Blending related stuff

Support for Registers and more avs functions

The demo now runs UnConeD's "Silk Strings" preset.

Not sure how far i can maintain compatibility with AVS. I am also adding some improvements, like

Named global vars - variables starting with @ symbol are global.

clone - Effects can contain a clone parameter, an integer that would create multiple instances of the same effect. The clone index is then available as a variable in the avs expressions.

Webgl/shader stuff is alien to me, so I've started working on an editor for this.

Here's a screen shot of how it currently looks:

The idea I have for this is that besides the main editor (Which is resizeable), you can pop out effects into their own window.
It should also allow for the visualisation to be shown in the page background, or in a window.
And in an ideal world you'll be able to drag & drop avs presets on to the window to load them.

I'll post a link to it when it starts getting usable.

I don't have WebVS running locally because I don't have whatever is used to build it (I assume it's node), so there is no integration with that currently.

Webgl/shader stuff is alien to me, so I've started working on an editor for this.

Here's a screen shot of how it currently looks:

The idea I have for this is that besides the main editor (Which is resizeable), you can pop out effects into their own window.
It should also allow for the visualisation to be shown in the page background, or in a window.
And in an ideal world you'll be able to drag & drop avs presets on to the window to load them.

I'll post a link to it when it starts getting usable.

I don't have WebVS running locally because I don't have whatever is used to build it (I assume it's node), so there is no integration with that currently.

This looks really nice. Is this is a standalone desktop tool?
I have also put together a somewhat basic HTML5 UI that could replace the textbox in the demo.

Here is a screenshot of what it looks like:

Somewhat basic stage right now, please check the code, i have put it on a separate branch on the repo (https://github.com/azeem/webvs/tree/editor).
The UI is pretty much similar to AVS itself. Popout and Drag and Drop are great ideas, the visualization can be played in the background, just like the demo we have right now.

WebVS uses grunt for building. You need to have nodejs, npm and grunt installed.

Clone the repo and run

code:npm install

This will install all the build tools.

To build, i run

code:grunt

.
This will generate all the files in the build directory.

To test, i run a simple http server in the repo directory with

code:python -m SimpleHTTPServer

and hit localhost:8000 in the browser.

Also, if you run

code:grunt watch

it'll run a continuous build, whenever you save files it'll regenerate, so you just have to refresh the browser.

A more ambitious idea is to have a WebVS editor + Gallery kind of site.
Where users can create, save, share, rate, view and fork presets.
Something similar to http://sketchpad.cc and the likes, but for AVS presets.
Thats still a long way though :P

i did a pull request on github in which i added working cdn links for codemirror and jquery. also, the (current) editor is now draggable.

haven't figured out your soundcloud code yet, but i think it'd be great to have support for playlists as well. also, i tried adding an option to hide the fps counter through a url parameter (e.g. "?showfps=false"), but i don't even know how the html source is generated.

webkit/bink based browsers:
- works in chrome
- doesn't work in chromium (no sound)
- doesn't work in opera 5 or opera next (no sound)
- doesn't work in safari (no sound, no visual - just the editor)

i also noticed that when i edited the default soundcloud track in the demo, a second instance of the track started sometimes (in particular with this track, others worked fine). when reloading the page, i sometimes experienced chopped sounds.

since the actual html of the demo seems to be rendered the javascript, it would be nice if you could put the un-minified files on github. reading one-letter variable names can be very confusing.

i played around a bit more with the editor and there are a couple of things i'd like to add. however, i would like you to explain a couple of things first.

1. is demo.min.js what a preset file would look like or is it a combination of the preset (as json) and some extra stuff?

2. i tried to add the code from the codemirror theme demo to the editor, but i'm not sure how that editor works. the input fields are being displayed a pre tags, not input or textareas. i think it would be a nice option to be able to change the theme of the syntax highlighter.

3. what else is codemirror doing than providing the editor with syntax highlighting?

Thanks for the changes you've submitted. The url param idea is cool. An interesting hack would be to encode the entire preset as base64 and accept it as a urlparam. This would allow us to share preset code as well in the url.

Quote:

Originally Posted by Yathosho

i played around a bit more with the editor and there are a couple of things i'd like to add. however, i would like you to explain a couple of things first.

1. is demo.min.js what a preset file would look like or is it a combination of the preset (as json) and some extra stuff?

I'll try to explain the basic structuring of the code in the repo.

/js - This contains the main WebVS library. I have designed things around a core visualization library. This is pure JS, just few dependencies. Essentially anyone can plug this library into any application, create a webvs object with proper options and start playing visualizations.

/js/core.js - This file contains all the base stuff including the base webvs object and base classes for all the components.

/js/** - All other files have one effect component or contain utility classes and stuff

/test/** - this contains just some very basic qunit test cases, for the expression parser mainly.

/demo - This contains the demo app that i have hosted at url

/demo/demo.js - This code runs the demo app with the editor and stuff. It uses the webvs library. This code contains a hardcoded preset, which is shown in the editor.

when you build the code 1.) all the webvs library files are assembled into one js file 2.) most of the other stuff are just copied into build directory, so you can run the demo from there.

when you build the code with "grunt dist". It generates all the same stuff in dist directory, but with minification. Its this dist directory that i have put on the demo page.

Quote:

Originally Posted by Yathosho

2. i tried to add the code from the codemirror theme demo to the editor, but i'm not sure how that editor works. the input fields are being displayed a pre tags, not input or textareas. i think it would be a nice option to be able to change the theme of the syntax highlighter.

3. what else is codemirror doing than providing the editor with syntax highlighting?

I do not know what could be the scope of the JSON editor based UI. I am working on the an AVS editor like UI, which should be much more simpler to use. The JSON format was meant to be a structure consumable by the WebVS library.

I would like to push the editor UI out into master and use it as the main app. Please take a look at the code in /editor in the editor branch.

Thanks for the changes you've submitted. The url param idea is cool. An interesting hack would be to encode the entire preset as base64 and accept it as a urlparam. This would allow us to share preset code as well in the url.

quick and dirty loader that reads preset files from a directory. i won't be able to refine this before later tonight or tomorrow. it currently only works after the second selection (applying the first) and it currently appends an editor window to the bottom. will get there eventually, but if someone wants to post suggestions in the meantime...

ps: i previously reported simultaneous tracks playing at times, i guess that can be caused when using multiple editors

okay, since i shared that terribly miserable loader prototype, i not only travelled 50km by bike, i also gave webvs a little thought.

1. webvs as a service
the loader is the first demo that relies ln the usage of a server-side language, namely the immensely horrible php scripting language. the script populates the dropdown menu for the presets. would i be fluent in cool languages like python, i wouldn't have taken such matters, while rails wasn't applicable as a quick solution. anyway, clear is on thing: webvs can run online and certain stuff will have to be done dynamically on the server side.

2. webv as an app
one would want to avoid duplicate work wherever possible. the combination of modern javascript and html5 enables webvs to run on all platforms that provide modern browser technology. since the current version of webvs runs on google chrome only (bizarrly other webkit browsers are not supported), i think it's worth thinking about using nodejs as a platform to deploy webvs on the desktop. this would eliminate the need of a variety of languages and little to no adjustments to let webvs run on the server or locally. that said, i probably should have populated the afforementioned preset dropdown using javascript.

so far i have enjoyed playing around with the available code, especially to test out what could be done on the frontend. i'm not particularly happy about the use of codemirror, as it seem a bit over the top for a rather simple task. also i'd prefer using real html textareas in the editor. regarding the syntax highlighting, there are several simpler solutions in the form of javascript. also, i'm not too happy about the current state of modules. things should be kept simple and modular, the current demo.js contains both the presets plus some additional code.

what are your plans for webvs' future regarding the scale of avs-compatibility and how do judge the level of accuracy? what are your plans regarding web platform and desktop deployment?

i think i will rebuild the frontend from ground up, replacing the editor library with something simpler, then add support to load (and later save) presets. i will then think about how to run server-side code on the nodejs platform. (did i mentioned how extremely well nodejs performs multithreaded?)

for the future, i could see some great ways to integrate music playback. besides soundcloud, other audio and video platforms should be integrated, interacting with all the user features (favourites, libary) that platform offers. needless to say, local music playback should be supported as well, again including library capability and favourites from popular players.

so far the code is mostly clean and modular (apart from demo.js), so i think if somebody doesn't agree with my ideas for the ui (or simply prefers the classic avs editor approach qoal has taken), the ui part should be kept just as simple as the rest of the plugin. users should be able to install and select a various frontend themes. the webvs core should make it easy for such third party addons to use a variety of libraries (in a similar way jsfiddle offers jquery, mootools etc.). syntax highlighting should be optional from the frontend decisions (though a theme could override that), providing a variety of userstyles in a seperate library. most of the javascript highlighting solutions i prefer over the current editor (i.e. enlighter, highlight.js etc.) already support a variety of highlighting themes.

okay, since i shared that terribly miserable loader prototype, i not only travelled 50km by bike, i also gave webvs a little thought.

1. webvs as a service
the loader is the first demo that relies ln the usage of a server-side language, namely the immensely horrible php scripting language. the script populates the dropdown menu for the presets. would i be fluent in cool languages like python, i wouldn't have taken such matters, while rails wasn't applicable as a quick solution. anyway, clear is on thing: webvs can run online and certain stuff will have to be done dynamically on the server side.

This is definitely a good direction, this is precisely what i meant by the "webvs gallery + editor site". I was hacking around with a little bit of https://www.firebase.com/ to getaway with having to write serverside code, though having a server side backend does sound more robust.

Quote:

Originally Posted by Yathosho

2. webv as an app
one would want to avoid duplicate work wherever possible. the combination of modern javascript and html5 enables webvs to run on all platforms that provide modern browser technology. since the current version of webvs runs on google chrome only (bizarrly other webkit browsers are not supported), i think it's worth thinking about using nodejs as a platform to deploy webvs on the desktop. this would eliminate the need of a variety of languages and little to no adjustments to let webvs run on the server or locally. that said, i probably should have populated the afforementioned preset dropdown using javascript.

Browser compatibility is a bit rough right now, I'll need to find some time to fix this. I havnt thought about this possibility of running webvs in node. This should be possible theoretically. However state of webgl support in headless browser kits or projects like node-webgl seems limited, need to investigate.

Quote:

Originally Posted by Yathosho

so far i have enjoyed playing around with the available code, especially to test out what could be done on the frontend. i'm not particularly happy about the use of codemirror, as it seem a bit over the top for a rather simple task. also i'd prefer using real html textareas in the editor. regarding the syntax highlighting, there are several simpler solutions in the form of javascript. also, i'm not too happy about the current state of modules. things should be kept simple and modular, the current demo.js contains both the presets plus some additional code.

demo.js was a small hack that i put together to test/demonstrate the library. I just kept adding some smaller changes to it. Never meant it to be used as a real editor, IMO its rather cumbersome to edit avs expressions inside the JSON since they are quoted as strings.

Quote:

Originally Posted by Yathosho

what are your plans for webvs' future regarding the scale of avs-compatibility and how do judge the level of accuracy? what are your plans regarding web platform and desktop deployment?

I am trying to build components one by one, eventually i hope we'll get to a point where a good number of presets can be supported. As for accuracy, results look pretty good so far, There are a lots of issues and loose ends, like eg. the color of unconed's silk string preset is somewhat messed up, the movement is very shaky compared to AVS and so on.

Quote:

Originally Posted by Yathosho

i think i will rebuild the frontend from ground up, replacing the editor library with something simpler, then add support to load (and later save) presets. i will then think about how to run server-side code on the nodejs platform. (did i mentioned how extremely well nodejs performs multithreaded?)

for the future, i could see some great ways to integrate music playback. besides soundcloud, other audio and video platforms should be integrated, interacting with all the user features (favourites, libary) that platform offers. needless to say, local music playback should be supported as well, again including library capability and favourites from popular players.

z33m: you started a fire!

Quote:

Originally Posted by Yathosho

and one more idea:

so far the code is mostly clean and modular (apart from demo.js), so i think if somebody doesn't agree with my ideas for the ui (or simply prefers the classic avs editor approach qoal has taken), the ui part should be kept just as simple as the rest of the plugin. users should be able to install and select a various frontend themes. the webvs core should make it easy for such third party addons to use a variety of libraries (in a similar way jsfiddle offers jquery, mootools etc.). syntax highlighting should be optional from the frontend decisions (though a theme could override that), providing a variety of userstyles in a seperate library. most of the javascript highlighting solutions i prefer over the current editor (i.e. enlighter, highlight.js etc.) already support a variety of highlighting themes.

I agree with this, any larger UI/Frontend work is big project in itself with lots of dependencies, it is nicer to keep the webvs core library simple.

Sadly I got fed up failing to code recursive drag & drop for the tree list, that coupled with depression and not wanting to fix the small css issues outside of firefox (so frustrating that after all these years there are still miss matches between browsers, even with css3 stuff). (I may fix them at some point)

I didn't get around to adding the pop-out windows, it would be a little ↗ icon on the right hand side, opposite the element label.

Anyway, I'm sure the code is ghastly for others to see, but it doesn't use any external libraries.

I was checking the AVS cpp code to see how the files are read/written. Here is what i've understood so far, if its of any help to anyone. Will need more help from someone with better understanding of the code.

The basic preset reading starts at __LoadPreset method in r_list.cpp. From there it goes on to read a root effectlist, and subsequently all the effects in the preset,

The basic structure is something like this:

AVS Signature string - "Nullsoft AVS Preset 0.2\x1a"

Root Effectlist Config - Effectlist config contains the following

mode (1 BYTE + 1 optional INT depending on the value of the first byte) - Not exactly sure how this is used. but i think it determines how some of the effectlist settings are read.

several INT values containing effect list settings. These i think are optional depending on the mode

config data for all sub effects

The structure for each effect including effectlist (other than the root) is as follows.

EffectId INT - This indicates the effect type. There are three cases for this

if EffectId == LIST_ID (0xfffffffe) then this is an effectlist

if EffectId < DLLRENDERBASE (16384) then this is a built in effect and EffectId is the index in the effect initializer declarations ie. DECLARE_EFFECT calls in rlib.cpp.

if EffectId > DLLRENDERBASE then i think the effect is loaded externally. The EffectId in this case is followed by a 32 byte string identifying the effect.

Length INT - Length number of bytes that follow make the config for this effect.

Config Code (Length BYTES) - This data i think is passed to load_config method of corresponding effect classes to initialize each effect.

Further, for externally loaded effects, it seems that the Config Code Section again has a structure like

use_code INT - Not sure what this means exactly.

length INT - number of bytes of config data that follows.

actual config data?

Meanwhile, on WebVS side, i ve added more stuff

More Effects

Blending related stuff

Support for Registers and more avs functions

The demo now runs UnConeD's "Silk Strings" preset.

Not sure how far i can maintain compatibility with AVS. I am also adding some improvements, like

Named global vars - variables starting with @ symbol are global.

clone - Effects can contain a clone parameter, an integer that would create multiple instances of the same effect. The clone index is then available as a variable in the avs expressions.

Hello again,
the Decoder is basically done - and I would appreciate some help hacking apart the various effects that are available.
It'd be great if some people would pick apart some of the many basic built-in "checkbox/slider/number/color"-type of effects.
Read https://github.com/grandchild/AVS-Fi...s-file-decoder

I'll be mostly doing APEs for now because those might require some slightly deeper digging and function writing in the code...

wow. lot of cool stuff. Ive been off for a little while, and AVS forum stopped sending me notifications for some reason.

Been working on some major refactoring (https://github.com/azeem/webvs/tree/refactr) of webvs core code. cleaning up lot of the shader code and internals. Also writing some tests. I guess these changes + other fixes etc. can be put together as the first numbered version. I will write some detailed documentation or maybe a blog post about the internal wirings and how to write Effect components, would like lots of help on this.

I have separated out the editor UI project into a separate repo (https://github.com/azeem/webvsed), the webvs library contains only the core library, the examples directory contains individual examples and tests.

Also checkout https://github.com/rogerwang/node-webkit this is an awesome platform. Its basically nodejs+stripped-down-chrome that allows javascript applications to work standalone and it supports webgl too. I was able to quickly put together a standalone version of webvs that works on the desktop. This IMO is super exciting.

Also working on the firefox issues. FF 24 release supports mp3 so the streaming issue is fixed, meanwhile some other problems have cropped up with dancer.js. Either ways webvs uses an adapter to interface with audio, so im thinking of looking at a more reliable audio library like using the flash support with soundmanager2 or something. Need to look at the beat detection also. The one in dancer.js is not very good.

wow so much awesomeness. This is really brilliant. Also, presently, avs presets and webvs preset are not a one to one map. so we might have to do some preprocessing in between, to make the output work directly.

Quote:

Originally Posted by Yathosho

what's wrong with the forum or github? the big shortcoming of irc is that everybody needs to be online all the time to be able to follow the discussion.

I agree, forum is better. Particularly for me, i think my timezone is 5+ hours ahead of most of you guys, been hanging out at the avs irc channel for sometime but rarely see any activity because of this. Having to put all discussion under one thread is getting a bit hairy though.

Can any explain the difference between trans/Movement and trans/DynamicMovement internally. In Webvs ive written only a dynamicmovement effect, i thought movement is equivalent to dynamic movement with the code inside perpixel. However some effects look significantly different.

Im going crazy trying debug this, getting weird artifacts in some cases. Could be because of difference in floating point calculations in webgl vs all integer calc in avs.

Also coudnt find trans/movement code in the avs source. Found dynamic movement code in r_dmove.cpp.

@azeem: Yes, have a look athttps://github.com/grandchild/AVS-Fi.../components.js
and its comments, there is every source file as a comment behind the name, and every now and then i wrote the ranges or even the formula i saw in AVS or in the source code behind the fields.