Shock Value

20th December 2003 03:32 UTC

Winamp 5.01 with AVS loops and array things (AVS v2.81b)

Winamp 5.01:
* fixed gen_ml selection bug
* added gen_ml option for no guessing at all
* made AVS and SPS support loop() in user code
* made AVS support megabuf() in user code
* made pro installer not prompt for regkey if already valid
* improved font directory retrieval in gen_ff
* added content rating system in Internet TV's listing
* added bandwidth usage statistic in Internet Radio/TV listings
* made media library guess from filename only when NO metadata found
* added seperate recent items tracking options for files/streams
* made installer better handle installing wa5 directly over wa3.
* added milkdrop docs to installer
* made uninstaller not remove winamp directory if not empty (user is
now required to do so manually to avoid people going "oops")
* made installer check sonic px.dll versions and prompt for reboot
accordingly
* fixed nsv metadata querying bugs
* fixed gen_ml guessing bugs for files with metadata that are not in DB

S-uper_T-oast

20th December 2003 03:51 UTC

Could somebody just post the new AVS .dll so I don't have to dowload a whole new version of winamp on my 14.4 modem.

dirkdeftly

20th December 2003 04:02 UTC

:(

This array support is REALLY wankass...I'm really disappointed that it was needed so badly that it had to be implemented so poorly. I hope we can get rid of this function before people start using it extensively, and implement proper array support later. It'd really be well worth the time and effort to implement some proper parsing.

BTW, Zeven just had a good idea (not sure whether he was joking or not but it's still a nice idea): EvalLib2. Add an option in the Main tree to use EvalLib2, and if it's on, add a watermark to the preset. That way, we could throw away all the wank comparison functions and add in a host of new boolean/bitwise/logical operators. Also, you could add real if/elseif/else and for structures. Then, we wouldn't have to worry about compatibility with old presets, but still have decent code support.

I know this would all be quite difficult to implement, but I think AVS is going down the wrong road ATM. The easiest way to do things isn't always the best :|

justin

20th December 2003 04:09 UTC

Originally posted by Atero
:(
I know this would all be quite difficult to implement, but I think AVS is going down the wrong road ATM. The easiest way to do things isn't always the best :|

hungryskull

20th December 2003 04:17 UTC

Just a question, could AVS maybe have it's own section on the winamp site so I wouldn't have to download the whole full winamp5 every time a new AVS comes out? Because I'm on dial-up and so are a lot of other users.

Luckily I'm using somebody elses PC today so I can download it again.

As for arrays I don't mind it being complicated.

anubis2003

20th December 2003 04:46 UTC

vis_Avs.dll v2.7.9.2

Jaak

20th December 2003 10:01 UTC

bah... so many new ideas... sure they are hard to be done with current array support... I really hoped for 3D,2D arrays, but its not THAT hard to make 1D array "2D,3D"
But arrays and loops are just great, thanks Justin man

fragmer

20th December 2003 10:20 UTC

gmegabuff is cool thing. that's for resolutions up to 1000x1000 i guess :p
But can someone explain me what is the difference between exec(), exec2() and undocumented exec3() ???

Jaak

20th December 2003 12:13 UTC

WTF are you talking about resolution!?
megabuf() and gmegabuf() are simply arrays, where you can store data... megabuf() is local to scope (dm, movement etc.) but gmegabuf() is global...
oh dear...

[edit]
deleted unworking example :p

Jaak

20th December 2003 12:31 UTC

gmegabuf() example: storing 2D precalculated points into 1d array

[edit]
bit buggy code, but it works... somewhat

Yathosho

20th December 2003 14:20 UTC

Originally posted by S-uper_T-oast
Could somebody just post the new AVS .dll so I don't have to dowload a whole new version of winamp on my 14.4 modem.

UnConeD

20th December 2003 14:37 UTC

I don't mind megabuf() at all: I played around with it already in SPS and you do a lot with it.

To make an array of n elements where the first element is removed and the last element is added: you just keep a fixed array, and calculate your indices dynamically so that the first element is in fact always a different one (so you don't have to shift the array every time you add a point). See attachment.

Like this: (virtual is the imaginary array we are simulating).

1st frame:

megabuf = [ 1 | . | . | . | . ]
virtual = [ . | . | . | . | 1 ]

megabuf = [ 1 | 2 | . | . | . ]
virtual = [ . | . | . | 1 | 2 ]

megabuf = [ 1 | 2 | 3 | . | . ]
virtual = [ . | . | 1 | 2 | 3 ]

megabuf = [ 1 | 2 | 3 | 4 | 5 ]
virtual = [ 1 | 2 | 3 | 4 | 5 ]

megabuf = [ 6 | 2 | 3 | 4 | 5 ]
virtual = [ 2 | 3 | 4 | 5 | 6 ]

megabuf = [ 6 | 7 | 3 | 4 | 5 ]
virtual = [ 3 | 4 | 5 | 6 | 7 ]

S-uper_T-oast

20th December 2003 16:36 UTC

/edit
I think you posted the wrong AVS version, anubis. All it seems to be is the same as avs2.8 w/ no loop or array support.
/edit

dirkdeftly

21st December 2003 05:39 UTC

uhh no that's not what i meant justin. what i meant was that this is not extendable, it's really tough to use - especially if you want to use more than 1 array - and it's EXTREMELY low level. my biggest problem is the variable limits. i honestly don't see what the big deal is with making extendable variable limits. i mean, why are the variable limits there in the first place? i'm not being accusative here, but i'd really like to know, since it doesn't make any sense. especially if you can extend it eightfold internally and not have a massive hit on performance.
the other problem i have is, when you add a function in avs it has very little possibility of ever improving. so that's why i don't like it when you add low level functions...they're not going to become high level functions in the future. along with the fact that since avs isn't parsing on the fly, a high level array management feature will have the same performance as megabuf() (I think). that's also why i suggested evallib2 - is there any chance that's gonna happen?

justin

21st December 2003 17:28 UTC

FYI, there are no longer variable limits (Since 2.8). It only took a small compile-time hit to add that, but it did require a lot of code reworking.

Anyway, once you get used to megabuf()/gmegabuf(), dividing it up into your own arrays is pretty easy.. and having megabuf() doesnt prevent us from adding array_alloc() etc later on -- this just provides a nice low level means to access a block of memory.

Having said that, doing dynamic array allocation could have equal performance to megabuf() type functionality, but it really depends on how it would be implemented, and that we will determine someday heh...

-Justin

Originally posted by Atero
uhh no that's not what i meant justin. what i meant was that this is not extendable, it's really tough to use - especially if you want to use more than 1 array - and it's EXTREMELY low level. my biggest problem is the variable limits. i honestly don't see what the big deal is with making extendable variable limits. i mean, why are the variable limits there in the first place? i'm not being accusative here, but i'd really like to know, since it doesn't make any sense. especially if you can extend it eightfold internally and not have a massive hit on performance.
the other problem i have is, when you add a function in avs it has very little possibility of ever improving. so that's why i don't like it when you add low level functions...they're not going to become high level functions in the future. along with the fact that since avs isn't parsing on the fly, a high level array management feature will have the same performance as megabuf() (I think). that's also why i suggested evallib2 - is there any chance that's gonna happen?

Raz

21st December 2003 17:42 UTC

All i'm really arsed about now is turning off that godawful 'effect lists open whenever you go near them' crap. And that crashing before never bothered me because you could save it quickly, can't do that anymore.

fsk

21st December 2003 19:12 UTC

agree with raz. And the order of stuff in the menu is still wrong sometimes:(. But otherwise the new AVS rocks, and it rarley crashes during projections in fact there was only one crash yesterday and i wasnt there (sleeping), so i dont know if it was AVSs fault. Great work Justin!

sidd

21st December 2003 23:23 UTC

Firstly in responce to fragmers question: There is no "exec" function, only an 'exec2' and apparantly 'exec3' undocumented.
The syntasx is clearly documented in the expression help.

st=exec2(assign(t,t+0.01),sin(t));

t=t+0.01; st=sin(t);

Raz

21st December 2003 23:51 UTC

Only time i get crashes is when changing the variable names for 3d rotation. Usually after a lot of unsaved tinkering but that's my own fault. ;)

Raz

22nd December 2003 23:09 UTC

eg:
http://www.geocities.com/raz_oo5/crashing.txt
everything excpet the floor was done without saving.

I think i'll go cry for a while.

Edit: well, i sat down, and redid the entire thing. Ack.

jheriko

27th December 2003 02:59 UTC

someone complained that 2d 3d array support is not there. even in c++ array[10][10] can be treated just like array[100] and using % you can use a 1d array just like an nd array.

Raz: I feel for you... I think everyone in these forums has probably lost 90% of some killer preset to a crash.

OnionRingOfDoom

26th February 2004 03:54 UTC

sidd: yeah, mine does that too. Gotta be careful to uncheck the plugins box on some pack installers. Luckly, the newer versions of Pimpbot exclude the plugins (I think). Anyway, my AVS rarely crashes.

Anyway, I figured I'd write something up for this place, so I'm gonna write a doc on making simple 3d geometric SSC primatives (sphere, cube, cone, etc.)