Do I need to download something else to view that preset? All I see is a white spectrum analyser, on a black background, with no fading. I got similar problems with a pack your other presets that I downloaded.
Oh, and FYI - the bass_att values aren't what you've thought they are. Maybe Rova led you to believe wrongly, I don't know. Here is the basic equation:
Bass_att = bass(this frame) / bass(previous frame)
It's a relative percentage thing. There might be more to it, but that's the gist of it.
Although you probably get used to it in no time
Aye, that you do.
For most presets that I write these days, I don't even touch the actual menu part, except to change the waveform. I usually do everything in code.
Once you're used to it, the on-screen interface is quite useful. It's cool to be able to be sitting watching it go full screen, and then a preset comes up that you realise has a mistake, or would look better in green, or whatever - you can change all that without ever seeing your desktop.
And on top of that the random feature (press space) sucks large paper balls sideways through long straws.
Graphic description there. 😉 👍
I understand what you're talking about with the difference in movement, even if Rovastar doesn't =]
As you've figured out, all the calculations in MilkDrop are done inline,
before Anything is changed on screen. So MD grabs all the values that are set in the menus, then runs through the per-frame code. After that, it runs through the per-pixel code once for every grid point on the mesh. Values for all the remaining pixels are taken as a weighted average of the mesh points around them. Only after all this is done, does MilkDrop draw the next frame.
As you've said, AVS is different, in that the screen is recalculated for every module in the preset. And yes, this is part of the reason AVS is slow, along with the fact that it does everything on the CPU. SSE / 3DNow! might be useful for pixel ops, these are basically streamlined loating-point operations. So if you're moving things around using decimals, they might come in handy. (They're referred to as 3d-accelerating instruction sets, because when simulating 3d space, almost everything is a decimal)
Beat-detection is just something that's not focused much on in AVS.
I agree with Rovastar on this one. I admit there are many MD presets (most notably the ones it comes with, but many user-made ones as well) that have no reactivity to the beat at all, beyond the oscilloscope. At the same time though, we have many which do react noticably to the music, and we're developing new effects all the time. What's the point of a music visualisation plugin that has no discernible relation to the music? =P
The presets that don't react with music (in either MD or AVS) could just as easily be AVIs, and you'd never know. Plus, they'd be pre-rendered, so they'd run faster. 😉
I was previously unaware of AVS's ability to "grab" info from a point (or more usefully, a range) on the spectrum. This then become your equivalent to our bass, mid, and treb variables. while being able to arbitrarily select a point on the waveform is cool, I don't see what you'd do with it. I would probably be constantly defining the same areas of the spectrum to refer to as bass, or whatever.
Defining a single point could posibly be used as a method for finding a random number, but why bother, when a random function already exists?
I think I can show that AVS is *harder* to program than MD
could you give us a simple example? What would you need to do if you wanted to move pixels further to the right the further from the left they got? What I mean, is, have things moving very slowly at the left side of the screen, and then accelerating exponentially (or even linear acceleration) off to the right. Would something simple like that be alot of work to code in AVS?
The superscope is one part of AVS that I haven't been able to figure out. I've been looking at some of El-Vis' 3d presets (maybe they're really complicated, but anyway). He seems to be using alot of variables in his definition of the superscope. Things like rx, ry, and rz (which I am assuming are for rotation along the three axes). What I'm confused about, is which variables are part of the actual superscope, and which were defined by El-vis for the purpose of his preset? An of those which ARE part of the superscope, what do they each control?
I think that if I understood AVS a little better, I may be more appreciative of it. I don't think I'll ever prefer it over MilkDrop, as the speed more than anything is such a big issue for me. But I'd like to be shown just how versatile it is, by some preset writers who have done supremely excellent presets.
I like this conversation. Let's continue it.
- Krash