Widget: Audio

[joepavitt]

Description

Description from Dashboard 1.0:

Properties

Properties from Dashboard 1.0:

r

Events

Not sure we need any events, this node would likely have 0 outputs.

Controls

• enabled: this widget can be enabled/disabled

Existing Examples

Existing Dashboard 1.0

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[chrismahoney]

I am most likely going to need this after having stumbled upon the 2.0 package in the palette manager, if I do and make headway I'll update here.

[haichenzhu]

looking forward to having this feature available on dashboard 2.0

[bartbutenaers]

The ui-template solution from @Steve-Mcl (see this discussion on Discourse) is a useful temporary workaround, and might be a good starting point for a core ui node.

[bartbutenaers]

@joepavitt
If you want you can also assign this one to me. Will have a look at it as soon as I find time.

[Steve-Mcl]

Not sure we need any events, this node would likely have 0 outputs

It would be useful to have output events like playing, stopped, finished etc for understanding state and for performing actions upon state. E.g. when stopped, your flow could qué a new random song. When finished, your flows might unlock a Step2 in a audiobook story etc.

[Steve-Mcl]

Not sure we need any events, this node would likely have 0 outputs

It would be useful to have output events like playing, stopped, finished etc for understanding state and for performing actions upon state. E.g. when stopped, your flow could qué a new random song. When finished, your flows might unlock a Step2 in a audiobook story etc.

[bartbutenaers]

It would be useful to have output events

@Steve-Mcl,

• I thought that there would be something like a single (invisible) audio player, bound to the ui (similar to the ui-notification node). Because it seems to make sense to me that you only listen to a single audio source.
• Or do you mean that you can add an audio player to every group (similar to e.g. a ui-button), and that it can be visible or not:
  
  And that both the user actions and the audio state changes will be send as output messages.

[Steve-Mcl]

Either way Bart. I am just stating knowledge is power 😇

[bartbutenaers]

Thanks Steve for that lousy advise 😂

I created a draft implementation last night for the first option. It works but it offers very few flexibility. So I will change it to option 2...

[Steve-Mcl]

IMHO, so long as the status is available (playing, position, length, finished) is available in some form (either as an output of the node or via ui-control or some other means), I can make decisions based on it. It can be super basic to start with so long as it is extensible (future proof, i.e. outputs an object). Everything else is up for grabs mister :)

[bartbutenaers]

@Steve-Mcl (and others of course...)
Making progress but now doubting a bit:

1. I assume the "value" of this widget is the src, so that should be applied via the msg.payload (instead of via msg.ui_update.src). Is that correct?
2. I need to be able to start/pause/stop the audio via input messages. Do I need to do that via msg.ui_update.state or some other way perhaps?
   [EDIT 1]: Although the ui-notification node for example (see here) does use msg.show instead of a dynamic property. So perhaps I should also do something similar...
   [EDIT 2]: I will do it like the ui-notification node. It makes no sense at all to store the play/pause/stop commands in the dynamic properties. It is volatile information that I will need to store in some or another msg property.