What would be the best way to use a timer (with callback function) in a (C++) Extension?
In GP Script, there is the function On TimerTick, or even a generator can be used.
Is there an alternative inside the extension SDK? Or should I use a Windows/Win32 timer? (I might get into problems with threads possibly).
When you create an extension, you have access to the full power of your operating system. You can create your own threads, timers, GUI components, networking, general file handling and so on.
The GP-SDK is solely intended to access functionality unique to GP such as access to widgets, plugins, some control (switching rackspaces, songs, etc), starting or stopping the play head, etc. But thereās nothing special about timers.
It is not intended to be a library or wrapper that exposes full OS functionality.
If you want an easy way to create timers, threads, OSC or other things that are not specific to gig performer, then use a library like JUCE which exposes those kinds of things and wraps OS functionality in a way that allows it to be cross-platform.
By the way, I was looking at the code to see why we didnāt expose parameter change callbacks to date and the reason is because those changes can happen inside the audio processing block. Exposing that to an extension directly is very dangerous as even the slightest delay in handling them will immediately cause audio glitching. In the short term, Iām considering optionally making them available by pushing the messages into the GUI thread (also not inexpensive) and will slow GUI response time if there are a lot of parameter changes. I may consider using a separately buffered object on another thread but even that will require the SDK developer to be very careful to avoid locking that buffer and basically killing audio.
Thank you for your elaborated answer and comments.
I understand that the SDK is only for GigPerformer, but better asking before than finding out there is a different (better) solution. Itās some time ago I used timers on Windows, so something to dive into (probably enough examples to be found).
I will first try a ānormalā WIndows method, maybe later going to check into JUCE. Also, for me being cross platform compatible is not a must.
I requested for the parameter callback functions, as you said in principle all GP script functions are easy to port to the SDK (btw, I meanwhile found some others, but I will make a list or a single thread out of it later, that might be easier). For my use case, MAYBE I can do without parameter callbacks, as I used them for the Insert Piz Here AudioToCc plugin, but it also works via MIDI ā¦ on the other hand, this might also cause a performance penalty, but in about two months I hope to have my extension finished in such a way I can do some performance testing.
On the other hand, I think it wouldnāt matter if the extension handles the parameter callback functions, or a GP script ā¦ or are they handled differently regarding thread usage?
Also, next week I will reserve a few hours for beta-testing, because npudar is right that I (also) should focus on beta testingā¦ I am just so much in the flow of writing the extension (I probably will reach over 10K lines when all is finished). And happy to share it for everyone (although it will be quite hardware specific), although the framework is generic.
Before you go much further,I would strongly encourage you to take a look at using JUCE (and thereās already an example project to get you started). Beyond the value of being cross-platform, JUCE has a huge collection of classes for building applications and libraries. Youāll save yourself a lot of time.
For example, using a normal Windows method, you have to do stuff like this
whereas in juce with a lambda you can just write
Timer::callAfterDelay(10000, []()
{
// process a 10-second timer
}
);
ā¦no need to have handles to windows, timer identifiers, and so forth.
Just my two cents
I think it might even be more complicated, as there is no default loop to check messages, I cannot make a loop in a callback function from GP, and doing it in another thread might result in other issues (data handling between threads).
I think this is indeed the way to go, I will finish a part Iām busy with next week and then check into JUCE; most of my code will probably still not have to be changed.
Also later, I might want to use OSC messages. Or maybe in time a dedicated UI, although I like the GP builtin widgets a lot.
FYI:
There is a possibility to use null for the windowshandle, but it is not very clean.
This is the windowless/message-less version:
Thanks for that solution, however, I think I will try first the JUCE solution, as it has more features I might want to incorporate later when needed (like OSC messages). Or even another (G)UI.
@dhj Thanks for mentioning Juce ā¦ it took a bit of timing getting both the extension and the test project compiling, but they compile (testing in GP I will do later). Setting a timer is super easy in Juce 
And now your extension can be cross platform! 
True ā¦ I will make file I/O implementation somewhere in 1 to 2 weeks from now, using JUCE so that also will be cross platform.
The only disadvantage for most is, that my extension is heavily based on some specific hardware (MIDI oxygen 61, or at least a MIDI keyboard with 9 knobs, 13 buttons), a secondary keyboard, and a MIDI foot pedal with (at least 5) switches and 2 pedals. It will probably be quite some work to make this so flexible any hardare can be used, but in the end, but I will do my best to describe the structure so people can change/adapt it for their own use, if they want.
Resurrecting this thread to see if you found a relatively simple way to do this with JUCE.
I started down this path several years ago and decided the complexity of integrating JUCE into my coding and building process was more effort than it was worth. I was willing to live without that functionality.
Iām writing a different extension now (for the iCon P1-M control surface) and am running into an issue where there is some minimal time required to wait between refreshes of the āsoftbuttonā display. Iām not going to do it in a way thatās not cross-platform, so Iām hoping for an example where somebody has already done this in a GP extension.
How much time are you talking about? Are you on a thread? You could just use the juce Thread::sleep function
For this particular case I would try something like 100ms minimum time between updates and go from there. I donāt currently have a mechanism to test the limit.
There are other ānice to haveā things I could do with a timer-related callback (such as display a message for 3 seconds, then clear it) but not really necessary.
While I know what a thread is from a user perspective, I have literally zero knowledge about coding with threads. The extensions Iāve written are all purely reactionary. They do nothing until GP invokes the callbacks that theyāre listening for.
I infer from the way this works that they operate on a single thread.
I donāt think Iād want to use a sleep function (assuming that halts everything for the specified time) because that could potentially lead to a buildup of messages and unacceptable delays in control responses.
In practice the reality is that GP can produce quite a few callbacks in pretty short periods of time (probably just a few milliseconds apart) that can each call for different updates of a control surface item or display.
Example: user switches into setlist mode. We get a callback for OnModeChanged followed by a callback for OnRackspaceChanged or possibly OnVariationChanged. This effects the state of numerous widgets, which produce callbacks of their own.
If weāre trying to keep the text display of a control surface up to date with the state of things - which may include setlist mode, active song name, songpart names, and the state and names of which widgets are being displayed for the underlying rackspace and variation, we can end up with a rapid sequence of updates being sent to the control surface.
The only cases Iāve run into (thus far) where this is problematic are for text displays on controllers. Some will simply drop everything, or produce gibberish on the display, if you send two display sysex messages too close together, even if theyāre only a couple hundred bytes.
Iām just a coding hobbyist, so Iām open to other suggestions, but my thought on using a delay callback here is that Iād build and maintain the display data in a persistent structure. Iād update that structure appropriately for each GP generated callback, but wouldnāt send it to the device more than once every (arbitrarily) 100 ms. Various callbacks might update it 5 times in that 100 ms, but only the current state would be sent at the end of that period.
I think the āUpdateDisplayā function would have to track when it was last sent, and produce the callback request if it needed to wait a while to send the next update.
Simply skipping the sending of the sysex and waiting for the next callback (of any type) to refresh the display doesnāt really work because in normal use the extension could go a very long time without receiving another callback.
I donāt know what the extension is supposed to do, but assuming youāre only interested in doing an update with the latest data, you could follow this pattern:
This way thereās no build up. (BTW, this is the way the Envelope Follower works).
This pattern wonāt work directly if you need to process also all intermediate updates. Then youād have to use a queue which is processed at the right interval. As long as there is no audio being processed on the producer thread, you can use a regular queue. Memory allocations shouldnāt be a problem. Otherwise you should use pre-allocated circular buffer which must be large enough to hold all updates that might build up.
Itās a control surface extension.
I think your suggestion is similar to what I am thinking, with the caveat that the majority of the duties of the extension remain event-driven, but maybe I only update the text display every 100ms (or whatever) and only if something to be displayed has changed.
If a user touches an item on the control surface (fader, knob, button, jog wheel) it must react as quickly as possible to take the appropriate action through a GP function call. (eg, change a widget, change rackspace, etc.)
If GP reports a change that should be reflected on the control surface (e.g., a widget value changed, song changed, etc.) it should be reflected as quickly as possible on the control surface.
For the most part Iāve written these extensions as āstatelessā. They retain no knowledge of widget or control surface states. They react purely to events, which means that 99%+ of the time they do nothing.
From a general design standpoint I think it would be less practical to do it on a polling basis because the only reason to poll would be to discover a change that already happened.
My thinking - when you play a note on your midi keyboard you want it played when you play it. You donāt want to wait 50 milliseconds until the keyboard is polled. If your keyboard also has an LCD text display that reports the last four notes played, but it turns to gibberish if you write to it more than once every 100 ms, then that needs to be handled differently.
I could definitely section off the text display routine and only update that every 100 ms or so, and only if something on the display changed.
If I was doing this in GP Script Iād just use a Generator callback. For reasons dhj mentioned early in this thread that functionality isnāt available through the external API. I think JUCE is probably the way to do that (based on this thread). Iām hoping somebody has a GP example using the external API.
EDIT - @rank13 seems to do something instructive through JUCE in his GP-Hud extension. This wonāt be the first thing Iāve pilfered from him (if i can figure it out).
Juce is quite a good framework to use and cross platform. If you need a simple timer you just need to have a class āinheritā from juce::timer and implement timerCallback(). You can start the timer with startTimer(ms) an stop it with stopTimer(). But I guess you already found that, so Iāll stop showing off 
Have you considered using the juce:
:callAfterDelay method which uses a lambda?
You can just write things like this:
juce::Timer::callAfterDelay(100, [this]
{
// Any code here will be triggered 100 milliseconds later
}
);
I very much appreciate those thoughts, and they give me a place to start. However, I canāt overstate how little I actually understand any of this stuff. I have no idea what āinheritā, āmethodā, or ālambdaā mean in this context, but google can be a pretty good teacher.
For reference, Iāve opened the in-progress code up publicly at WidnerM/GP-P1M: GigPerformer extension for the iCon P1-M controller.
At the top of the file P1Routines.cpp is the function SendSofbuttons(). Iām thinking as a first step I just put that in a timer routine to run every 100 ms. I just added a skeletal DelayCallback.cpp file where Iāll try to add that. I borrowed that snippet from @rank13 but Iām trying to work through his code and figure out how to do it outside the context of JUCE popup windows and such.
Iāll try to give you primer on this, although it is more suited for a training course and I do not make a good instructor 
The idea of inheritance is that particular sets of ābehaviorā and āpropertiesā are not limited to one object but are more general. For and example, letās look at pets. For the sake of clarity, Iāll assume that the only pets are cats and dogs (otherwise it will get too complicated). General behaviors of these pets are eating, moving, making sounds, showing affection. General properties are fur-type, tail-length, ear-shape, healthiness. You could create to separate objects ācatā and ādogā, but then you would repeat the same stuff a lot. Also it would be nice you could take some pet (dog or cat) to the vet instead of explicitly take a dog to the vet or a cat to the vet. Thatās where inheritance can be nice:
Iāll try to do some pseudo object description language:
pet:
// Behaviors
doEat
doMove
doMakeSound
doShowAffection
// Properties
furType // Curly, Straight, Bald
tailLength // In inches
earShape // Pointy, Rounded
isHealthy // Yes/No
cat (is a pet): // Inherit from pet
doEat
digest cat food
doMove
walk without the nails making a sound
doMakeSound
perform meow
doShowAffection
give headbutts
dog (is a pet): // Inherit from pet
doEat
digest dog food
doMove
walk with ticking nails
doMakeSound
bark
doShowAffection
lick
In the above example, you can see the set of behaviors and properties are the same for both cat and dog, but the actual way the behaviors work are differently āimplementedā
The power of this is shown by this:
pet myPets[3]
pet.add(new dog)
pet.add(new cat)
pet.add(new cat)
for(pet somePet in myPets)
somePet.doMakeSound
In this example while iterating through the array of myPets each pet will make its distinctive sound, due to their implementation.
In c++ it would look like this:
class pet
{
public:
virtual void doMakeSound() = 0;
virtual void doShowAffection() = 0;
int tailLenght = 0;
bool isHealty = true;
// ...
};
class cat: public pet
{
cat(int tailLength /*, other properties */)
void doMakeSound() override
{
// Play meow-wave
}
void doShowAffection() override
{
// Show picture of cat doing headbutts
}
// ...
};
class dog: public pet
{
dog(int tailLength /*, other properties */)
void doMakeSound() override
{
// Play bark-wave
}
void doShowAffection() override
{
// Show picture of dog licking face of boss
}
// ...
};
void main()
{
pet myPets[3] = {dog(10), cat(0), cat(7)};
for(int x = 0; x < 3; ++1)
myPets[x].doMakeSound();
}
( I didnāt compile it, so it could be not completely syntactically right)
In the above examples doShowAffection, doMakeSound and so on are called āmethodsā. Play bark-wave, Play meow-wave, Show picture [...] and so on are the implementations of the methods āinheritedā from pet. The lines class cat : public pet and class dog : public pet express that inheritance.
In a class, if you need to refer to the instance a method is currently working for, you can use the word this. So letās apply this to the pet example:
class vet
{
public:
void curePet(pet thePet, boss itsBoss)
{
// Do something that hopefully cures the pet
sendBillToBoss(itsBoss);
}
// ...
};
class boss
{
public:
vet myVet;
void checkPet(pet myPet)
{
if(!myPet.isHealty)
myVet.curePet(myPet, this);
}
};
In programming languages you have various types of variables like int, long, string and so on. Wouldnāt it be nice if there would be a type of variable that could be assigned a function of function body so that later on you could call that variable to execute that function? Pseudo language:
function makeSound;
void main()
{
makeSound = { setVolume(100); playWaveFile(1); }
makeSound();
makeSound = { setVolume(50); playWaveFile(7); }
makeSound();
makeSound = { switchOnTelevision(true); }
makeSound();
}
A lambda takes this idea to a higher level: You assign a function-body, but you can have it operating in the context of what is accessible (with regards to variables) at time you assign the lambda. Here is a snippet showing that:
void lambdaDemo(String text)
{
myText = text;
String someTitle = "Show data from MainComponent";
juce::Timer::callAfterDelay(3000,
// Lambda starts here
[this, someTitle] // List of variables that the body has access to
{ // Body of the lambda
juce::AlertWindow::showMessageBox(AlertWindow::AlertIconType::InfoIcon, someTitle, myText);
} // End of the body
); // This belongs to `juce::Timer:callAfterDelay(...)`
someTitle = "This title will not be show";
}
myText is a string variable defined in the class MainComponent. Because this is in the list of variables, the body can access it. The variable someTitle is a local variable, but also seems available to the lambda body, even while the function has already exited, but actually it gets a copy.
I hope this did explain some things and I didnāt confuse things any further (āI would have understood it, if he wouldnāt have explained itā 
);
Here is a simple juce 7.0.12 project showing the juce::Timer inheritance and the lambda:
GUIOnly.zip (17.0 KB)
Disclaimer
There may be errors in terminology, syntax and explanations. Also the demo project may contain errors (although it compiles and executes fine on my system)
Thank you, Frank. Thatās definitely helpful, and I appreciate you taking the time to write it out. Coming from coding in plain old ācā there are a lot of things that arenāt familiar or intuitive.
Where Iām still getting stuck is that my starting point is a couple thousand lines of code thatās already completely functional as a GigPerformer extension that doesnāt use anything from juce. All I need to add from juce is Timer::timerCallback() functionality, which needs to send midi sysex through the GigPerformerAPI.
Letās use your lambdaDemo (String text) example above, but modified to send a midi message through the GigPerformer external API. I think it would look something like:
void lambdaDemo(std::string text)
{
std::string device;
gigperformer::sdk::GPMidiMessage midimessage;
juce::Timer::callAfterDelay(3000,
// Lambda starts here
[this, device, midimessage]
{ // Body of the lambda
gigperformer::sdk::GigPerformerFunctions::sendMidiMessageToMidiOutDevice(device,midimessage);
} // End of the body
);
}
That wonāt compile with the error āāthisā can only be used as a lambda capture within a non-static member functionā, and the stuff in the GigPerformerAPI isnāt static.
I need the GigPerformerAPI functions to send the midi. Maybe Iām missing something fairly basic in how Iām declaring things, but thatās the roadblock I keep running into.