Re: Adding lisp functions to the playlist

[Yoni Rabkin]

Alex Griffin <a@ajgrf.com> writes:

> It would be cool if EMMS could include arbitrary lisp functions in the 
> playlist, which would be called instead of playing a media track.
>
> Hopefully this idea makes sense to someone other than just
> me. Obviously, this feature isn't strictly necessary to enable lisp
> code to interact with the EMMS playlist, however it would make certain
> things easier:
>
> 1. Functions could be queued after certain tracks. Examples of functions I 
> might use this way include:
>
>   - Stopping playback for some length of time
>   - Powering off or rebooting my machine
>   - Changing the volume
>   - Changing the emms player backend
>
> 2. You could use standard EMMS key bindings to order and rearrange functions 
> to execute, and store them in playlist files.
>
> I'm writing this because I'm not sure how this feature would be
> implemented or if it would need support in upstream EMMS. Although I
> have written a simple emms player backend[1], this idea breaks the
> media player paradigm a little bit so I decided to solicit feedback
> from the mailing list here.
>
> Is anyone else interested in this? Can it be implemented as a standard
> player backend or would it require upstream support/crazy hacks?

Sounds like an interesting idea. Perhaps call it emms-actions.el? It
would entail adding a new track type. It might look something like this:

    (*track* (type . action)
             (function . #'emms-volume-raise)
             (info-title . "raise the volume")

Then implement a "player" for the `action' track type, which would be in
emms-actions.el. If you look at the code around
`emms-players-preference-f' you'll see that there is no problem putting
a call into emms-actions.el when (eq 'action (emms-track-type track))

All that would then do, using an accessor such as `emms-track-function'
is something like:

    ...
    (funcall (emms-track-function track))
    ...

However, it should come with appropriate warnings and
protections. Otherwise, if someone has an "action" track which reboots
the machine, and they hit emms-shuffle and play... emms-actions.el will
have to provide ample protection from surprising the user.

Also, you'd need to make sure that the cache and similar functionality
isn't broken by coming across an action track.

Another idea is to add a property such as `before-action' and
`after-action' to any track, which store a function, and have
emms-action.el funcall that. This is already pretty close to hooks, but
track-specific.

What do you think?

-- 
   "Cut your own wood and it will warm you twice"