New preset authoring guide

[Rovastar]

Hi,

I have added a new preset authoring guide to my site. It is in Word format and I will try and add to it at regular intervals and anything to add too it folks just email me rovastar@hotmail.com.

My PC I have for running MilkDrop is still not working. So no new milks from me. But soon hopefully.

Let me know what you think of the guide basically it is what was posted here before plus some new stuff.

Rovastar

[unchained]

zoom = 1 + sin(sin(time*rad)/10 - cos(x/y)/30

missing a close paren in there somewhere


Where the value of rot and zoom from the menus are 0 and 0.9 respectively. So it means the same thing. But the computer is doing and extra look-ups and calculations therefore it is not as efficient.

You think? I never tested this, and you'd have to be really clear on how ryan's code works to be sure. Depending on how the equations get tokenized, it could really go either way. I always kinda figured having the values in there was a nice touch, as it allows somebody inexperienced at preset authoring to fiddle with things a bit from the menus without having to actually touch any of the equations.

Although Ryan’s documentation states that decay is in a range 0 to 1 it realistically is a range of 0.9 to 1.

My memory's telling me it's actually limited to .95-1 in the menus, but I could be off.

If you find that the image on the screen appears to dark there are 2 different variable you can change that to achieve greater brightness. The first to look at is decay/sustain.

should be "appears _too_ dark". Also, i've found changing the opacity or size of the waveforms can have a huge effect on brightness (wave type 5 tends to get too "spread out" when you make it bigger)


Nice work

[Rovastar]

Thanks for the feedback unchained.
You appear to have read it all.:)

---------
Where the value of rot and zoom from the menus are 0 and 0.9 respectively. So it means the same thing. But the computer is doing and extra look-ups and calculations therefore it is not as efficient.
---------

I just figured that it if it is looking up another variable then the computer is doing more work. Therefore obviously it will be slower - I admit but such an infinitely small amount we could probably never notice.

IMHO in any programming context:

z = x + y
z = 0 + y (quicker)
z = y (quickest)
(where x = 0)

What does everyone else think? Maybe I am wrong. (Gets you thinking though)

But true, people can change the presets on the fly from the menus if you do not do it this way and keep the variables in the equation.

The decay thing it is from memory for me also lol but I was pretty sure it is 0.9 to 1. I need my good pc working. It is all written from memory.

If you have opacity by volume on you cannot really add any additional brightness to it - Can you?

Anyway it is only a start and it is already 2000 words long and nowhere near finished. Thanks for that I will change the document and up load it.

Cheers,

Rovastar

[unchained]

IMHO in any programming context:

z = x + y
z = 0 + y (quicker)
z = y (quickest)
(where x = 0)


You'd think that, wouldn't you? No such luck.

There's a zillion layers of interpretation between the code above and the assembly instructions that actually get passed to the machine. Geiss is using a third-party math library, and for a HEAVILY API-based OS. You don't know what type of optimizations geiss himself is doing, let alone the math library, and what type of compilation THAT stuff is going through. A fairly mature c or c++ compiler would use whatever version was fastest on the specific chipset, but suppose Ryan's storing the zoom in a CPU register, considering it gets used so often, or maybe the compiler's doing that and he doesn't even know or care. <shrug>

Code is code these days. My presets don't run so slow because they're poorly coded (though in some cases they are, I'm sure), they run slow because they're running in directx on milkdrop on winamp on windows on frog-knows what hardware.

Code c64 assembly demos if you want to optimize. I just wanna make stuff that's purdy to look at :)

[Rovastar]

Point taken Unchained it explains the z = 0 + y example to a degree but I cannot understand how:

z = y

can ever be slower in any circumstances then:

z = x + y
(where x = 0)

what about

z = 3.1415*x + y, etc

I am from a old skool programming background and find people today are far too lazy with the writing of code in general. Computers are quick code doesn't have to be efficient any more. ASP etc comes along on the web and in the early days some of the semantics of the code was shocking – were speed and efficiency was important.

Being efficent is a good practice that should be used anyway I believe.

You stated yourself that there are a zillion layers from MD equations to output to screen and that is exactly my point. A tiny inefficency in the preset will be magnified a zillion times and it could (probably not though) make an effect on the screen.

Yes it is a trivial example (and maybe a little misguided) and I may remove it from the guide.

It least it got us talking about stuff anyway.

[unchained]

Point taken Unchained it explains the z = 0 + y example to a degree but I cannot understand how:

z = y

can ever be slower in any circumstances then:

z = x + y
(where x = 0)


In milkdrop, chances are damn good you're right. In microcode, you often hit situations where it's faster to do something tricky like a zero-based stack register addition than moving something from point A to point B.

Being efficent is a good practice that should be used anyway I believe.

I'd be insane to argue that. It's just that having worked on compilers and whatnot, I've seen many situations where the machine instructions have so little resemblance to the high-level code that if you only had the binary to work from inside of a debugger, you'd be lucky to reconstruct "z = x + y" out of the mess.

As an example (probably not very practical, but it just popped into my head) many RISC platforms have what's called delayed-branch instructions, where when the CPU performs a "jump" type op, the next few ops after it will already be in the pipe. Primative compilers accounted for this by always coding a few no-ops after a jump, but of course that's a perfect place to slide in a few optimizations if you're really slick.

...

I wouldn't remove it from the guide. In general you're right, and efficiency of coding is definitely something that should be mentioned. I've just learned to look at any kind of optimization done at such a high level with a jaundiced eye. :)

[Krash]

Found an error in your table of ang values - You've got the values for 1 and 3 mixed up , and the same for 7 and 9.
the top right corner should be pi/4, and the bottom right is -pi/4, you've got the top and bottem left, respectively.

- Krash

[Rovastar]

I have updated the guide added sections for Video echo, colour cycling and breifly borders - also corrected mistakes. Please feel free at any comments/ sections and give feedback.

Is the values of ang 3pi/2 or -pi/2 for directly below center? I am a little confused.

Rovastar

[unchained]

Bah, who uses that junk anyway? If you can't do it with a sin wave, I'm not having it!

Anybody care to teach me a few quick log exploits? I know what a log is, but I've never seen anybody use one for anything that I found interesting, so I've studied other things. What does it actually DO, aside from a few tricks to simplify standard arithmetic?


Heh...I know more about topology and knot theory than most people living, yet I don't know how to use logs to any advantage...kinda funny.

[Krash]

> Is the values of ang 3pi/2 or -pi/2 for directly below center? I am a little confused.

Technically, it's both. The system goes around in a circle, but the numbers will keep getting higher/lower (depending on whether you're going clockwise or anticlockwise). For simplicity, it's common practice to use the values -pi to pi. (Except when you need to describe more than one revolution of the circle, such as in a spiral)

So to answer your question, Milkdrop refers to straight down as -pi/2. Any corresponding value (such as 3pi/2) will be treated as -pi/2.

>Anybody care to teach me a few quick log exploits? I know what a log is, but I've never seen anybody use one for anything that I found interesting, so I've studied other things. What does it actually DO, aside from a few tricks to simplify standard arithmetic?

You know what a log curve is?
The log function (natural or base 10, it doesn't matter) of x is asymptotic to the negative y axis on the positive x side. Meaning that as you approach x=0 from the positive direction, the log of x approaches negative infinity. When x=1, y=0. As x increases, the curve flattens out (it's very steep when x<1), but continues to increase. The curve never becomes flat, just flatter. When x is infinity, y is also infinity. The log of x does not exist when x is less than or equal to 0.

So that's what it actually does. Making good use of it is tricky.

- Krash

[unchained]

Ok, I can work with that as soon as I find a few graphs.