|
|||
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: 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. |
|||
| ^ | Joined: 11 Feb 2006 Member: #97939 Location: Helsinki, Finland | ||
|
|||
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. |
|||
| ^ | Joined: 11 Feb 2006 Member: #97939 Location: Helsinki, Finland | ||
|
|||
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? |
|||
| ^ | Joined: 11 Feb 2006 Member: #97939 Location: Helsinki, Finland | ||
|
|||
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. |
|||
| ^ | Joined: 22 May 2004 Member: #26536 Location: Yokohama, Japan | ||
|
|||
| ^ | Joined: 24 Feb 2004 Member: #13779 Location: Germany | ||
|
|||
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 |
|||
| ^ | Joined: 11 Feb 2006 Member: #97939 Location: Helsinki, Finland | ||
|
|||
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. |
|||
| ^ | Joined: 11 Feb 2006 Member: #97939 Location: Helsinki, Finland | ||
|
|||
cheers |
|||
| ^ | Joined: 22 May 2004 Member: #26536 Location: Yokohama, Japan | ||
|
|||
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 |
|||
| ^ | Joined: 19 Jul 2005 Member: #75331 Location: Paris | ||
|
|||
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" ) ![]() |
|||
| ^ | Joined: 22 May 2004 Member: #26536 Location: Yokohama, Japan | ||
|
|||
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 |
|||
| ^ | Joined: 06 Sep 2009 Member: #214896 | ||
|
|||
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 |
|||
| ^ | Joined: 22 May 2004 Member: #26536 Location: Yokohama, Japan | ||
|
|||
| ^ | Joined: 21 Nov 2003 Member: #10518 Location: Mars, Solar System | ||
|
|||
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] |
|||
| ^ | Joined: 06 Jan 2009 Member: #197719 Location: Croatia | ||
|
|||
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 |
|||
| ^ | Joined: 22 May 2004 Member: #26536 Location: Yokohama, Japan |
| KVR Forum Index » DSP and Plug-in Development | All times are GMT - 8 Hours |
|
Printable version |
Disclaimer: All communications made available as part of this forum and any opinions, advice, statements, views or other information expressed in this forum are solely provided by, and the responsibility of, the person posting such communication and not of kvraudio.com (unless kvraudio.com is specifically identified as the author of the communication).
Powered by phpBB © phpBB Group










