Things I don't agree with...

Combine all the event boxes (OnInit, OnFrame, etc) into one large syntax highlighting editor in which one would write each part as a subroutine. On top of this, try adding a feature so that AVS points out code errors instead of just choking.

If all the event boxes were combined, we would loose backwards compatibility. So for people without the latest version of AVS, the DM, SSC, DDM, etc. would display nothing. I had this problem a while back when DMs were new. I implemented it, and even though the preset was not that great, people complained because it did not work and gave me zero stars. Plus, newbies would be freaked out be the prospect of having to write in subroutines, and there would be many more people asking for help than normal.

On the other hand, I like the idea of the syntax highlighter so it is much easier to see if you have enough parentheses, etc.

amen to that. as much as i don't like the current subroutine boxes, i really don't like the idea of 90% of people who try to watch the new AVS' coming in saying "avs not werkin!! plz hlp!!!1"

I think avs definitely needs some changes (i.e. global variables!!!) but they must be good enough so that it is worth the initial barrage of questions. Of course to lower the number of questions, Winamp could put presets that use the new version in a different section. However, combination of all of the event boxes definitely is a good idea, and although syntax highlighting and error detection would be nice, it could slow up avs even more.If only I had a P4 3.06Ghz...

AVS Could be written to load older presets into the new subroutine structure. Perhaps if the version is 26 or lower, use older load method. (Current version number listed in AVS files is 26)

...no, it's 2.5(.1).

Combination of all syntax boxes would be incredibly annoying IMHO because then you lose the ease of things like "on init, do this and this and this" in just one text box. Instead you'd have to do it like NSIS;
Function .onInit
n=576; tpi=acos(-1)*2;
FunctionEnd
It's just one more thing to remember, and it's just one more thing AVS would have to look for in real-time.

AVS syntax highlighting would be calculated, if the AVS techies are smart enough, only when the code is changed - and it would only be displayed (and therefore held in memory) when the coded window is displayed. So it would only slow AVS down when you're editing the code - no more of an annoyance than Trans / Movement's lag when the code is edited.

AVS preset file header:

String "Nullsoft AVS Preset 0.2/n"
Byte 26
Byte [ClearEveryFrame]

Combining the syntax boxes and making it "scriptable" (using script kind of code like nsis as Atero stated) sounds awful complicated to me...
[avril]Why do you have to make things so complicated?[/avril]

I know you coders like such features, but i don't like it because it only makes things more complicated for users who aren't that good at coding superscopes, movements, dynamic movements, etc...

Just imagine how much of code it would require to make a simple circle ssc...

Draw asLines

SourceData waveform center

ColorCycles 1 #FFFFFF



Function .onInit

n=360 ; pi2=acos(-1)*2

FunctionEnd



Function .onBeat

gps=getspec(0,0,0)*0.6 ; gts=getosc(0.01,0.03,0)*0.12 ; gts2=getosc(0.2,0.04,0)*0.12 ;

rc=rand(128)/256 ; gc=rand(128)/256 ; bc=rand(128)/256

FunctionEnd



Function .perFrame

gps=gps*0.91 ; t=t+gts ; t2=t2+gts2 ; st=sin(t) ; ct=cos(t)

FunctionEnd



Function .perPoint

d=0.4+gps ;

x=sin(i*pi2+t)*ct*d ;

y=cos(i*pi2+t2)*st*d ;

red=rc+d ;

green=gc+d ;

blue=bc+d ;

FunctionEnd

Doesn't look so easy to me...

Yeah, remember, not everyone's going to be able to figure all that out. Even if everyone did, I'm not sure there's anything useful that would come out of it. What else can you do with that that you couldn't do before? How will it make coding easier for anybody?

More importantly, who suggested that in the first place?

I suggested that, for the simple reason of space: one large box is tons better than 4 small ones.

Also, if any of the other language advancements are going to be implemented (if/while/functions) then one large code box is invitable.

Besides, you're underestimating the complexity of the current system: just because you're used to it doesn't mean it's less cryptic than the above system.

There's no need to always include the line style and colors in there though. Currently, we can use the color cycler OR define our own red/green/blue values. The same approach could work wonderfully for line/dot toggling.
Similarly, I haven't used 'v' in ages, I just use getosc/getspec all the time out of habit.

Besides, if the AVS code editor was implemented decently (read: not a dumb editbox) then they could even make it so that the default functions (oninit, onbeat, ...) are always present and cannot be deleted.

One editbox(or seperate window) would be nice if it defined all of the necessary functions for you. As it stands right now, you can't even use the keyboard to move from one editbox to another, which can be a pain sometimes. Hopefully Nullsoft will make a change to the avs language and syntax that will allow for more complex presets without sacrificing speed.

anubis, ever heard of the "tab" key?

The Tab Key doesn't work in Winamp... at least on my computer.

Works perfectly for me. It shouldn't matter what Winamp does or does not do, since you're working with AVS, not Winamp.

Ok Atero, It doesn't work in AVS. I use the two synonomously [I think I spelled that wrong] because without AVS i would probably just use Windows Media Player.

Tab will only work on Winamp 2 AVS, not the Winamp 3 one.

Besides, if you're working on AVS, it's best to use Winamp 2 - Winamp 3 uses that much more system resources.