Not sure I want to see an output pin on this node. I'd prefer the status to reflect the state of playback.
1 Like
Hey Dave, the status update is indeed a nice feature!
Is there any particular reason, you don't want the audio-out node to have an output? Is it because the audio-out node doesn't accept user input, so you find it confusing? But it could be useful to have an output message when the audio fragment has been finished by the client, so you can e.g. send a new audio fragment for playback.
You could use a status node and set it to the audio note 
That is what i have in mind to use it to trigger other things
1 Like
What @RogierQ just said :-)...
I just refer nodes that are logically the end of a flow to look like they end it...
I'd also like to retro fit some of this thinking into some of the non-dashboard audio nodes that may use the right edge button for mute etc.
Ok, I can clearly see your point from a visual point of view in the flow editor.
But a question about the Status-node: Currently I have only used the node status to display something visual in the editor, but I wasn't aware that these statusses are also passed through the flow (instead of messages) to exchange information between nodes. From some discussions I had concluded that we were only supposed to exchange data via the 'visible' wires, and that other 'invisible' data exchange was not allowed in the Node-RED philisophy?
Is there perhaps any rule of thumb for node developers? When something changes that the flow should be aware of: when should we send an output message and when should we update the node status. Perhaps I haven't done this correctly in my other contributions 
Thanks !!
Hi Bart,
Status messages aren't passed through the flow. They are indeed mainly for visual effect, BUT... they also create an event that the status node receives (and can filter on). This is similar to the Catch node that catches node.error events.
Status is intended to reflect the status of the flow (or node) itself - rather than the state of the message - though this is blurred :-)... So it is intended for things like the state of a network connection, the depth of a queue, if a node is active or inactive, rather than the value of the payload.... of course in a function node you can set node.status to anything so this can be abused fairly quickly :-0...
And yes it is fairly arbitrary. If it's something where you would "normally" expect it to be part of a flow eg http-request - then yes it makes sense to also handle the error as part of the output message. If it's something you have handed off to something else then status may be more appropriate. But somethings that fail a lot... do mean we change our minds... like the file output node now has an output.
Also of course if the node has an output button (like debug) then it shouldn't have a output pin as well.
2 Likes
Hey guys,
Before I submit a pull request, it would be nice to get some 'constructive' feedback.
Here is a demo, since you can not easily install my personal dashboard version:
Some explanation of the demo:
- When pressing 'start' an mp3 fragment is send to the audio-out node. Once the web audio has started playing the fragment in the browser, the dashboard will send status 'started' back to the Node-RED flow.
- Since I couldn't add sound to this animated gif, you can watch the equalizer bar in the right screen to see whether the audio is playing or not.
- As soon as the mp3 fragment has been played 'entirely' by the web audio, the dashboard will send status 'completed' back to the Node-RED flow.
- When pressing 'stop' during playback of the mp3 fragment, the web audio playback will be stopped. And the dashboard will send status 'reset' back to the Node-RED flow. P.S. the demo shows status text 'resetted', but I have changed the text afterwards to 'reset'.
In the info tab of the audio-out node, some extra text has been added:
I have tested this on Chrome Windows and Chrome android.
Remark: does anybody expect extra issues in case multiple clients are listening simultaneously to the same audio?
Bart
3 Likes
Looks perfect to me! Thanks!
Does it also work with tts?
Thats my main use of the audio node
@BartButenaers I'd say send a blank and no blob for end of playing - eg like the preceding http request - so it is cleared when finished. This also leaves the possibility free for "stopped" if there was ever to be a stop command, or maybe "paused" etc.... Also I'd prefer "playing" instead of started... 
If you send a blank, is it possible to catch that change then with the status node?
So do i have a trigger that tells me it has stopped?
actually can be an empty string ""...
1 Like
Nope. Seems that I will need to handle the speech synthesis differently:
- It should be stopped this way.
- And to detect the end of the speech playback, I think I should use this event.
But for some reason I get no sound at all using TTS, so a bit difficult to test Don't know what is wrong, because I have it on all my Raspberry's (so not a result of my dashboard changes)...
Don't know if my demo was not clear, but when you send a msg.reset=true then the playback will already be stopped. So that functionality is also part of this pull request ... Do you prefer perhaps msg.stop instead of msg.reset?
In the current version I haven't implemented pause or resume:
- Web audio can only be started or stopped. However when 'pause' or 'resume' is required, we would need to remember ourselves the time offset (where we have interrupted the fragment). Like in this Codepen example .
- On the other hand, the speech synthesis seem to have pause and resume methods out of the box.
No, implement as you suggested with msg.reset as that is consistent with other nodes (like delay and trigger etc). I was introducing feature creep which I should not as no-one is asking for it.
1 Like
Do you have the web interface ( /ui ) open?
Thats all ways my mistake when testing
@RogierQ: Yes I also saw the text arriving in the dashboard (using Chrome debugger) and entering in the 'speak' function, but no sound... But on Android it worked fine, so I could implement the 'reset' and 'oncomplete' features last night also for speech synthesis. Looks to be working identical to normal audio now...
@dceejay: I have only one open issue. When I have N audio nodes on my flow, they all get the same status. However when nodeA plays A.mp3 and nodeB plays B.mp3 (at another time), I only want the status of nodeA to be updated when A.mp3 is playing.
I do it like this:
- In the ui.js an event is emitted when the socket gets an audio status change from the browser:
socket.on('ui-audio', function(audioStatus) { ev.emit("audiostatus", audioStatus, socket.client.id, socket.request.connection.remoteAddress); }); - In the ui_audio.js this event is handled by setting the node status:
var updateStatus = function(audioStatus) { ... node.status({shape:"dot",fill:"blue",text:audioStatus}); }; ui.ev.on('audiostatus', updateStatus);
Do you know how I can determine in this event handler whether the status update is required for THIS audio-out node. If I know that answer, I will try to submit a pull request this evening. Now I'm off ...
Thanks !!
Hmm - actually that raises a good point... I wonder if this is the way we want to do it...
Wondering if we need a more general approach for setting status rather than setting specific listeners as that won't be extendable. I think maybe that rather like we have updateValueEventName and it's associated handlers - if we need updateStatusEventName to do similar for status - in order to allow widgets to update status.
The thinking with things like the ui_control and ui_audio node was that as they are across the complete dashboard then you only need one per "project" - the fact that you have two and they both feed data to the same speaker is good fortune. As there is only one physical speaker (or two for stereo - then msg.reset will/should stop all the output anyway so the status should reflect that ?
So I think proceed anyway - lets get the PR in and then play with it before release.
Yes that is the same that I was thinking, since there is only one audio destination... But in my examples with A.mp3 and B.mp3 it is rather confusing when both audio node statusses are updated. But 'in theory' it is correct behaviour.
Will prepare the PR as soon as possible...
Thanks!
Btw think this would be interesting functionality for the new widget API anyway!
Evening guys,
The pull request has been submitted.
Now we have to wait for an approval from the master (of disaster )
Keep faith and fingers crossed ...
Bart
1 Like
Merged to master if you wish to try it.
Thanks Bart - looks fine so far.
