PDA

View Full Version : Possible button "shift" implementation



Moser, Robert L. II
2003-11-26, 16:10
There have been requests to add a "shift" button, to expand the usefulness
of the remote. I've been kind of unwilling to add it, because there are a
lot of interactions that would need to be accounted for in a proper
implementation. I think I may have come up with a compromise. Instead of a
"shift" paradigm, think "Caps Lock" instead.

Basically what would be added would be a function which changes the current
mapping for a player. So you set yourself up with a couple of different
mappings, lets say custom1.map and custom2.map. In custom1.map you map a
button to changeMap_custom2 and in custom2.map you map a button to
changeMap_custom1 (probably the same button, but it wouldn't have to be).
Part of the changeMap function would be to do a showBriefly to indicate the
newly active map.

Comments?

Kevin Deane-Freeman
2003-11-26, 17:16
Quoting "Moser, Robert L. II" <Robert.Moser (AT) med (DOT) va.gov>:

> There have been requests to add a "shift" button, to expand the usefulness
> of the remote. I've been kind of unwilling to add it, because there are a
> lot of interactions that would need to be accounted for in a proper
> implementation. I think I may have come up with a compromise. Instead of a
> "shift" paradigm, think "Caps Lock" instead.
>
> Basically what would be added would be a function which changes the current
> mapping for a player. So you set yourself up with a couple of different
> mappings, lets say custom1.map and custom2.map. In custom1.map you map a
> button to changeMap_custom2 and in custom2.map you map a button to
> changeMap_custom1 (probably the same button, but it wouldn't have to be).
> Part of the changeMap function would be to do a showBriefly to indicate the
> newly active map.
>
> Comments?

Sounds liek a good compromise. My first thought would be ongoing feedback as to
which map is active. If you switch to custom2.map, and forget 10 minutes later,
you might get a couple unexpected reactions berfore you realise you need to
switch back. Perhaps a persistent single character in the display woudl suffice.

Either that, or another method I could suggest would be stolen from my Stereo
remote. DSP options are handled via a modifier key, which lasts for 30 seconds,
then reverts back to the normal mode. This way, you could have a showBriefly at
the start and at the finish of the time window.

-kdf

dean
2003-11-26, 17:30
Could you post some scenarios where this might be useful? I'm having
trouble visualizing the user interface.


On Nov 26, 2003, at 3:10 PM, Moser, Robert L. II wrote:

> There have been requests to add a "shift" button, to expand the
> usefulness
> of the remote. I've been kind of unwilling to add it, because there
> are a
> lot of interactions that would need to be accounted for in a proper
> implementation. I think I may have come up with a compromise.
> Instead of a
> "shift" paradigm, think "Caps Lock" instead.
>
> Basically what would be added would be a function which changes the
> current
> mapping for a player. So you set yourself up with a couple of
> different
> mappings, lets say custom1.map and custom2.map. In custom1.map you
> map a
> button to changeMap_custom2 and in custom2.map you map a button to
> changeMap_custom1 (probably the same button, but it wouldn't have to
> be).
> Part of the changeMap function would be to do a showBriefly to
> indicate the
> newly active map.
>
> Comments?
>

Robert Moser II
2003-11-26, 20:20
Kevin Deane-Freeman wrote:
> Sounds liek a good compromise. My first thought would be ongoing feedback as to
> which map is active. If you switch to custom2.map, and forget 10 minutes later,
> you might get a couple unexpected reactions berfore you realise you need to
> switch back. Perhaps a persistent single character in the display woudl suffice.

If you forget you can always just hit your switching button to be
prompted again. Putting up a persistant single character would require
defining what the baseline map is (in addition to the current map) and
would require some mechanism to put that character up across all modes.
I don't see it as being worth it.

> Either that, or another method I could suggest would be stolen from my Stereo
> remote. DSP options are handled via a modifier key, which lasts for 30 seconds,
> then reverts back to the normal mode. This way, you could have a showBriefly at
> the start and at the finish of the time window.

Sounds more doable, you would just record your current map, then set a
timer to change back to it after some amount of time. I'll keep it in
mind as a future enhancement.

Dean Blackketter wrote:

> Could you post some scenarios where this might be useful? I'm having
> trouble visualizing the user interface.

Suppose there was a function loadPlaylist which could be used with a
parameter to load a particular playlist with a single button press (to
load the playlist 80sClassics you would use loadPlaylist_80sClassics).
Further say that you have 10 favorite playlists that you would want to
load with only 3 button presses.

To do this you would choose a button to override (search in this
example) and create two custom maps:

# baseline.map
[common]
search = changeMap_myfaves
### end baseline.map

# myfaves.map
[common]
0 = loadPlaylist_AllAbba
1 = loadPlaylist_EuroDance
2 = loadPlaylist_80sClassics
3 = loadPlaylist_SurfGuitars
4 = loadPlaylist_Romantic
5 = loadPlaylist_Trance
6 = loadPlaylist_StarWarsSoundtracks
7 = loadPlaylist_DrinkingTunes
8 = loadPlaylist_HangoverHits
9 = loadPlaylist_HappyHacking

search = changeMap_baseline
### end myfaves.map

Obviously, we currently don't have the loadPlaylist function, because
where would you find the extra buttons to use it? Well, if you could
change maps at the press of a button, there would be lots more room.

So here's the use scenario, you get home and feel like working on some
code, you press [search]-[9]-[search]. After a while a bunch of friends
show up at your door, so you press [search]-[7]-[search] to get things
going. The next morning, [search]-[8]-[search].

dean
2003-11-26, 22:08
On Nov 26, 2003, at 7:20 PM, Robert Moser II wrote:
> > Could you post some scenarios where this might be useful? I'm having
> > trouble visualizing the user interface.
>
> So here's the use scenario, you get home and feel like working on some
> code, you press [search]-[9]-[search]. After a while a bunch of
> friends show up at your door, so you press [search]-[7]-[search] to
> get things going. The next morning, [search]-[8]-[search].
So, I'm not sure why this is a button map issue. Why not create a new
mode for playlists that is triggered by the SEARCH button.

Press SEARCH, see on the display:

Enter the code for the playlist you'd like:
_

Then enter the number of the playlist, 8, and see:

Enter the code for the playlist you'd like:
8 - Hangover Hits

Then press PLAY:

Now Playing:
8 - Hangover Hits

That seems more consistent with the current UI and does the exact same
thing, nearly. (You don't end up in the last place you navigated to,
but that's probably acceptable, given the scenario.)

-dean

Robert Moser II
2003-11-27, 00:00
dean blackketter wrote:
> So, I'm not sure why this is a button map issue. Why not create a new
> mode for playlists that is triggered by the SEARCH button.

Doing it with a couple of maps and two simple functions: about 16 lines
of code, plus 2 files: one 2 lines, one 12. Writing a whole new mode
for the same thing: lots more code.

Keep in mind that the scenario I gave was just one example of one use
for rapid map switching. Another scenario would be a husband and wife
who can't agree on how best to map the buttons on the remote. Create a
husband.map and a wife.map, and reserve one button to flip back and forth.

Another scenario: add a saveToPlaylist function, takes the currently
playing song and adds it to a specified playlist: have a FixTags
playlist for songs that need to have their tags adjusted, a PartyMix
playlist to add to while you are going through your whole collection, a
NeedToReRip playlist for tracks that don't sound right.

The main point to being able to switch maps quickly is to expand the
options available from the remote. Not everyone needs or wants to use
every function, rapid map switching included. It has no impact on
people who like the default configuration, but it allows others to do a
lot more with their remote.

What I see as being great about the Slim system is the wide range of
things possible with it. In any given mode there are tons of different
functions which could be implemented. If people like the functions they
can map a button to use them, if they don't, well, the function isn't
doing them any harm by being there. Notice when I wrote the INPUT.Text
mode how many functions I included, now look at how many are mapped.
Taking advantage of all the functionality of just that one module would
require a remote with as many keys as a keyboard.

I'm sure that the users out there will be able to come up with all kinds
of scenarios where it will come in handy.

By the way, heres the untested code for the loadPlaylist function:

,'loadPlaylist' => sub {
my ($client,$funct,$functarg) = @_;
return if !$functarg;
Slim::Buttons::Block::block($client
,Slim::Player::Playlist::shuffle($client)
? string('PLAYING_RANDOMLY_FROM')
: string('NOW_PLAYING_FROM')
,$functarg);
Slim::Control::Command::execute($client
,['playlist','load',$functarg]
,\&Slim::Buttons::Block::unblock
,[$client]);
}


>

dean
2003-11-27, 08:41
You're absolutely right, using switchable button maps does make it work
with less code, but an unfortunate side effect is that the user
experience isn't great.

It's a fine feature for the people on this list, but probably not a
user interface that we want to include by default.

-dean

On Nov 26, 2003, at 11:00 PM, Robert Moser II wrote:

> dean blackketter wrote:
> > So, I'm not sure why this is a button map issue. Why not create a
> new
> > mode for playlists that is triggered by the SEARCH button.
>
> Doing it with a couple of maps and two simple functions: about 16
> lines of code, plus 2 files: one 2 lines, one 12. Writing a whole new
> mode for the same thing: lots more code.
>
> Keep in mind that the scenario I gave was just one example of one use
> for rapid map switching. Another scenario would be a husband and wife
> who can't agree on how best to map the buttons on the remote. Create
> a husband.map and a wife.map, and reserve one button to flip back and
> forth.
>
> Another scenario: add a saveToPlaylist function, takes the currently
> playing song and adds it to a specified playlist: have a FixTags
> playlist for songs that need to have their tags adjusted, a PartyMix
> playlist to add to while you are going through your whole collection,
> a NeedToReRip playlist for tracks that don't sound right.
>
> The main point to being able to switch maps quickly is to expand the
> options available from the remote. Not everyone needs or wants to use
> every function, rapid map switching included. It has no impact on
> people who like the default configuration, but it allows others to do
> a lot more with their remote.
>
> What I see as being great about the Slim system is the wide range of
> things possible with it. In any given mode there are tons of
> different functions which could be implemented. If people like the
> functions they can map a button to use them, if they don't, well, the
> function isn't doing them any harm by being there. Notice when I
> wrote the INPUT.Text mode how many functions I included, now look at
> how many are mapped. Taking advantage of all the functionality of just
> that one module would require a remote with as many keys as a
> keyboard.
>
> I'm sure that the users out there will be able to come up with all
> kinds of scenarios where it will come in handy.
>
> By the way, heres the untested code for the loadPlaylist function:
>
> ,'loadPlaylist' => sub {
> my ($client,$funct,$functarg) = @_;
> return if !$functarg;
> Slim::Buttons::Block::block($client
> ,Slim::Player::Playlist::shuffle($client)
> ? string('PLAYING_RANDOMLY_FROM')
> : string('NOW_PLAYING_FROM')
> ,$functarg);
> Slim::Control::Command::execute($client
> ,['playlist','load',$functarg]
> ,\&Slim::Buttons::Block::unblock
> ,[$client]);
> }
>
>
>
>

Robert Moser II
2003-11-27, 11:42
dean blackketter wrote:

> You're absolutely right, using switchable button maps does make it
> work with less code, but an unfortunate side effect is that the
> user experience isn't great.
>
> It's a fine feature for the people on this list, but probably not
> a user interface that we want to include by default.

Which is why it is just a function in Common.pm's function hash. I'm
not suggesting that it be put into the Default map, which controls the
user interface included by default.

Only changes to the functions included in the Default map or to the
Default map itself will have impact on Default user experience.

-Robert