KVR Audio

mystran · Post by **mystran** » Thu May 26, 2011 3:55 pm

I'd have a fairly simple feature request.

Right now you can export vertical or horizontal strips. I'd like being able to export a grid like:

Code: Select all

 1 2 3
 4 5 6
 7 8 9

Doesn't matter if it's left-to-right or top-to-bottom first. I don't mind if I need to specify rows and/or columns either. If the specified frames don't actually fill the grid, those can be left blank (see below).

Reason is having a very wide (or tall) image is non-ideal for loading into a GPU texture, since many GPUs insist on power-of-2 dimensions (so eg 5000 pixels would get rounded to 8192) and some have annoying maximum size limitations (like max 2048 or 4096 or something). With grid-layout a texture of 1024x1024 could fit 256 frames for a 64x64 knob (or use less frames and have plenty of extra space to put other graphics into the same texture).

I can obviously split a strip manually, or export individual frames, and use some random texture atlas-tool to combine them, but from work-flow point of view it'd be cool if knobman could do it automatically.

mystran · Post by **mystran** » Thu May 26, 2011 4:34 pm

Oh, I just figured there's this other tool called NKnobMan that knows how to talk to Knobman and can do what I want and plenty of other cool stuff.

Nevermind then.

mystran · Post by **mystran** » Fri May 27, 2011 6:35 pm

I have a bug report (version I downloaded yesterday): if I have a line rotated from -140 to 140 degrees, and I specify 96 frames then 48th frame will have the line pointing exactly up. With even number of frames, there should not be a frame where the line points exactly up (each frame should be rotated by about 2,947 degrees, so 48th frame should have rotation of about 1,474 counter-clockwise, and 49th frame should have rotation of about 1,474 clockwise). I'd guess this happens with any sufficiently large even frame count.

While it might be useful to have a frame pointing exactly up when displaying individual frames, this behavior is annoying when one does blending through the frames; 0.5 maps to half-way blend between 48th and 49th frame, and exactly up is shown when the knob is slightly below half-way.

Quick work-around is obviously to ignore the last frame (so it's not exactly HUGE problem), but if this behavior can't be corrected, it would be nice to know the exact rotation calculation logic so one could instead modify the angles just enough to get the correct result. Basically, should I assume 280 total rotation means every frame is rotated 280/96 instead of 280/95? Or should I offset both end points down by half-frame? Or maybe something even more confusing?

g200kg · Post by **g200kg** » Fri May 27, 2011 8:05 pm

mystran wrote:I have a bug report (version I downloaded yesterday): if I have a line rotated from -140 to 140 degrees, and I specify 96 frames then 48th frame will have the line pointing exactly up. With even number of frames, there should not be a frame where the line points exactly up (each frame should be rotated by about 2,947 degrees, so 48th frame should have rotation of about 1,474 counter-clockwise, and 49th frame should have rotation of about 1,474 clockwise). I'd guess this happens with any sufficiently large even frame count.

While it might be useful to have a frame pointing exactly up when displaying individual frames, this behavior is annoying when one does blending through the frames; 0.5 maps to half-way blend between 48th and 49th frame, and exactly up is shown when the knob is slightly below half-way.

Quick work-around is obviously to ignore the last frame (so it's not exactly HUGE problem), but if this behavior can't be corrected, it would be nice to know the exact rotation calculation logic so one could instead modify the angles just enough to get the correct result. Basically, should I assume 280 total rotation means every frame is rotated 280/96 instead of 280/95? Or should I offset both end points down by half-frame? Or maybe something even more confusing?

hello

I'm a little confusing.
In my design, KnobMan will not generate exactly-up image for even number of frames. do you think this is not right behavior? or exactly-up image is generated for even number of frames in your test?

I think many people (me too) use KnobMan with the odd number of frames if the exactly-up image is needed.

WOK · Post by **WOK** » Fri May 27, 2011 9:34 pm

mystran wrote:I have a bug report (version I downloaded yesterday): if I have a line rotated from -140 to 140 degrees, and I specify 96 frames then 48th frame will have the line pointing exactly up.

I made a quick test with these values and the line is not exactly vertically.

mystran · Post by **mystran** » Sun May 29, 2011 9:03 am

g200kg wrote: I'm a little confusing.
In my design, KnobMan will not generate exactly-up image for even number of frames. do you think this is not right behavior? or exactly-up image is generated for even number of frames in your test?

Exactly up image was generated with -140 to 140 rotation and 96 frames. I'm confused as well if it works for you and WOK like I'd prefer it.

I need to test a bit more and see if there's some condition that triggers it.

The .knob file I had this problem with was originally from version 1.34, and it is possible it originates from even older version. I used to generate 101 frames for software rendering so I could have an exactly up frame (back before I added the frame blending), and this worked; maybe it's modified settings confusing knobman, I don't know.

Thanks for the reply though; at least now I know it SHOULD do what I want.

edit: ok this is funny; today I get different results from what I got yesterday, and now it seems to render right

mystran · Post by **mystran** » Mon May 30, 2011 11:08 am

Ok, I'm starting to think this must have been an user error. At a time I was really frustrated from trying to fight with DWM+Direct3D9 to work in MDI situation (eg FL Studio), and with GIMP with trying to save PNGs with premultiplied alpha (yes, PNGs are not supposed to be premultiplied, but making them so is still useful; convincing GIMP to do so is just a bit tricky).

For what it's worth, DWM+Direct3D9 just fails. Yesterday I rewrote the whole thing in OpenGL and it just works, even if it's my first OpenGL code ever. That's the only nice thing I'm going to say about OpenGL though; the API is horrible.

Knobman is probably doing what it should. I apologize for any inconvenience caused.

g200kg · Post by **g200kg** » Mon May 30, 2011 5:19 pm

cheers

kx77free · Post by **kx77free** » Thu Jun 02, 2011 8:28 pm

Hi,

Just to say you THANKS!!

I used your program for the Kx-Modulad and the Kx-Synth-x16 (Nova) and I will use it for my next plug-in.

Xavier

g200kg · Post by **g200kg** » Sat Jun 04, 2011 5:26 pm

Hi,

Now i have updated the KnobMan to ver 1.46

http://www.g200kg.com/en/software/knobman.html

New features:

* Style setting is added: that will easily switch the Set of layer visibilities and output image-size. this feature will help to maintain the variation of knobs by one knob-file.
* Texture file format: not only bmp, also support the png jpg gif files.
* Texture file offset is revised. the center of texure-image is automatically ajusted to the primitive's center.
* Added the 'Specular width' parameter to the 'metal circle' primitive.
* BugFix: Texture for 'Metal Circle' has not right effect. light/dark is exchanged.

Texture file offset revise will help making the circular texture. the example is below...
(this texture is attached to the package as name "Circle" )

pylorca · Post by **pylorca** » Mon Jun 06, 2011 7:21 pm

hi g200kg,

great softwate

v1.46 has a bug with visibility (eye icon) when you change the layer order. The visivility not changes the order, and layer loses the association with the visibility.

Cheers

g200kg · Post by **g200kg** » Mon Jun 06, 2011 9:45 pm

pylorca wrote:hi g200kg,

great softwate

v1.46 has a bug with visibility (eye icon) when you change the layer order. The visivility not changes the order, and layer loses the association with the visibility.

Cheers

hello,

Thank you for the report.
Just I've fixed:
http://www.g200kg.com/en/software/knobman.html

novaflash · Post by **novaflash** » Wed Jun 15, 2011 8:10 am

thanks for the update.

...and a very small remark, really not important, the app. icon have
not a transparent background, it will be cool for app. launcher like rocket-dock. As i have says, a detail

cheers,
Eric

EvilDragon · Post by **EvilDragon** » Sat Jun 18, 2011 10:20 am

Here's the icon I'm using for RocketDock:

Yeah it does look hacky, however I'm not using a REALLY BIG dock size - it looks just fine over here:

Thanks for the update g200kg![/img]

g200kg · Post by **g200kg** » Tue Jun 21, 2011 9:49 am

KnobMan 1.48
http://www.g200kg.com/en/software/knobman.html

* BugFix: The visibility not changes when adding/deleting layers.
* New parameter 'Shadow Type', selectable 'Spot' or 'Line'.
* Added a 'Line' type shadow sample 'LineShadow.knob'.
* KnobBrowser is updated. SkinMan's skin-file also be thumbnailed (for Vista or later).
* Added the KnobBrowser register/unregister button on the "File-Option" dialog.

Line type shadow sample. APNG-file, FireFox or Opera is needed for animation.

And the ICON background is now transparent

KnobMan, the VSTGUI AnimationKnob bitmap generator