Ruby Knob fully customisable

[RJHollins]

returning to the thread ...

I thought I figured the fix correctly ...

but one thing I noticed, its taking 2 clicks on the 'INIT' button to reset the knob pointer

[Nubeat7]

i found a better solution - when setting the midivalues directly befor the knob and switching between midival and knob val it is the most performant way, the "true on action" module sets interact to true on incoming MIDI signal and selects between knob value and midi value and the the value is not blocked at the interactswitch in the preset module

edit: look at the first post to get the latest vertsion!

[steph_tsf]

Thank you so much for those very nice knobs.
I have a FS schematic that's running okay, relying on standard FS knobs "static with gauge".
Unfortunately, when I replace all the knobs by the new nice knobs, the schematic is taking a very long time to load, leaving the component library (left side of the screen) empty for minutes. Clearly FS doesn't like those new knobs in my particular schematic.
As I'm not using MIDI, I reworked the new knobs, wiping out everything concerning MIDI.
The schematic loads now faster, however when there are seven MIDI-less new knobs on the schematic, FS remains in big trouble. The load time gets perceptible, and there appears to be a sync galore, about 50% CPU usage (windows taskmanager) without the audio enabled, with everything supposed to be idling in the schematic.
I am attaching three .fsm :
- FS schematic with the old knobs
- FS schematic with a few new MIDI-less knobs
- FS schematic with seven new MIDI-less knobs
I'm very curious to see what mistake I made, while reworking the knobs, suppressing everything relating with MIDI.

[steph_tsf]

I made a .fsm showing all knobs, connected to float displays, and nothing more. There should be no processing. Guess what : the CPU is a 50%. What's did I wrong ? See attached .fsm.

[RJHollins]

I'm seeing about a 12% CPU on TaskManager.

Is there an FS 'monitor' that can measure things like CPU usage ???

I'll be watching this thread ... sorry not to be of any help

[nix]

Yep, it's about 17% on my 4 core i7.
It's definitely a problem drawing them mate.
If you go inside of one to the main piece of code,
it will stop the CPU usage.
So it is a loop in your drawing,
but I could not find it,
It is really neat work IMO,
u deserve a pat on the back.

FS only monitors audio CPU consumption RJ,
task manager is accurate AFAIK

[MyCo]

@steph:
It's not the knob, that has the bug, it's your labels:

Code: Select all

def draw v
   ...
   redraw
end

You do a redraw in the draw... causing an endless drawing loop

[steph_tsf]

Indeed! When suppressing the draw call within the Draw, the trigger galore is gone.
Sadly, the Label and Readout fields are not anymore updated. The knob is thus kaput.

Let's look at the details. The trigger galore got inherited from the knob2.1 (Nubeat7).fsm posted above. Let's now address this in the details. Nubeat7 came with such arrangement for vertically appending the Label and Readout fields (considered as sub-View) at the bottom of the knob (considered as main-View, square sized corresponding to the knob footprint and nothing more). The result looks seductive. The knob footprint stays compact. There is no wasted empty space. Nubeat7 needed such Draw call within the Ruby code, for requesting the main-view to append something new, that just went computed (the label and Reaédout). Is my analysis correct?

I fixed the Trigger galore using a single portrait-sized View and a fixed v.height arrangement, not letting Ruby to vertically center the knob. The Trigger galore is gone. The double click "default" doesn't update the Readout, albeit the value gets correctly reset. Can somebody help ?

I'm attaching a few files as examples.

[Nubeat7]

thats crazy, thanks steph for figuring this out, for the readout update add "output 1, nil" to the mouseLDouble section and send the trigger to the s&h of the readout redraw limiter...

[Nubeat7]

@steph:
It's not the knob, that has the bug, it's your labels:

Code: Select all

def draw v
   ...
   redraw
end

You do a redraw in the draw... causing an endless drawing loop

the redraw have to be done after the draw methodes end

Code: Select all

def draw v
   ...
   
end
redraw

this also fixes the issue, or should i always call the event methode to do this, like this

Code: Select all

def event i,v
redraw 0
end

?? like you can find it in the stock label module