Re: Re: Abbreviated Album Names

# The following was supposedly scribed by
# Joe Hughes
# on Wednesday 22 December 2004 09:37 am:

>I'd like the abbreviated album title in the actual file names, as
> this makes the files independent of the folder structure. You've
> given me some ideas, I'll have to try out a wrapper script and see
> what I can do.

I'm not sure if you can use backtick interpolation in the "Encoder 
command-line" field.  If so, you could just have a program (e.g. 
"shorten") which simply formats the filename and then put `shorten 
%m` into that field.

On a related note, it might be nice to have something like plug-ins 
which are distributed with grip.   (I say "something like" because 
plugins are not really the grip way of doing things.)  What I mean is 
something like a set of pre-configured command-line/encoder settings 
that the user could choose from (and this could include contributed 
wrapper scripts.)  I guess I mean "templates."

I'm sure that a lot of people have written wrapper/utility scripts to 
use with grip and it seems that many of them must have similar 
functionality.  So, it would be nice if the grip distribution could 
be a central source of community-contributed scripts and configs.  I 
myself have written a "wavstack_worker" program which encodes to ogg 
and mp3 simultaneously (a perl script which uses forks to utilize 
multiple processors) and have considered extending it to do something 
of a distributed-encoding.  To make this work, I had to configure 
grip using a short script in the encoder section which just dumps the 
ripped filename to a todo list.  This works great, unless grip is set 
to "add ID3 tags to encoded files" because that makes a file 
containing only the ID3 tag and tricks the wavstack_worker into 
thinking that the encoding of that file was already completed.

Summarizing, this is sort of a feature request for grip to have a 
"templates" button on each of the config tabs and some system for 
people to submit configuration templates (and associated 
scripts/utilities) for inclusion in the distribution.

In order to not just leave the implementation as SEP, I'll suggest 
that the template-chooser be an external application with either an 
IPC scheme to tell grip what to do or the right to mod the config 
file (or create a snippet of config file) which grip would then 
reload (or merge) when said external app exits.  As far as organizing 
the community contribution, some sort of package format (ala CPAN or 
debian, etc) which is able to contain the template, scripts, etc 
would be in order (and of course that opens the issue of 
dependencies, etc.)

Grip seems to be all about tying-together external applications, and I 
think something like this would fit nicely into that theme while 
making it easier to do more with grip "right out of the box."

--Eric
-- 
"When the going gets tough, most people quit."
                                        --Unknown


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/