Various aspects tuning

Wanted ability to tune various aspects of AVS from preset code - window size, pixel doubling and even overlay mode. Of course, beat detection and else. Probably some people dont' want allow presets change these parameters. Therefore it must be flag disabling internal tuning. Of course this flag must not be accessible from preset code.

The idea to include default display mode is a nice one, but why we force users to use such setting? Someone may only have a slow computer to view it, or may be something else...

What good is it if you can turn it off? It won't be 100% sure that the preset is viewed as it should if the feature can be turned off 🧟

Besides it would totally piss of n00bs and then they would come to this forum and yell: "AN AVS PRESET CHANGED MY SETTINGS!!!%¤#! HOW DO I PREVENT THIS!!!"!¤#"!%¤"# PLEAAAAZZZZ HELP!!!! IM DESPERATE!!"

I can't deny though that it is a nice idea, the window size setting would allow to create really different presets, but i don't think that's absolutly necessary since you can code scopes and dm's to work in all different kind of resolutions.

Guys read again - I told there must be flag disabling internal settings change. That means in Settings\Display must appear setting with 2 values:

On - Enable preset change internal settings of AVS
Off - Disable preset change internal settings of AVS.

If user is smart enough it can turn this on. For others it is off. And preset itself cannot ever change this.

since you can code scopes and dm's to work in all different kind of resolutions.

What if preset uses solid bitmap for background? If you set line width in pixels in Set Render Mode - then AVS doesnt' scale it automatically.

y'know there's an edit button for that, gourmet

Anyway, n00bs wouldn't know how to turn it off (whether it was default or if they did it themselves). That, and who the fuck is going to use it? This falls under the same category as your SSC alpha blending...

Again - if you will not ever use it - that doesnt' mean nobody will. I will. Fuck.
😠

I didn't say I wouldn't (even though I won't). I'm saying nobody else will, for the obvious reasons Tuggummi stated. If you're too stupid to see that it's not my problem 😔

If you dont' wanna it become your problem - think more before reply to my post.
😎

I don't see the point in controlling overlay mode from code... how do you think people would react when they're browsing presets and suddenly their desktop background changes?

Similarly, why control beat-detection? Write your own beat detection then...

The only option I do want is the ability for effect-lists with a different internal resolution.

For example, a half-size (or percentage size) effect list that is rescaled to normal size when blended with the rest. Similar, a fixed-resolution effect list. If they add the option for bilinear-filtering or not, this would be a better replacement than messing with the user's pixel doubling setting.

Besides, if a preset were to include code to change an option, where would it be turned back? We'd have to add an 'on unload' piece of code to every component just for this purpose. Seems wasteful to me.

Ok there are points to talk about...

I don't see the point in controlling overlay mode from code... how do you think people would react when they're browsing presets and suddenly their desktop background changes?

Overlay mode assumes that some overlayed color must be set on desktop. It is controlled by user. Of course, WinAmp could automatically change this color and run in overlay mode. For example set desktop to 0x000001 and overlay this. But it MUST warn user about it and do nothing if user declines. I do not insist on auto-overlay feature. But some presets have good look on desktop. And I'm sure many users even dont' know about desktop overlay ability. We can show it.

Similarly, why control beat-detection? Write your own beat detection then...

Hm. Why should I write my own if I could just change settings of AVS? It already has two modes - they are completely enough. I noticed my presets better look with "standard" detection. But some others with "advanced". I want set option as I see.

Besides, if a preset were to include code to change an option, where would it be turned back? We'd have to add an 'on unload' piece of code to every component just for this purpose. Seems wasteful to me.

I had an answer for this question before. But right now I just got better idea. All this can be implemented as APE. Name it - "Override settings". You can get idea from it's name. If such APE appeares in tree - AVS ignores it's default settings and uses provided by preset. And in this APE it MUST be ability set window size and position. Just imagine - window can change it's position and size while working. If expressions and variables will be available in this APE - window can even dance on screen... Jump on beat... Wow... I want this.

Of course if there is no such APE - AVS goes as now. Of course it must apply default settings each time when preset starts. Then if user selects even old preset - AVS will appear as usual.

If expressions and variables will be available in this APE - window can even dance on screen... Jump on beat... Wow... I want this.

No offense but this sounds like a HORRIBLE idea. Why the hell would I want the window to dance on screen? And besides, how much 'dancing' can a rectangle do? It would only make it harder to view the preset, IMO. Just think about it practically. A rectangle that is bouncing around on the screen. How would you change the preset if it keeps moving around? How would you close it?
This sounds like one of those things that might be cool in your head, but suck practically.

Hm. Why should I write my own if I could just change settings of AVS? It already has two modes - they are completely enough. I noticed my presets better look with "standard" detection. But some others with "advanced". I want set option as I see.

This depends hugely on the music playing as well. There is no reason to say something will work better with one beat detection than with another.


Don't get me wrong, I'm all for progress, but you're thinking from a preset author's point and not a user. Any feature that is added should be made to allow the user to see prettier presets, nothing else.

Users *hate* anything that changes without their knowledge. I would hate it if a preset changed my overlay color or turned overlay on/off.

If only one feature could be added to AVS, I would certainly not want this, because I would turn it off the first moment it annoyed me, and never look back again.

Dude, think for two seconds. If the AVS window suddenly started moving around on the screen without you telling it to, what would YOU do? If you simply accept what's happening I suggest you run Norton a few times and see how many virii you've let sit around your system for years on end.

Nobody but NOBODY wants to have messages popping up for 'Can AVS switch to overlay mode?' and 'Can AVS change your window size?' and 'Can AVS change your color settings?' whenever they open presets. Like I said before, if some n00b all of a sudden sees AVS switching corners of the screen every few seconds he'll wonder what the fuck is happening to his computer, NOT what's happening to his AVS window. Thus anyone who actually uses 'aspect tuning' is never going to be very highly regarded in the AVS community. You want your presets to get deleted a minute after they're installed? Fine by me - just do it somewhere else.

First of all I wanna set window size and change "pixel doubling" from preset. About dancing window - I would like see it on my screen. It can not only jump but float or change it's sizes. On your 3D preset camera can be synchronized with this window (if only global variables appear...). It will look as you see at large 3D world throgh floating window. About how to close it - it must stop changes if music mutes. But again - this is just an idea which I like see. As user.

And here is another problem with AVS - how to tell user what he will have while preset runs. What he must do to get preset properly looking - as author recommends. Of course there is Misc\Comment window - but to access it user has dive to preset code. O course README.TXT can be compiled and shown while installation. But it lays deeply in directories structure - not useful for further views. Special intro preset can be created and placed first in stack. But how much text can you place there? This all is not so useful to use and to create. I did not see detailed introductions. I'd prefer ability place some readme.html file to collection directory. And this file must appear on top of collection. When clicked - this file openes in internal WA browser. This allows do many things. So many.

You're not listening, gourmet. NOBODY WANTS AVS TO DO THINGS THEY'RE NOT TELLING IT TO DO. If I'm just randomly switching presets, I do NOT want a pop-up asking me if I want my settings changed. No one else does either. If I'm not in control of my computer, it's virtually useless to me - my computer is here to do what I tell it to; it always has been and it always SHOULD be.
And I will say once again: If you're new to the world of AVS - not just writing, but watching - and all of a sudden you get a popup saying "The screen's going to start moving now" and every time you try to stop it you can't get a hold of it, you're not going to like AVS very much. Think about what you're asking for...just because YOU want to see that doesn't mean everyone else will.

The only idea is like is the minibrowser integration... but only if the browser is already open.

You're not listening, gourmet.

Of course. But you are not reading. 😁

NOBODY WANTS

Didnt' your Mom tell you? - Speak about yourself.

LOL

The only idea is like is the minibrowser integration... but only if the browser is already open.

Why AVS cannot open minibrowser if .html file selected? It is not just implemented. Or there are any internal problems with it? As programmer I cant' find principle problem.

Argh... because when I'm watching presets I don't want the friggin' minibrowser to open in my face. I want to watch presets. It has nothing to do with physical limitations, but what you should and should't do.

It's like a popup - but worse.

Didnt' your Mom tell you? - Speak about yourself.

Was that supposed to be funny? Was that even supposed to have a point?

because when I'm watching presets I don't want the friggin' minibrowser to open in my face

Of course in auto-switching mode AVS must open only presets. Minibrowser has not appear. It must be opened if only you select "readme" in top of collection list from presets folder.

You're making this far too complicated - for the AVSer AND the user. Remember, not all (in fact few) users will be able to understand any of this. If your idea were implemented, no one would use AVS because of the hassle involved.

For authors:

1. Ability to store .html or .txt file appeares. File must me stored in same folder where collection of presets lay. Simple txt will be shown in browser as non-formated text. HTML will be shown as hypertext with ability place links to author's home page, WinAmp pages, skins, pictures and so on. File can have any name but ONLY ONE such file will be accepted bu AVS. One call of
findfirst("*.html"|"*.txt")/*in C-like terms*/ will be made and accepted by AVS, other files will be ignored.

For users:

1. One item with file's name appeares on top of presets list in collection submenu. When selected WinAmp openes minibrowser and shows this file there.
2. When auto-switching presets AVS openes only .avs files.

I do not see here anything complicated.
That is not more complex than create or view single-page Web-site.

Looks like you never did programming and never worked with users. They are smart. Beleive me - I'm university graduated MS in computers and work in this area last 15 years. I created software with powerful interface (even before and after MicroSoft appeared). Users were glad use it.

Originally posted by gourmet
For authors:

1. Ability to store .html or .txt file appeares. File must me stored in same folder where collection of presets lay. Simple txt will be shown in browser as non-formated text. HTML will be shown as hypertext with ability place links to author's home page, WinAmp pages, skins, pictures and so on. File can have any name but ONLY ONE such file will be accepted bu AVS. One call of
findfirst("*.html"|"*.txt")/*in C-like terms*/ will be made and accepted by AVS, other files will be ignored.

I'd have to agree that a README file for a preset pack that used anything that you suggested should, indeed, be included. However, it should be displayed before installing the preset pack - perhaps in the installer, for example?

But also extracting it to the pack's storage area is a good idea, so that you can prove to anyone else who might want to see these "cool new presets" that you've downloaded (and starts screaming "DUDE, YOU'VE GOTTEN A VIRUS!" when this stuff happens) that "No, it's not a virus, it's supposed to happen, see right here in the readme? See right here in the preset tree? There ya go, proof positive..."

For users:

1. One item with file's name appears on top of presets list in collection submenu. When selected WinAmp openes minibrowser and shows this file there.
2. When auto-switching presets AVS opens only .avs files.

I do not see here anything complicated.
That is not more complex than create or view single-page Web-site.

1. TGHat would make perfect sense - having the minibroser only open the file when it's selected in the "Open..." dialog box.

2. THIS SHOULD BE COMMON SENSE. AVS is compatible with AVS files - ONLY. It can render bitmaps and AVIs, but it CANNOT - REPEAT, CANNOT - read HTML. For that you'd need the minibroswer, Internet Explorer, Mozilla, Opera or Netscape Navigator.

I'd have to agree that a README file for a preset pack that used anything that you suggested should, indeed, be included. However, it should be displayed before installing the preset pack - perhaps in the installer, for example?

It can but default installer script doesnt' contain this feature. You have to rewrite the script to add this. I thing it is not useful for most developers. Better include readme feature to NSIS by default.

But also extracting it to the pack's storage area is a good idea, so that you can prove to anyone else who might want to see these "cool new presets" that you've downloaded (and starts screaming "DUDE, YOU'VE GOTTEN A VIRUS!" when this stuff happens) that "No, it's not a virus, it's supposed to happen, see right here in the readme? See right here in the preset tree? There ya go, proof positive..."

Yessss.....

THIS SHOULD BE COMMON SENSE. AVS is compatible with AVS files - ONLY. It can render bitmaps and AVIs, but it CANNOT - REPEAT, CANNOT - read HTML. For that you'd need the minibroswer, Internet Explorer, Mozilla, Opera or Netscape Navigator.

The only changes of AVS code must be - findfirst() html or txt file in presets folder, display it's name on top of presets list. If this name selected then just DDE it to WinAmp mini-browser. Period. All other non-avs files will be ignored. When doing auto switching presets AVS will ignore all non-avs files. As it does it now.

Why use other viewers if you already have mini-browser near and skinned?

Originally posted by gourmet


The only changes of AVS code must be - findfirst() html or txt file in presets folder, display it's name on top of presets list. If this name selected then just DDE it to WinAmp mini-browser. Period. All other non-avs files will be ignored. When doing auto switching presets AVS will ignore all non-avs files. As it does it now.

Why use other viewers if you already have mini-browser near and skinned?

I was merely making a point - the point being that AVS, by its design, ins incompatible with, and thus unable to display, HTML files. And, as I also said, in order to display them, you would need an HTML-enabled program or program plugin on your system.

Examples would be:

1) The Winamp Minibrowser
2) Netscape Navigator
3) Internet Explorer
4) Opera
5) Mozilla

I could go on, but I think I've made my point. Also, some people don't always use the Winamp Minibrowser, so, if the Minibrowser isn't enabled, they can choose to either:

1) Activate the Minibrowser to read the HTML/TXT readme
2) Use the default Web broswer on their system (usually Internet Explorer or Netscape Navigator) to view the HTML readme

or

3) open Notepad/WordPad/other word processing software to read a TXT readme.

I was merely making a point - the point being that AVS, by its design, ins incompatible with, and thus unable to display, HTML files. And, as I also said, in order to display them, you would need an HTML-enabled program or program plugin on your system.

Sure and in common case user already has it. Can you imagine any one networked computer running WinAmp and not having Web-browser? I can imagine but I would greatly surprised by it and I'd not recommend it's owner open HTML files. 😁

I could go on, but I think I've made my point. Also, some people don't always use the Winamp Minibrowser, so, if the Minibrowser isn't enabled, they can choose to either:

Yes, if WinAmp mini-browser is not installed - then AVS has to run "default browser". If it failes then just message - "Not available display text file."

Even WA-mini-browser containes Internet Explorer builtin as DCOM object. (may be not IE but "default browser" - I didnt' dive deep)

3) open Notepad/WordPad/other word processing software to read a TXT readme.

Not necessary. All browsers you listed can clearly read and display .txt files. Just use default browser for txt. Easer select codepage if needed. And this is more universal and easer to implement - no code needed to tune to operating system. Just "open default Web-browser" even for .txt file. Simple.

God, gourmet, would you just drop this?

I agree with Atero... if you're so bent on it, write it yourself as a 'misc / comment HTML' ape or something, it's not that hard. But aside from Clashman no-one seems to want it. I think it's a horrible feature, and I'd refuse to download any pack that popped up annoying HTML when I'm viewing it.

(Idem for installers that close down your Winamp, change your preset-switching options, change the resolution, etc.)

Just 'cause you two think Gourmet's idea sucks doesn't mean EVERYONE does (case in point: ME).

Also, who ever said that the readme had to pop up every time a preset from the pack was loaded? It could easily pop only the first time a preset was loaded.

Example script for such a thing (in the completely fictitious but easy to understand ClashScript language):

if TimesLoaded>0 and Preset LoadedFromDirectory=yes then noexecute #onload 

This checks the PresetLoadedFromDirectory flag, which answers the query "Was a preset loaded from directory c:\Program Files\Winamp\wacs\avs\{directory}?" and the Times variable, which answers the question "How many times was a preset loaded from this directory?". If both answers are negative, then the #onload string executes.

#onload(c:\Program Files\Winamp\wacs\avs\{directory}\*.avs) set PresetLoadedFromDirectory=yes,TimesLoaded=1,loadfile(c:\Program Files\Winamp\wacs\avs\{directory}\readme.txt)

This sets the Preset Loaded From Directory flag in the script to "yes" and the variable Times to "1" - these are the key flags for the previous ClashScript line.