some experiments using gmegabuf

Here's some stuff I made using gmegabuf.

Mystify: screensaver-like preset using particles that bounce around and are connected by lines.

Particles: Exactly what the name implies. This one uses loop() commands, so the max particle size is about 400. Click to add "energy". This engine isn't perfect, since particles sometimes get stuck in the floor. But it shows what you can do with gmegabuf.

Screenfade: The red is a spectrum visualization. The blue is a ghost image of the red, saved using gmegabuf.

Waterfall: A particle engine made to look like a waterfall (sort of). Change the number in the SC to whatever you want; this one does not use the loop function so there is no limit. Just don't expect it to run fast at high numbers.

The gmegabuf function is great! I just wish the loop function's count could reach the limit of gmegabuf. That's what is really needed right now to make full use of gmegabuf.

You can just do nested loops if you need more. The limit is there to prevent infinite loops.

I don't see why that limit should be there. I also don't see why we should have a "countdown" type loop rather than an argument based loop (e.g. for( ; ; )). There ought to be an addition to the Main tree which sets a personal limit for loop repetitions...that would both eliminate infinite loops and give us more flexibility with them.

The difference between the current loop and for( ; ; ) is purely semantical. The for-syntax only adds something in powerful languages like C++ where you can use iterators or objects rather than ints.

I'm getting tired of your whining about the new AVS stuff: it's not as if it's an amazingly low-level function in an otherwise high-level language. AVS Evallib is low-level all the way.

Now with collision detection! (But not accurate collisions; the balls don't bounce off realistically.)

A nicer syntax would have made it easier to write the code, but this proves (to me at least) that AVS is capable of some complicated effects, even if they are a bitch to program.

you need to predict collisions based on the next frame, based on the direction the particles are moving. That way, they wont stick together like that.

Yes, I know, I might make true collisions later on. I just wanted to see if I could get any detection at all using loop() and gmegabuf().

i started, but it got too messy so i gave up.

Just so you know, there's a useful tricks for using loops:

loop(n,
assign(blah,blah)+
assign(blah,blah)+
assign(blah,blah)+
assign(blah,blah)
);

Much easier than trying to leep track of a whole bunch of exec3's

that collision one is nice 🙂. I don't understand it, but it looks really nice. you could make a great preset out of it.