ChangeListener not called back from AudioTransportSource

What I am attempting to do is to get a callback when the transport is done playing a sound file.

I load the sound into an AudioFormatReader using createReaderFor.  Then create an AudioFormatSource from the reader.

Finally, I tell the AudioTransportSource to  setSource to the AudioFormatSource.

I create a new subclass of ChangeListener and tell the AudioTransportSource that it should addChangeListener, and then I tell it to start.


The sound plays fine, but the ChangeListener is never called.  This is on Linux as well as Raspberry Pi; I haven't tried yet to repro on OS X.

Just FYI: here's my subclass.  The ctor does get called:

class MyAudioListener : public ChangeListener
        virtual void changeListenerCallback    (    ChangeBroadcaster *     source    );
        virtual ~MyAudioListener();
MyAudioListener::MyAudioListener() : ChangeListener()
    printf("MyAudioListener ctor\n");
    printf("MyAudioListener dtor\n");
void MyAudioListener::changeListenerCallback    (    ChangeBroadcaster *     source    )

Nobody has any clues for me?

Did you actually attach this listener to anything?

As I said, I did an addChangeListener:

transport->addChangeListener(new MyAudioListener());

Is this maybe a command line application?
Message notifications only work if a MessageManager object has been created. I’m not sure, whether this additionally needs to be done in a graphical environment or if it also works on a Linux without X server.

If you call “addChangeListener(new MyAudioListener());” the MyAudioListener object will be leaked.

As it happens, it is a CLI application and indeed, changing it to a GUI one makes this problem go away.

If I manually do a "runDispatchLoopUntil(40)" then I get some of the messages.  So I guess the question is: is there a proper way to have a CLI application pump the message loop?

Thanks for the pointer!

Oh, that kind of thing isn't really designed to be used in a CLI app.. If you're writing an app that needs an event-loop then you should actually just make it a gui app, but not open any windows. You can run the message loop directy, but it's not generally a good idea.

OK.  In my use-case I need to be able to use messaging even from a CLI application.  So the question is: how best do run the message loop (and how to relinquish it if a regular GUI app starts)?

Don't understand the question...? if you need a message loop then it's a GUI app (regardless of whether it opens any windows). You can still launch it from the command-line like a CLI app, of course.

OK.  My app reads from the console.  So it's a CLI app, but it uses the JUCE library and wants to have messages processed, so it's a GUI app.  

I want to be able to play a sound even if the regular message loop is not run.  

You could use a thread to read the console stuff.

That's a thought.  I'll look into that.

Works, after putting my main processing on a Thread....