waldronate - TY for replies, and i do hope not to take up too much of anyone's attention.

i've been using perlin in audio, and as an audio coder i'm well used to octaves, and certain conventions in procedure. i'll explain my implementation somewhat, which may elicit why i'm seeing things differently.

audio requires speed, so wherever possible, i use INTs, and unsigned ones at that. my noise map is unsigned short[x][y] and each octave is a stored array smaller by a power of two.

(or what i prefer to call a tower of poo)

each octave is stored and cosine interpolation is used at summing each octave to discern any coordinate (i'm familiar with bicubic interpolation but cosine looks well enough and is faster given that i'm using INTs and ^2, so all cosine functions use a ^2 array of float values).

so my variables for each octave range 0 - 65535. i sum them using n^2 for successive octaves.. typical perlin, and squish this range into my desired outcome (0-255 for bitmap output, data is retained in the 2^16 for processing).

it is trivial to use 0 or 65535 for the outcome of each cell, but this doesn't look too different from standard perlin. the outcome of the previous layer is used to determine the magnitude of the subsequent, or something like that?

the approach in musgrave.h is very different from my set of discretised arrays... so i've been searching for a non-code explanation of the procedure

here's an example of output using perlin octaves, no smoothing to illustrate my current progress..
Click image for larger version. 

Name:	ground.jpg 
Views:	274 
Size:	140.4 KB 
ID:	43812