[music-dsp] introducing myself

[Thomas Merkle, Bitplant]

> Have admired applications which can display well-rendered "odd shaped" knobs
> such as guitar-amp style "chicken head" knobs which must obviously be
> separately modeled for each degree of rotation.

nope. you model once (one object) and have the model spin. you tell the 3D
app from which angle to another to turn and the required number of frames.
technically speaking there is no difference between a simple cylindrical
knob and a more complex form.

> Figured that such programs must be using a bunch of separate bitmaps for the
> knob rotations, since it might be difficult and cpu-intensive to get a
> smooth appearance by software-rotating a single master bitmap.

it's just one bitmap containing all the frames.
 
> Even if software rotation didn't add aliasing and jaggies, the knob
> highlights and shadows wouldn't look right at different rotations. And who
> would want to add code equivalent to a ray-tracing 3D program, just to get a
> cool looking knob in an audio plugin?
> 
> To save on memory dedicated to such potentially huge multi-bitmaps, wonder
> if anyone has explored this--
>
> Convert the series of bitmaps to a compressed MOV or AVI video file? When
> the user adjusts a knob, the program could off-screen "play" the movie to
> the proper frame location, which reflects the current value of the knob, and
> then copy that rendered bitmap to the program's window?

as posted before, the easiest way is to have a single strip bitmap and to
point to the dedicated frame. if i got it right the compression in .mov
relies on removing precedently displayed pixels in following frames, so the
app would have to check all frames 'til all pixels are in before displaying
the actual frame. hmm ...

> Perhaps that would be too complicated just to save memory, dunno.
> 
> Sometimes it is scary to write a nice compact program, and then see it grow
> to several megs once you add the fancy screen graphics (G).

strip the bitmaps to an adaptive 8bit palette, that saves much.
and hey, let's get serious: the days of AT286/16megs have gone. to have
compact programs meant to be just compact programs might be some kinda
sport, but a nice app is something different for standard users. it must be
easy to handle and agreable to control. if it looks and feels cool, it will
be used frequently. compact code makes sense if its meaning is *optimzed*.
not just small.
when i think of all the good and properly implemented interfaces we could
have for the same filesize if only the code was optimized ...

cheers
/thomas merkle
bitplant


dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
http://shoko.calarts.edu/musicdsp/