emit a signal from inside a callback routine

[JohannesMunk]

In which part of the code I have to write the QObject::connect?

Any. I suggest where you create the sounddata. If your sounddata is more generic than just data being played back, I suggest to set it up when you prepare it for playback. But then you will have to remove the connection after playback ended, to avoid multiple connections, when you play it back again. I don't know enough about the layout of your program to help you here..

BTW: As the connect function is a static function of the QObject class, you only need to write "QObject::" in front of connect, if you are outside a QObject class.. Inside you can just write "connect(..)". But I showed you QObject::connect .. to underline that you can call this from everywhere.

In that case ( a signal emitted by a callback ) I have to specify the Queued connections flag right?

That depends on your callback library. Some execute the callback within the thread context of your application (synchronized) and some don't (async). Perhaps you can specify that when you set the callback. When the callback is already synchronized it doesn't make a lot of sense to go through qt's message system again (=>direct connection). Unless the callback needs to return very quickly and you want to do something big in your connected slot. If the callback is called asynchronously (in the threadcontext of the libraray) and you want to access GUI elements or something else that is not thread safe, you have to go for the Queued connection.

Just try both options.. and see what works for you.. Or specify nothing and let qt decide. Qt decides upon matching thread contexts. Which should work just fine here.

Cheers!

Johannes

[franco.amato]

Any. I suggest where you create the sounddata. If your sounddata is more generic than just data being played back, I suggest to set it up when you prepare it for playback. But then you will have to remove the connection after playback ended, to avoid multiple connections, when you play it back again. I don't know enough about the layout of your program to help you here..

BTW: As the connect function is a static function of the QObject class, you only need to write "QObject::" in front of connect, if you are outside a QObject class.. Inside you can just write "connect(..)". But I showed you QObject::connect .. to underline that you can call this from everywhere.


That depends on your callback library. Some execute the callback within the thread context of your application (synchronized) and some don't (async). Perhaps you can specify that when you set the callback. When the callback is already synchronized it doesn't make a lot of sense to go through qt's message system again (=>direct connection). Unless the callback needs to return very quickly and you want to do something big in your connected slot. If the callback is called asynchronously (in the threadcontext of the libraray) and you want to access GUI elements or something else that is not thread safe, you have to go for the Queued connection.

Just try both options.. and see what works for you.. Or specify nothing and let qt decide. Qt decides upon matching thread contexts. Which should work just fine here.

Cheers!

Johannes

The callback is executed when a playing file finish to play.
In this case I have to stop a QTimer that I use to determine the "pcm position" within the
audio data ( this to move a timeline ). So I think is not necesary to remove the connection. Because if a file is not playing the callback is never called. ( how I remove a callback?? ).

I don't exactly know if the callback is sync or async, I have to ask to the fmod community for that.
If is async I have to use the Queued connections flag right?

Thank you

[JohannesMunk]

You didn't get me.

If you set up the signal slot connection whenever you START playing the sounddata on an Audiodevice there will be multiple signal-slot-connections, if you play the same sound multiple times and you don't remove the connection with QObject::disconnect after play back stopped.

If you set it up only once when you create the sound everything is fine.

Callback: No need to ask. Just try what works. You can't break anything.

Good luck with your project!

Johannes

[franco.amato]

You didn't get me.

If you set up the signal slot connection whenever you START playing the sounddata on an Audiodevice there will be multiple signal-slot-connections, if you play the same sound multiple times and you don't remove the connection with QObject::disconnect after play back stopped.

If you set it up only once when you create the sound everything is fine.

Callback: No need to ask. Just try what works. You can't break anything.

Good luck with your project!

Johannes

Thank you very much Johannes for your precious help.

Best Regards

[JohannesMunk]

You are welcome!

[franco.amato]

You are welcome!

Hi I have a new problem. Some posts ago you explained to me how to connect a signal to a slots of 2 "unknow" objects, eather one is part of the other.
You gave to me this clear example:

AudioDevice* ad = new AudioDevice();
 ...
SoundData* sd = new SoundData();
...
QObject::connect(ad,SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

AudioDevice* ad = new AudioDevice();
 ...
SoundData* sd = new SoundData();
...
QObject::connect(ad,SIGNAL(soundStopped()),sd,SLOT(someSLOT()));

To copy to clipboard, switch view to plain text mode 

Supposing ad (or object A in general has a slider)
I would connect the "valueChanged(int)" signal of the QSlider sl that's part of the object A with a slot that's part of the object B

Something like this:

AudioDevice* ad = new AudioDevice(); //ad has a QSlider sl
 ...
SoundData* sd = new SoundData(); //sd has a slot slot_sd(int);
...
QObject::connect(ad->sl,SIGNAL(valueChanged(int)),sd,SLOT(slot_sd(int)));

AudioDevice* ad = new AudioDevice(); //ad has a QSlider sl
 ...
SoundData* sd = new SoundData(); //sd has a slot slot_sd(int);
...
QObject::connect(ad->sl,SIGNAL(valueChanged(int)),sd,SLOT(slot_sd(int)));

To copy to clipboard, switch view to plain text mode 

Is it possible?
Best Regards