Knob dimentions saved in PNG/GIF meta information

[infuzion]

I was just looking inside a knob, & noticed that the knob system that kirkagur & I have reduced from SM's that each knob calculate the strip size & positions at start up. Not an issue for 1-4 knobs, but when you have 30 knobs in a VST, things can start to be worth reducing.

I tend to use a single separate Knob Strip Loader connected via wireless to make it easier to change out the knobs quickly. However, I don't presently use wireless for things that should be calculated only once rather than on a per-knob basis:
Cell Count (number of animations)
Cell Area (static)
Grid height & width
However, I think this info is best stored in the graphics file, & retrieved via a new/revised Animation Bitmap primitive. Until then, how do people build their GUI animations; is each cell joined vertically or horizontally please? Is there already a meta tag for any of this info (cell size, count, direction, etc)?
cheers

[Acrobat]

That could be useful....

Knobman align cells vertically by default, of course you can change it but most people rely on the
default method, as I've seen in lots of examples here on the forum.

When preparing the math, consider that as long as the CELL (was: strip) has a square form,
Cell Count and Cell Area are not needed as the are values DERIVED from Width and Height of the strip.
When the cell is rectangular (example Sliders) the simplyfing trick will not work.

A.

[trogluddite]

Likewise, I use vertical because it is the knobman standard.
It ought to be relatively simple to make a module that parses the info from the filename. So your file would have a name something like 'Myknob v10 x30 y40', meaning '10 frames arranged vertically, 30 by 40 pixels'. In fact, you could work out the number of frames and their arrangement once you know the frame size anyway, and simplify it to 'Myknob 30x40'

[infuzion]

Ty Acrobat for the insight!

It ought to be relatively simple to make a module that parses the info from the filename. So your file would have a name something like 'Myknob v10 x30 y40', meaning '10 frames arranged vertically, 30 by 40 pixels'. In fact, you could work out the number of frames and their arrangement once you know the frame size anyway, and simplify it to 'Myknob 30x40'

That's a good idea! We just have to make sure that "v" is not used for "version".

[trogluddite]

Got a parser for the 'Myknob 30x40.png' format of file name working - I'll try to extend it to work out the number of frames (sorry, can't post attachments in Ideas and Requests - I'll post up the fulll thing elsewhere when finished)

[MegaHurtz]

If it`s a square image you can work it out by size alone.

[trogluddite]

Cool for knobs but square sliders look a bit silly

[stw]

If it`s a square image you can work it out by size alone.

You can always work it out by size.
If real x is greater than parsed x it's a horizontal allignment. If y is greater than it's vertical.
Devide the size by the parsed single size ad you'll get the frames.

[trogluddite]

Got halfway to that solution, then got distracted by another possibility.
I'm going to try making it so the animation frames don't even have to be one single strip, but an X,Y grid of frames.
For a normal knob you could read them like a book a line at a time. That's maybe not so useful, but you could also select the X and Y seperately and have a bitmap display with two dimensions - to show a little frequency plot from the frequency and resonance for example. I'd just really like to see if that's more efficient than using vector graphics.

[infuzion]

I'm going to try making it so the animation frames don't even have to be one single strip, but an X,Y grid of frames.

My idea of standardizing either vertical or horizontal is to reduce coding (the number of divides), while this idea will increase coding. I do have another idea for XY grid for animation though.

[trogluddite]

My idea of standardizing either vertical or horizontal is to reduce coding

Oh yes,like I said, for normal 'one dimensional' knobs, not very useful - the knobman vertical default seems pretty well accepted as standard. But for two dimensions, there shouldn't be significantly more code than extracting X and Y from one very very long strip (whch would definitely need an extra divide). Also, the divides should only have to happen once when the bitmap is loaded - a S&H just after stops them getting re-calculated during animation.
Could be done with a bitmap array of single strips I suppose, need to test to see how efficient the two methods are - but that would mean a lot more bitmap files to manage on disk when doing the design work.
Just need nice software to do X,Y matrices of frames - it's taking me an age to stitch together an example animation in photoshop, and the animation I want isn't suitable for doing in knobman - anyone know of software for this, or a photoshop script, maybe?

Anyway the whole X,Y things is probably is little off topic - I'll move it to another thread when I have something.