Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 5 of 5

Hybrid View

  1. #1
    Slim Devices Developer fcm4711's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    872

    Re: Possible button "shift" implementation

    Hi there

    I'd love to have the possibility to expand
    the remote with different map files, since I'm
    always short of buttons on the remote.

    BTW: I have a solution for the example of
    loading and playing a particular playlist
    with one button push.

    Have a look at my QuickAccess plugin here:

    http://www.gwendesign.com/slimserver/development.htm

    Enjoy
    Felix

    --- Robert Moser II <rlmoser (AT) earthlink (DOT) net> 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]);
    > }
    >
    >
    > >

    >
    >

  2. #2
    Robert Moser II
    Guest

    Re: Possible button "shift" implementation

    Felix Mueller wrote:

    > Hi there
    >
    > I'd love to have the possibility to expand
    > the remote with different map files, since I'm
    > always short of buttons on the remote.
    >
    > BTW: I have a solution for the example of
    > loading and playing a particular playlist
    > with one button push.
    >
    > Have a look at my QuickAccess plugin here:
    >
    > http://www.gwendesign.com/slimserver/development.htm
    >
    > Enjoy
    > Felix


    I have a philosophical problem with your plugin. Your numberScroll
    function isn't actually scrolling, it is loading the requested playlist.

    Other than that small gripe, it looks good. If you have the time, I'd
    be interested in having you convert it to use the INPUT.List mode so
    that I could get feedback on that. You can look at Information.pm and
    Settings.pm for examples. I'm going to be updating the documentation today.

  3. #3
    Kevin Deane-Freeman
    Guest

    Re: Possible button "shift" implementation

    Quoting Robert Moser II <rlmoser (AT) earthlink (DOT) net>:


    > I have a philosophical problem with your plugin. Your numberScroll
    > function isn't actually scrolling, it is loading the requested playlist.
    >
    > Other than that small gripe, it looks good. If you have the time, I'd
    > be interested in having you convert it to use the INPUT.List mode so
    > that I could get feedback on that. You can look at Information.pm and
    > Settings.pm for examples. I'm going to be updating the documentation today.


    I haven't had enough time to really look over it, so I figured I'd just ask
    anyway Does the INPUT.List mode handle directory browsing? When you first
    started bringing it in, that application immediately jumped to mind. A couple
    of plugins could make use of that for sure. If its simple, then even the server
    could use ir for navigating music folder and for saved playists sub-folders.

    -kdf

  4. #4
    Robert Moser II
    Guest

    INPUT.List discussion

    > I haven't had enough time to really look over it, so I figured I'd just ask
    > anyway Does the INPUT.List mode handle directory browsing? When you first
    > started bringing it in, that application immediately jumped to mind. A couple
    > of plugins could make use of that for sure. If its simple, then even the server
    > could use ir for navigating music folder and for saved playists sub-folders.
    >
    > -kdf


    It doesn't handle it all by itself, it would need some support from the
    calling mode. However, once I get around to writing it, directory
    browsing will be completely handled by INPUT.Tree, which will most
    likely just wrap around INPUT.List. I haven't even gotten around to
    spec'ing out INPUT.Tree yet.

    I'm in the middle of updating input.html (the doc for INPUT.*) right
    now, so you'll have to rely on the source to get an idea of how
    everything works. I'll most likely be checking in the updated doc
    sometime today.

    -Robert

  5. #5
    Kevin Deane-Freeman
    Guest

    Re: INPUT.List discussion

    Quoting Robert Moser II <rlmoser (AT) earthlink (DOT) net>:

    > > I haven't had enough time to really look over it, so I figured I'd just

    > ask
    > > anyway Does the INPUT.List mode handle directory browsing? When you

    > first
    > > started bringing it in, that application immediately jumped to mind. A

    > couple
    > > of plugins could make use of that for sure. If its simple, then even the

    > server
    > > could use ir for navigating music folder and for saved playists

    > sub-folders.
    > >
    > > -kdf

    >
    > It doesn't handle it all by itself, it would need some support from the
    > calling mode. However, once I get around to writing it, directory
    > browsing will be completely handled by INPUT.Tree, which will most
    > likely just wrap around INPUT.List. I haven't even gotten around to
    > spec'ing out INPUT.Tree yet.


    Sounds right in line with what I expected. Read the dir, send the list to
    INPUT.List, callback reads the sub-dir, etc.

    cheers,
    kdf

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •