KVR Audio

ddsl · Post by **ddsl** » Sun Nov 30, 2008 1:11 am

...

g200kg · Post by **g200kg** » Sun Nov 30, 2008 3:48 am

juha_p wrote:
ddsl wrote:Hi Juha

how many texture have you in texture dir of Knobman ?

Because when i put about one hundred of textures ( somes are about 1,5 Meg ) in the textures dir, i have quite the same problem. KM takes about one or two minutes to load (Athlon64), perhaps even more. With same 99% cpu usage and quite same memory usage : 100 meg.

when only 30 or 40 pics in this directory KM load well.

An idea g200kg ?

I can confirm this. I have ~100 textures (total ~105MB). When I move most of those to another location, KM starts working w/o issues.

Juha

Great, ddsl

it seems good to adding a splash screen and a progress bar?

Art60 · Post by **Art60** » Sun Nov 30, 2008 7:51 am

g200kg wrote:it seems good to adding a splash screen and a progress bar?

It depends on the need you have to browse those textures at program start !
Do you really need to ?

Regards.
Arthur.

ddsl · Post by **ddsl** » Sun Nov 30, 2008 2:12 pm

Art60 wrote:
g200kg wrote:it seems good to adding a splash screen and a progress bar?
It depends on the need you have to browse those textures at program start !
Do you really need to ?

Regards.
Arthur.

+1.

i've noticed that when i delete all textures from dir, KM install restarts and put missing textures in textures dir. Is KM browse this dir to check if those textures are present ?

duncanparsons · Post by **duncanparsons** » Sun Nov 30, 2008 3:00 pm

If the texture check is needed, could it be done in a separate thread, and if textures are requested, the request is only honoured when a flag that the scan is complete?

So if you have 100s of textures and load a .knob which uses some, the controls are disabled and a messagebox appears that says 'You are trying to open a file which uses a texture; Knobman is currently processing the available textures - your file will complete loading shortly.'

When the thread completes it fires an event which re-enables the controls and maybe fires a system asterisk sound to alert the user that work can continue.

That means that if you load KM and start work, you won't be impeded by the scan...

Just an idea

DSP

g200kg · Post by **g200kg** » Sun Nov 30, 2008 4:21 pm

Arthur, ddsl, DSP,...

okok, my suggestion of a slipshod work has been rejected

probably improved in next release (collect only names at start, file read at actual use).

gunnare · Post by **gunnare** » Sun Nov 30, 2008 4:36 pm

I have just started to use Knobman. Sent donation today.

sinkmusic · Post by **sinkmusic** » Sun Nov 30, 2008 4:45 pm

G200k, have you seen my question above about SkinMan not starting properly ?
I don't understand what's going wrong

Leslie Sanford · Post by **Leslie Sanford** » Sun Nov 30, 2008 7:29 pm

Gotta major problem, and I don't know if it's KnobMan/SkinMan's fault or not.

I set my DPI setting to 120 or so to test out some graphic bugs I was having with some of my plugins. I decided to leave it at that setting. Then I began working on rendering the graphics in SkinMan and KnobMan for my delay plugin. I compiled my program and uploaded. All of this done with my system still set to 120 DPI.

I immediately started getting bug reports related to the graphics.

After looking at my code and not finding a problem, I lowered my DPI setting back to normal and re-rendered the graphics in SkinMan/KnobMan. I compiled a new version of the plugin, and everything seems to work ok now.

Any clues?

g200kg · Post by **g200kg** » Sun Nov 30, 2008 10:35 pm

sinkmusic wrote:G200k, have you seen my question above about SkinMan not starting properly ?
I don't understand what's going wrong

sorry, a little confused.

is that a problem of SkinMan(NOT combination with KnobMan)?

anyway, please try
* delete the 'SkinMan.ini' file
* delete the Texture folder

next, how about the CPU/Memory usage by TaskMgr?

sinkmusic · Post by **sinkmusic** » Sun Nov 30, 2008 10:50 pm

g200kg wrote:is that a problem of SkinMan(NOT combination with KnobMan)?

Yes, KnobMan is NOT involve in that (despite being a KnobMan thread, sorry about that).

g200kg wrote:anyway, please try
* delete the 'SkinMan.ini' file
* delete the Texture folder

If i delete the 'SkinMan.ini' file + the Texture folder, it works fine again.

thanks

g200kg · Post by **g200kg** » Mon Dec 01, 2008 2:34 pm

Leslie Sanford wrote:Gotta major problem, and I don't know if it's KnobMan/SkinMan's fault or not.

I set my DPI setting to 120 or so to test out some graphic bugs I was having with some of my plugins. I decided to leave it at that setting. Then I began working on rendering the graphics in SkinMan and KnobMan for my delay plugin. I compiled my program and uploaded. All of this done with my system still set to 120 DPI.

I immediately started getting bug reports related to the graphics.

After looking at my code and not finding a problem, I lowered my DPI setting back to normal and re-rendered the graphics in SkinMan/KnobMan. I compiled a new version of the plugin, and everything seems to work ok now.

Any clues?

hello, i have confirmed.
the DPI information is embedded to the exported images from KnobMan (for examples the .bmp file, the parameters are biXPelsPerMeter, biYPelsPerMeter). but it might be expected that almost applications ignore this info.

how did you use the exported images?

Leslie Sanford · Post by **Leslie Sanford** » Mon Dec 01, 2008 2:42 pm

g200kg wrote: hello, i have confirmed.
the DPI information is embedded to the exported images from KnobMan (for examples the .bmp file, the parameters are biXPelsPerMeter, biYPelsPerMeter). but it might be expected that almost applications ignore this info.

how did you use the exported images?

Hi g200kg.

I embedded the exported images into a Visual Studio resource file. The resource file is compiled with my plugin. Within my plugin I use the Windows GDI+ API for loading the image data and drawing them to the user interface.

Perhaps there's an option in GDI+ for ignoring DPI information. I'll research it.

g200kg · Post by **g200kg** » Mon Dec 01, 2008 11:16 pm

Leslie Sanford wrote:
g200kg wrote: hello, i have confirmed.
the DPI information is embedded to the exported images from KnobMan (for examples the .bmp file, the parameters are biXPelsPerMeter, biYPelsPerMeter). but it might be expected that almost applications ignore this info.

how did you use the exported images?
Hi g200kg.

I embedded the exported images into a Visual Studio resource file. The resource file is compiled with my plugin. Within my plugin I use the Windows GDI+ API for loading the image data and drawing them to the user interface.

Perhaps there's an option in GDI+ for ignoring DPI information. I'll research it.

In my understanding,
DrawImage(img,x,y) will be affected by DPI.
DrawImage(img,x,y,img->GetWidth(),img->GetHeight()) is independent from DPI.

Leslie Sanford · Post by **Leslie Sanford** » Tue Dec 02, 2008 12:00 am

g200kg wrote: In my understanding,
DrawImage(img,x,y) will be affected by DPI.
DrawImage(img,x,y,img->GetWidth(),img->GetHeight()) is independent from DPI.

Aha! This explains why some of my controls looked correct and others didn't. For example, my knobs used DrawImage(img, x, y) and my switches used one of the other overrides. So the knobs looked too small but the switches looked the right size:

Image supplied by Reverse Engineer on my delay thread over on the Effects forum.

I've changed my code accordingly.

Thanks for the information.

KnobMan, the VSTGUI AnimationKnob bitmap generator