PDA

View Full Version : Legal values for "functions" in Default,map



Mark Miksis
2005-05-21, 17:40
I'm hoping to program a universal remote to play certain playlists with a single button. I have some idea how the IR .map and .ir files work. I'm wondering if the "functions" on the right side of Default.map can look deeper into the menus. For example, I'd like to do something like:
my_mix_button = menu_browse_playlists->my_mix_playlist->play
(and then assign it to a code in the .ir file)

The above syntax does not seem to be valid. Can this be done? Is the valid syntax for a "function" documented somewhere?

mherger
2005-05-21, 23:36
> I'm hoping to program a universal remote to play certain playlists with
> a single button. I have some idea how the IR .map and .ir files work.

Have you tried the Favorite plugin? It does exactly this: assign a
playlist to a numeric button. You could find some information there.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

Mark Miksis
2005-05-22, 07:25
That sounds interesting. Where can I find it?

mherger
2005-05-22, 07:27
> That sounds interesting. Where can I find it?

It's in the 6.1 branch (trunk), Plugins/Favorites.

Much of the functionality is not in the plugin, but in various other
modules. If you want to see which modules to the job the following link
might be interesting:

http://svn.slimdevices.com/trunk/server/HTML/?view=rev&rev=2988

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

Mark Miksis
2005-05-22, 07:46
Ah. OK, thanks. I haven't been running trunk but now I have a good reason to check it out. It appears to support favorites for tracks, not playlists, but that's better than nothing.

I'm still curious whether there's an answer to my original query regarding legal "function" names...

mherger
2005-05-22, 07:53
> Ah. OK, thanks. I haven't been running trunk but now I have a good
> reason to check it out. It appears to support favorites for tracks,
> not playlists, but that's better than nothing.

Ooops, you're right. I didn't notice as I've used a playlist which
contains one single stream.

> I'm still curious whether there's an answer to my original query
> regarding legal "function" names...

I'll leave this to the experts.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

kdf
2005-05-22, 11:42
Quoting Michael Herger <slim (AT) herger (DOT) net>:
>
> > I'm still curious whether there's an answer to my original query
> > regarding legal "function" names...
>
> I'll leave this to the experts.

i believe the info desired for this is covered in the help section, technical
info, button mapping. The underscore really only allows provision of a single
argument as opposed to a function path.

-kdf

Mark Miksis
2005-05-22, 13:52
i believe the info desired for this is covered in the help section, technical
info, button mapping. The underscore really only allows provision of a single
argument as opposed to a function path.
Yeah, I read that page before posting the question. It seems a little light on details and examples. Of course, that may be because what I'm asking for simply isn't supported ;)

Robert Moser
2005-05-22, 22:44
Fletch blurted out:
> light on details and examples. Of course, that may be because what I'm
> asking for simply isn't supported ;)

Yep, what you are looking for is not (currently) supported. In general,
the "functions" that you use on the right hand side in the .map file are
the keys of the %functions hash in the .pm's in the Buttons directory
(and in various plugins).

The way it works goes like this (it uses the first match it finds):

1) Look for exact match of the function name in the mode's function hash
2) Split the function name on the first _ and look for the first piece
in the mode's function hash
3) Look for an exact match in the common mode function hash
4) Split the function name on the first _ and look for the first piece
in the common mode function hash

How this usually plays out is that the function name comes first, then a
parameter separated by an underscore. That parameter after the
underscore doesn't have to be a single one though, you can have the
function split it up however you like, much like I did with the
'modeFunction' function in the common mode. In that function it takes
the original parameter and splits it using '->'.

So how this would work for you would be like this:

Create a plugin with a mode and a function to play a given playlist.

Lets call the plugin/mode QuickPlaylist and that function
'play-playlist'. Note that due to the way we parse function names it is
really not a good idea to use underscores in the names of functions.

So, in the map file (in whatever mode you want, probably [common] you
would put this:

my_mix_button = modeFunction_QuickPlaylist->play-playlist_myPlaylistName

The ir mapping you already figured out as something like this:

my_mix_button = 0001beef



To break it down, here's what happens:

It looks for "modeFunction_QuickPlaylist->play-playlist_myPlaylistName"
as a hash key. It doesn't find it, so it looks for "modeFunction". It
doesn't find it either. Then it looks again in the common mode
functions hash. Still doesn't find the long version, so it looks for
"modeFunction" and finds it. When modeFunction is called, it is passed
"QuickPlaylist->play-playlist_myPlaylistName" as it's function argument.
It then breaks that down into "QuickPlayist" as the mode to use, and
"play-playlist_myPlaylistName" as the function in that mode to call. It
doesn't find that, so it tries "play-playlist" and is successfull. It
then calls the "play-playlist" function from the "QuickPlaylist" mode
with an argument of "myPlaylistName".

fcm4711
2005-05-23, 01:55
Hi Fletch

Another possibility to assign a playlist to a number button of the remote is my QuickAccess plugin. As additional bonus you can also assign a player to a button. This enables you to 'transport' a playlist from one player to another thus 'taking' the currently playing music with you.

Felix

Mark Miksis
2005-05-23, 08:57
Robert: Thanks for the detailed response. I was starting to think that I needed a plugin to add new functions and you confirmed that. Looks pretty straight forward though.

fcm4711: I actually stumbled across your plugin last night. I haven't looked at it too closely, but it looks like it'll do what I want. I may need to make some minor changes (for example, to use normal button presses on additional codes instead of the press-and-hold thing).

Can either of you tell me how multiple .map and .ir files are handled? I prefer not to edit the default files to simplify updates. What happens if multiple files have conflicting entries for the same buttonname, function or code?

Robert Moser
2005-05-23, 11:57
Fletch wrote:
> Robert: Thanks for the detailed response. I was starting to think that
> I needed a plugin to add new functions and you confirmed that. Looks
> pretty straight forward though.
>
> fcm4711: I actually stumbled across your plugin last night. I haven't
> looked at it too closely, but it looks like it'll do what I want. I may
> need to make some minor changes (for example, to use normal button
> presses on additional codes instead of the press-and-hold thing).
>
> Can either of you tell me how multiple .map and .ir files are handled?
> I prefer not to edit the default files to simplify updates. What
> happens if multiple files have conflicting entries for the same
> buttonname, function or code?
>
>

The custom.map file takes precedence. It goes like this for button
lookup (taking the first match):

1) Button in the current mode in the selected .map file
2) Button in the current mode in the default .map file
3) Button in the common mode in the selected .map file
4) Button in the common mode in the default .map file


From start to finish it goes like this:

1) ircode is mapped to button name
2) button name is mapped to function name
3) function name is mapped to code reference

Parts 2 and 3 depend on the mode of the player, part 1 does not.

1)
Recieve an ircode (something like 0x00001234). Look through the set of
enabled .ir files until you find a match mapping that code to a button
name. The first match is taken and the order is hash dependent (ie, not
really controllable). This shouldn't matter though, as different ir
sets should have different codes. If there is overlap, one of the two
overlapping files should be disabled.

2)
Look for the button name to function name mapping in this order, taking
the first match: current mode, selected .map; current mode, default
..map; root mode, selected map; root mode, default map; common mode,
selected .map; common mode, default .map. The root mode refers to modes
like SCREENSAVER.musicinfo, where the root mode would be 'screensaver'.

3)
Look for the function name to code reference mapping in this order,
taking the first match: current mode, complete function name; current
mode, split function name; common mode, complete function name; common
mode, split function name.


Some of the things that are not immediately apparent: a mapping in the
common mode .map file can resolve to a code reference in the current
mode (arrow_left maps to 'left' in common mode, but there is no common
'left' function -> coderef); a mapping in a specific mode can resolve to
code in the common mode (the ubiquitous use of the 'dead' function to
disable common mode mappings).

Another thing I haven't mentioned here yet is pressing style, which is
the part in the mapping of the button name after the period. The
initial press results in the base mapping being fired. Then some timers
get set which result in things like button.repeat being fired if the
exact same ircode comes in within a certain time frame, or button.single
being fired after a certain amount of time of not getting that same
ircode, or getting a different ircode. The .* in the mapping file gets
expanded in to each of the pressing styles in the in-memory hash, then
if another mapping involving that button is in the .map file it replaces
the entry put there by the .* (which is why you see in the INPUT.Text
mode the add.* = dead line followed by a plain add = exit_add line).

For reference, my @buttonPressStyles = (
'','.single','.double','.repeat','.hold','.hold_re lease'); is the
enumeration of the recognized pressing styles.

Mark Miksis
2005-05-23, 20:03
Great data. Thanks!