Time Display in Global Rackspace

I have managed to stop the timer but it is only temporary. If you open the options/scripting window, the clock will stop. Change nothing and close the window. The clock will have stopped, this is understandable as you may have changed options. But when I recompile the script, it starts to run.

The timers aren’t restarted automatically after going to any of the possible option-tabs.

I devised a way to restart them (in global and/or local rackspace), using system actions. If you’re interested, I can look it up and upload an demo gigfile.

OK… I was able to get it working and even did a little bit of customizing to the time format. (Lots of trial and error… really had no idea what I was doing. :laughing:)

Here is the script I ended up with. It is based on the script from the other thread that originally put the clock on a local rackspace. Changed my computers system clock a couple times and the clock in global rackspace didn’t miss a beat. Everything seems to be working as it should.

Thanks for all your suggestion and patience!

Now to integrate into my working gig file. :grinning:

var lbl_time : widget

// Called by timer ticking
On TimerTick(ns : double)
    lbl_time.SetWidgetLabel (FormatTime(ClockTime(), "%l:%M:%S %p"))
End

// Called automatically after script is loaded and after compile
Initialization
    SetTimersRunning(true)    
End

1 Like

Looks good, but keep in mind there is cpu usage.
So every some milli seconds the widget is refreshed.

Your script actually crashes my GP4.7, I will tweak the script so that it runs on my setup, than ask if you can test it. As @pianopaul says, it will be burning CPU cycles, that is probably what made it crash on my i5 Win 10 machine.

I promised to upload a gigfile with a possible workaround for timers not restarting after showing the options dialog. This gigfile holds a fix for timers in the Global rackspace and for timers in the local rackspaces(s) as well. The script itself only focuses on the restart of the timer. For demo purposes there is a blinking led, but you can delete that, because that’s not what you’re after.

TimerIssue.gig (90.2 KB)

Can you please attach the crash log?

Please try this script, it should limit the CPU cycles.

var lbl_time : widget
var str_format : string = "%H:%M:%S"    // Format of the clock display

var nextnS : double = 0

// Called by timer ticking
On TimerTick(ns : double)
    if ns > nextnS then
        lbl_time.SetWidgetLabel (FormatTime(ClockTime(), str_format))
        nextnS = ns + 200
    End
End

// Called automatically after script is loaded
Initialization
    SetTimersRunning(true)
End

Crash Report has been sent. I suspect it is just lack of CPU grunt.

// This crashes my Win10 i5
var lbl_time : widget

// Called by timer ticking
On TimerTick(ns : double)
    lbl_time.SetWidgetLabel (FormatTime(ClockTime(), "%l:%M:%S %p"))
End

// Called automatically after script is loaded and after compile
Initialization
    SetTimersRunning(true)    
End
// This runs on my Win10 i5
var lbl_time : widget
var str_format : string = "%H:%M:%S"    // Format of the clock display

var nextnS : double = 0

// Called by timer ticking
On TimerTick(ns : double)
    if ns > nextnS then
        lbl_time.SetWidgetLabel (FormatTime(ClockTime(), str_format))
        nextnS = ns + 200
    End
End

// Called automatically after script is loaded
Initialization
    SetTimersRunning(true)
End

The first one works fine on my 2019 Intel laptop

That said, if the main GUI thread gets too busy, throwing lots of GUI messages at it isn’t going to work very well

Spav,

The version you did that limits CPU cycles works great! The only issue I had was the one you mentioned earlier where going into options windows stopped the time clock. I swapped out the Initialization call to the original one that kickstarts it with a rackspace change. I have integrated it into my master gig file and everything seems to be working well. I have 3 gigs this weekend, so I will update if any problems arise.

Thanks again for all the help and advise! This is what makes this community AMAZING!

Here is the version that i have working right now:

var lbl_time : widget
var str_format : string = "%l:%M:%S %p"    // Format of the clock display

var nextnS : double = 0

// Called by timer ticking
On TimerTick(ns : double)
    if ns > nextnS then
        lbl_time.SetWidgetLabel (FormatTime(ClockTime(), str_format))
        nextnS = ns + 200
    End
End

// Called when rackspace is activated
On Rackspace(oldRs : Integer, newRs : Integer )
    If !GetTimersRunning() Then
        SetTimersRunning(true)
    End
End

This works for local rackspaces, but not for the global rackspaces. If you don’t need that: no problem. If you do need it: In the gigfile I uploaded there’s also a workaround for that, using the system actions plugin

I wonder why do you need this inside Gig Performer? I’d never use this in a plugin host.

You have a wonderful portable application in Windows called DesktopClock (available on GitHub, MIT license).

You can create customizable desktop clocks in various formats, color, size, transparency, etc.

–

If you need the battery info → LINK

–

Using tiny portable applications have the most sense for these use cases.

Well, some like to run full screen. Also, if you have a widget displaying a clock, you can make it appear on an OSC device like Lemur as well.

1 Like

You have the “Always on top” feature and can place it even outside the panel area.

As for the OSC, I believe that Lemur can set time inside itself (it doesn’t need Gig Performer to send it time).

Well, Lemur is hardly the only OSC app out there.

That breaks immediately if you are not running GP full screen and you move or resize the GP window – now you have to keep readjusting your separate clock display

More generally, you can’t assume that a clock is the only thing one might want to display. Indeed, in just the example above, the user has nicely placed a clock and a tempo label, cosmetically matching, beside each other. Adjusting the size of GP window will still keep those aligned properly. That won’t work well with a separate clock application.

One can also easily imagine other kinds of “dynamic” timing to be displayed, such as a timer showing the amount of elapsed time for each song as you play them.

OK, we have different views on this.

Whoever wants an alternative solution using simple portable apps – it’s here :slight_smile:

There is an old saying, “If we agreed on everything, some of us wouldn’t be necessary.” :grinning::grinning::grinning:

2 Likes