Bugzilla – Bug 9057
Preview Alarm Sounds - IP3K players
Last modified: 2010-06-08 13:18:41 UTC
When setting an alarm on the boom, there is no way to Preview what the sound is like from the player UI in the alarm menu. Please add a "play" option when an alarm sound it viewed. Simply pressing the play button on the front panel / IR remote is acceptable.
note: there isn't currently any framework for "preview" of tracks/sounds. Having a "play" option would effectively mean replacing the current playlist with the potential alarm sound. A more complicated process would be to use something like the announcement idea: insert the track-to-be-previewed as the next song on the queue. mark the current playback position if player is playing. jump to preview track for...say 30s jump back to previous track and goto previous position (start of song for transcoded songs) remove preview track. Potential Problems: interrupting currently playing remote tracks. surprised users who forget they have synced players when they preview barnyard sounds. Currently the sound selection uses INPUT.Choice. This means you have actions on Play, Add and Right. Given that they are currently not treated as audio, all 3 select the sound. Simple case may be to have onPlay and onAdd do the usual thing for audio tracks, and only have onRight do the selection. In that case, the UI needs some thinking in order to reflect that (typically playable files have a note icon, while selectable items have the radio button or checkbox).
Alan: Does new_streaming make it easier to pause, play something else, then resume audio?
No, not really. Maybe a little - the hooks you would need are more accessible. It would be nice though - you could do whole-house audio announcements ("dinner time").
*** Bug 11462 has been marked as a duplicate of this bug. ***
*** Bug 14293 has been marked as a duplicate of this bug. ***
*** Bug 14704 has been marked as a duplicate of this bug. ***
this problem also exists on the radio and to have so many sounds is pretty useless without beeing able to prelisten to them.
I'd like to suggest that this be given a much higher priority due to the release of the Squeezebox Radio, which is also being positioned as an alarm clock replacement. Lack of alarm sounds preview has been brought up several times in the forums already and is even being mentioned as a downside in online reviews of the new product. What about using the mixer to play the preview? Then the current playlist needn't be wiped. Mute whatever is playing (if something is playing), play the alarm sample, then unmute.
The more votes, the higher the priority :)
Currently I consider the alarm-clock sounds as a non-existent 'feature'. Selecting one, adjusting the alarm-time, waiting at least 1min to have the alarm go on just to hear one single sound is just a plain stupid thing to do. Currently you need about 10 minutes, just to prelisten 5 short sounds !
re-assigning Seth's bugs to Matt
Matt Weldon doesn't work for us any more.
Brought up during Fab4 CX review. Retargeting to engender discussion for next release.
*** Bug 16017 has been marked as a duplicate of this bug. ***
See bug 15321 for SP equivalent bug.
I mean bug 15231
This bug was originally brought up for Boom, but I'm hijacking it for the purposes of fixing it for Squeezeplay UI purposes. Alarm Preview on Squeezeplay players will be the scope of this bug for 7.5.1. I'm fine with it staying open past 7.5.1 for ip3K players (or webUI), but that's out of scope for what I'm going to be working on. Bug 15231 is not the equivalent SP bug. That bug deals with alarm *volume* preview, not alarm tone preview. I should also note: in the current SP UI implementation I'm working on, KDFs comment#1 still applies. A preview option will replace the current playlist with the potential alarm sound. I have some thoughts on possible ways to get past this limitation, but again this may be beyond the scope of what can be delivered for our next point release.
== Auto-comment from SVN commit #30676 to the slim repo by bklaas == == http://svn.slimdevices.com/slim?view=revision&revision=30676 == Bug: 9057 Description: add a 'preview' action callback to sounds in SP alarms. Note that this checkin is 100% inert until the SP-side is completed.
== Auto-comment from SVN commit #8721 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8721 == Bug: 9057 Description: add ability to preview alarm sounds through a new 'preview' action from the server alarm preview is done through either pressing play or + (or on the touch interface, through touch-hold) window pops up while the alarm sound is previewed. when the window is exited, the player is paused current limitations of implementation: 1. very difficult to discover the means of previewing. there is currently no mechanism for sending help text from the server in a slimbrowse menu such as this to message the user. 2. previewing an alarm sound wipes the current playlist and replaces it with the alarm sound.
I showed Matt Weldon what had been done so far. He said there were two ways of doing it. Although he said he was going to update this bug himself, Matt seems to be super busy. Before I forget what he said, I wanted to enter them in now and perhaps Matt can correct me later: 1. Make more discoverable by - Putting a hint like "Press and hold sound to preview" in the screen title, E.g., right under "Musical Sounds". - Once the user presses and holds, a new window would not appear. Instead the sound would preview for a fixed amount of time, like 30 seconds. You would not be able to shorten it, and no button to stop the preview is needed. - To indicate the sound is playing, the selection circle at the far right would turn into a spinny while it's playing. 2. Add choice to preview sound into a context menu. This would require a restructuring of alarm menus to make it fit into the flow of setting alarms. However, this would be consistent with a larger framework of items discoverable by context menus on many other screens.
== Auto-comment from SVN commit #8724 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8724 == Bug: 9057 Description: add 'go' to the list of actions not ignored by the window
>> Add choice to preview sound into a context menu. [...] >> However, this would be consistent with a larger framework >> of items discoverable by context menus on many other screens. Screensavers are previewed by pressing the 'play'-button on the respective screensafer. Doing the same to preview/play an alarm-sound I'd consider consistent and intuitive.
Weldon, very much appreciated on the input, and Mickey thanks for the legwork on that. Choice #2 may be the best option, as it is a consistent UI model with e.g. browsing tracks in a library. The problem with putting a hint that says "Press and hold sound to preview" is that this hint is coming from the server, and the text that's delivered would need to be platform-specific (e.g., on Touch it's press and hold, but on Radio it's the + button). In addition, we'd need to engineer in the ability to display a slimbrowse menu that includes both menu header text and a menu of non-standard (in this case, radio button) items. There is no support for that right now, and IMO adding it would not be particularly straightforward. The second and third points in choice #1 are valid suggestions but dosn't actually address the discoverability issue, just the behavior of the preview. I'll noodle on them though, they are good thoughts as far as the UI goes. Stefan, unfortunately SB Touch throws a wrench in things because there is no differentiation between a "play" action and a "go" action. On SB Touch, both play and go are invoked by touching the item. There needs to be a way to select the item as your configured alarm sound (the radio button) as well as playing it.
I'm happily take a Touch as present to try out myself :D How do you do it for Screensafers on the Touch then ? On Radio and Controller the 'Go'-Function is used to select a screensafer and 'Play' to preview it. If there is no dedicated 'Play' on the Touch ... um ... can't you preview screensafers on the Touch then ? Anyway - if you do anything fancy with the + button for alarm-sounds, remember to adjust screensafer previews accordingly.
Press-hold on Touch (same action as + button) is for previewing screensavers. Unfortunately this does not work as well as it should and is an open bug, bug 11096.
Thinking about this a little further, I think that going with a context menu approach for the + button may be fine from a UI design perspective, but it also does nothing to enhance the discoverability of the feature. Either the current model or the context menu model require a user to hit the plus key or touch-hold to access (note: play button also works for preview in the current model) So...if the task at hand is to let the user better know that sounds can be previewed, the only way to do effectively do this is through something visible on the UI.
== Auto-comment from SVN commit #8728 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8728 == Bug: 9057 Description: pull the preview action listener into a separate clause from the _jive_button logic
== Auto-comment from SVN commit #8745 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8745 == Bug: 9057 Description: call player:stopPreview() when alarm preview window is exited. Requires up-to-date 7.5.1 SBS for this to function properly. unrelated to 9057: allow a showBriefly to bring up a persistent window when duration is -1 debug message for choose player window debugging
== Auto-comment from SVN commit #30707 to the slim repo by bklaas == == http://svn.slimdevices.com/slim?view=revision&revision=30707 == Bug: 9057 Description: add 'playlist preview' cli command to support alarm sound preview and retrieval of last previous playlist before preview. extend 'playlist resume' to include tagged params of noplay:1 and wipePlaylist:1. Used for not auto-starting after resume and to wipe a temporarily cached playlist, respectively. document cli changes
== Auto-comment from SVN commit #30708 to the slim repo by bklaas == == http://svn.slimdevices.com/slim?view=revision&revision=30708 == Bug: 9057 Description: send a textareaToken in the window for Alarm Sounds
== Auto-comment from SVN commit #8746 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8746 == Bug: 9057 Description: support for a textareaToken on a slimbrowse menu which can deliver platform-specific help for a window note that using help to present menu header widgets like this can not coexist with decorated menu items like radio buttons or checkboxes
== Auto-comment from SVN commit #8749 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8749 == Bug: 9057 Description: handle the alarm preview window correctly for the slimbrowse window step stack. this fixed a UI problem when backing out of windows after calling an alarm preview. I believe this is the final checkin for alarm preview support for Squeezeplay-based players.
I believe this bug to be fixed for Squeezeplay-based players, which was the 7.5.1 target requirement. Rather than close this, I'm going to leave it open, untarget it, and change the summary to reflect that this is now only open for ip3k players. FWIW, it could be that some of the 'alarm preview' cli work that was done server-side could be leveraged for ip3k player support. However, this will not be my task to fix.
Changed bug summary to reflect current status.