C++ - Keep thread running after delete instance

omen80

Hi,

I'm working on audio software at the moment which allows users to create their own audio plugins etc. Basically I need to figure how to keep something running after the plugin window has been closed. This will allow the user to re-open up the window and each component will adjust to the current position, as if it had never been closed. Make sense?!

For example...lets say I have a class Graphics and a class BackgroundThread.

I create an instance of Graphics which inherits BackgroundThread. When I close the window the instance of Graphics gets deleted. How can I keep BackgroundThread running, and also, how can I recreate the same instance of Graphics? Is this possible? Any advice is welcome.......

Thanks.

superluck

Could you not create BackgroundThread first and just pass an instance of this to Graphics each time you want to create a window?

Inside BackgroundThread class somewhere, do:

CGraphics *pGraphics = New CGraphics(this);

What are you using to handle events in the window? guessing that where you're having problems.
Maybe you only want to hide the window instead of destroy it? that might be easier.

instead of destroying, just hide/show depending on what action user takes.

Colonel Panic

Where are you creating the graphics and background thread instances? What code gets called when the window is destroyed?

srsly78

Just hide the window instead of destroying it.

You haven't even stated what platform this is for! We assume it's win32 -.-

omen80

srsly78 wrote: »

Just hide the window instead of destroying it.
You haven't even stated what platform this is for! We assume it's win32 -.-

I'm using the JUCE library, and trying to get it working on Windows at the moment. I can't hide the window as it gets destroyed by the host when exited. You probably have to understand a little about audio software to get this, but lets just say that it gets destroyed.


Maybe if I use a simpler example.....

I have a class Counter which displays an integer. I have another class BackgroundThread which uses a timer to increment an integer, so lets say it gets incremented by 1 every second.
If I create an instance of BackgroundThread in the Counter class, then that will get deleted once the instance of Counter is deleted, so I'm not sure if I need Counter to be derived from BackgroundThread instead?
How could I keep BackgroundThread running once the instance of Counter is deleted?

I want to be able to delete the instance of Counter, but the integer value would continue to increment. So when I recreate an instance of Counter, it will display the current value, and not 0.

Colonel Panic

Without seeing code, it would be tough to help you. If you can't hook into a a window closing event in JUCE and hide the window instead of exiting, it's not a very good framework.

Although that said, your problem is one of ownership. Why would a window own the background thread? Create the thread and pass a pointer or reference of that instance to the Window on creation.

There's no need to subclass anything.

omen80

Colonel Panic wrote: »

Without seeing code, it would be tough to help you. If you can't hook into a a window closing event in JUCE and hide the window instead of exiting, it's not a very good framework.

Let's just say for the sake of it that this is what I need to do. It's not that I can't access a "hide window" option in Juce, it's the host that will ultimately destroy it.

Colonel Panic wrote: »

Although that said, your problem is one of ownership. Why would a window own the background thread? Create the thread and pass a pointer or reference of that instance to the Window on creation.
There's no need to subclass anything.

I was using the window in my first example, which was a poor example! I'm actually developing a custom component which owns the background thread. When that component gets destroyed the background thread stops working.
But I think if I can solve my 2nd example with the counter I might be on to something....

kayos

I think Colonel Panic hit the nail on the head when he says the problem is one of ownership. Pass/Inject your objects to the window don't have the window create them.

I've not done c++ in donkeys so the below is speaking from a .NET point of view.

To use your simple example

The hosting application creates an instance of the counter class and then passes/injects this to the window that will display the information to the user. When the user closes the window your hosting application will still have the instance of the counter class and in turn the background thread. It will keep ticking away happily in the background. Next time the user wants to see the information you just pass it back to your window.

I could be completely wrong but that would be how I'd look at things.

omen80

kayos wrote: »

To use your simple example

The hosting application creates an instance of the counter class and then passes/injects this to the window that will display the information to the user. When the user closes the window your hosting application will still have the instance of the counter class and in turn the background thread. It will keep ticking away happily in the background. Next time the user wants to see the information you just pass it back to your window.

I could be completely wrong but that would be how I'd look at things.

I can follow your train of thought, but I'm not sure that it will work in this situation because Counter is a self-contained component with its own gui method. Actually what about if the host wrote the counter instance to an array after it is created? Then if it's deleted it could look in the array and get the previous instance? Or is that completely illogical?!

Thaks for all the help so far.....

Anima

Hey Omen,

I use JUCE a lot for audio apps. What exactly is your setup? Are you using AudioProcessor as the base of your plugin/component?

omen80

Anima wrote: »

Hey Omen,

I use JUCE a lot for audio apps. What exactly is your setup? Are you using AudioProcessor as the base of your plugin/component?

Yeah, I'm working with another guy on this and we use the AudioProcessor class for plugins. He was saying that I would probably need to use the getParameter() method for this situation but I can't really get my head around it. I'm trying to think of a simpler example at the moment so I can get my head around this! What do you suggest?

Anima

The usual architecture with audio plugins is as follows. The host will spawn an instance of of your plugin (AudioProcessor), using the createPluginFilter () method. You have to define this yourself somewhere, and JUCE will call it when needed. Usually it contains just (return new myPlugin;).

The AudioProcessor contains your audio callback which runs on a high priority thread, all the internal state and methods for the host to use to query the plugin for info.

The host can ask for the plugin GUI by calling createEditor() (defined in AudioProcessor). Your GUI shouldn't hold any state, it's just a view to the data which the plugin is holding. It should always request data from the AudioProcessor. When createEditor() is called it passes a pointer to the plugin also, so you have a means of communication.

The AudioProcessor is the only thing that is permanent for the duration of the plugin instance existence in the host. The editor will be created and destroyed often and there can be multiple windows spawned at a time.

It sounds like you wan't the AudioProcessor to inherit from the timer class and provide a callback to update a value that is local to the AudioProcessor instance. You can specify the interval time as you like.