GDI - Interactive Fader and Knob controls

[Jardz]

Hi MattyD,

I may not be understanding your issue, but if the problem is not being able to guarantee the last value is captured for the labels, then here's my dirty work around.

Essentially, just repeat reading the last active message to ensure it's in sync.

Func Main()
    Local $iMsg = 0, $iMsgPrev = 0
    Local $bMsgRecv = False

    While 1
        $iMsg = GUIGetMsg()
        $bMsgRecv = $iMsg > 0 ? True : False

        Switch $iMsg
            Case $GUI_EVENT_CLOSE
                ExitLoop
            Case 0
                If $iMsgPrev Then
                    $iMsg = $iMsgPrev
                    $iMsgPrev = 0
                    ContinueCase
                EndIf
            Case Else
                If $bMsgRecv Then $iMsgPrev = $iMsg
                For $i = 0 To UBound($aChannel) - 1
                    Switch $iMsg
                        Case $aChannel[$i][1]
                            GUICtrlSetData($aChannel[$i][0], GUICtrlRead($iMsg))
                            ExitLoop

                        Case $aChannel[$i][2]
                            GUICtrlSetData($aChannel[$i][3], GUICtrlRead($iMsg))
                            ExitLoop
                    EndSwitch
                Next

        EndSwitch
        If $i = UBound($aChannel) Then VegasMode($iMsg = $hVegas)

    WEnd
EndFunc

 

 

[MattyD]

Thanks Jardz,

But that part should be ok - when we GuiCtrlRead, the value should be correct at that point in time. 

Its more that we're sending a message to the dummy control because the value has changed to x -  but by the time we read the control the value is already at y.
This is probably not the worst thing in the world - the read value is correct at that point, but its not particularly nice when you start flooding messages.

So if we send a sequence quickly because the values at: 1, 3, 7, 10, 11 ,14, 20 - our GuiCtrlReads could give us 7, 14, 20, 20, 20, 20, 20.

I think I might have a solution though to throttle the SendToDummys...

• On mousemove we do everything we'd normally do
  • but instead of a SendToDummy we set an internal flag that the control has changed.
     
• Then in our adlib function we check this flag, and fire the SendToDummy if need be.
  • If the delay on the adlib is comparable, or slower than GuiGetMsg(), things should (in theory) be relatively under control.

Using our example again, mousemove triggers: 1, 3, 7, 10, 11 ,14, 20. Now we're only triggering a SendToDummy at, say:  3, 10, 20. Now, its still technically possible for GuiCtrlRead to get behind - but for the most part it *should* be pretty good.

 

[MattyD]

Ok - a new file is up, changes are as follows:

•  I've throttled the SendToDummy messages as explained above.
•  Calling GuiCtrlSetData directly will no longer lead to a SendToDummy message. (This causes issues with the new notification behaviour).
•  A notification is no longer sent on control creation.
•  The adlib interval has been cut down again for the UpdateControls function. This now affects:
  • Fader reaction/update time when calling GuiCtrlSetData()
  • The polling interval of the control. if a change is detected, a SendToDummy() message is fired to notify the programmer.
•   Plugged more memory leaks when creating the bitmap sets.

[MattyD]

Another day, another update - new controls today!

LRKnobs
basically the same as a knob, but there is a center point maked on them.  
The name may change at some point, just unsure how to best describe them ATM.

Vertical and horizontal meters. 
These are to be used with GuiCtrlsetData(), but I just realised you can still set these with the mouse wheel 😒.  This will be fixed with the next update.

[MattyD]

Hi all,

I think we're getting to the end of this initial stage - so there may be a repreive from my spamming here soon! I just want to thank everyone again for their contributions in order to get this up quickly it really is appreciated.

It probably goes without saying - but if someone's actually planning on using this for audio where timing is more critical, bypassing those dummy controls might be a good idea. I'm happy to elaborate and/or provide an examples on how to do this if need be.

Anyway I digress...

A new file has been uploaded:

• You can no longer set a meter with the mouse wheel
• There is another new control - 7-segment display. 

The range of the 7-seg display is still 0 to 127, but each bit represents a segment..

• For example, everything lit up is: 1111111 binary (0x7F hex, 127 decimal)   
• And just 3rd & 5th would be:  0010100 binary (0x14 hex, 20 decimal)

As a cheat sheet the numerals 0 - 9 are:

0x3F, 0x06, 0x5B, 0x4F, 0x66
0x6D, 0x7D, 0x07, 0x7F, 0x6F

Happy coding!

 

[MattyD]

One more control today because we can, the 14-segment display .

For this one, the ascii code of a character will determine what lights up.  So GuiCtrlSetData($hLCD, Chr("A"))  will cause an "A" to show.

Because ascii codes lower than 0x20 are mainy non-printing I've thrown a few other symbols in that space.  Vlaues 0x01 to 0x08 for example may be used as a makeshift progress wheel. I've left  CR and LF alone though, so these codes just clear the display.

You'll find in the zip there are a couple of extra demo files that that demonstrate all possible states of the 7-segment and 14-segment displays.

[argumentum]

heheh, I can run "Vegas mode" all night.
Very nice demo.

[MattyD]

Hi all,

A couple of additions today.

ctrl + click a fader or knob to reset it to a default value.
shift + drag a fader or knob to make fine adjustments.

Default values can be set per-control with:
_GUICtrlGDI_SetDefaultValue($hWnd, $iValue)

Otherwise out-of-the-box default values are:
LR Knob/Horizontal Fader = 64
Vertical Fader = 100
All Else = 0