[Playlist] Nested Playlists, Embedded Fields (was: We need to reset the site

Lucas Gonze lucas at gonze.com
Fri Sep 3 01:49:15 UTC 2021


Now that we have a shared repo on GitLab, Evan has turned your post into an
issue:
https://gitlab.xiph.org/xiph/xspf/-/issues/4



On Mon, Aug 30, 2021 at 5:04 PM Lucas Gonze <lucas at gonze.com> wrote:

> Kace, I'm holding off on substantive comments about this until we figure
> out what's happening with the mailing list and repo.
>
> I'll dive in here next.
>
> On Mon, Aug 30, 2021 at 3:10 PM Kace Ong <kaceong at gmail.com> wrote:
>
>> Since I see that my old questions from 22-Jul-2015 has been added to
>> the gitlab issues
>> (https://gitlab.xiph.org/boehs/xpsf-spec/-/issues/3), please allow me
>> to add more context to my issue.
>>
>> The original question is whether XSPF allows custom tags and nesting
>> of playlists.
>>
>> 1. Playlist of playlists: say song A, B, C are a group file, and song
>> D, E, F are another group file.  Then I may want to be able to create
>> a third file that simply refers file 1 and 2 as child objects, without
>> having to explicitly write out their contents.
>>
>> 2. Within the definition of a playlist sequence, a song is defined by
>> an absolute location/URL.  Sometimes this is undesirable, e.g. if the
>> song's absolute location cannot be determined.  For instance, a set of
>> song files on a portable storage is sometimes mounted on D: drive on
>> one PC, and as F: drive on another PC.  This breaks the playlist.
>>
>>   - 2a. So sometimes what is desirable is to have a file location
>> which is resolvable at runtime.  This may mean some extra user defined
>> fields in XSPF specs, e.g. a custom field called DRIVENAME=D and
>> allowing file locations to be expressions.
>>
>>   - 2b. In the world of online music, due to various rights and
>> permissions concern, a song repository may be linked only temporarily
>> at https://mymusic.com.  This means any playlist pointing to this
>> repository has to resolve the domain name.  It is then easier to have
>> a custom field called REPOSITORY=https://mymusic.com instead of that
>> string in every song address.
>>
>>   - 2c. Both 2a/2b cases can be just a macro or variable substitution.
>> But here is another situation that is possibly more complex.  A DJ at
>> location 1 wants to play his music at location 2 remotely, which is a
>> fairly common scenario in today's world.  Usually he sends the
>> compressed audios from location 1 to 2.  But what if he sends his
>> playlist instead and have it executed at location 2?  Then the remote
>> side gets to hear full resolution music.  But this can work only if
>> playlists can travel and still resolve resource addresses correctly.
>>
>> 3. For the advanced music hackers, can we use scripts to automate
>> playlists?  A case example would be a Karaoke, which has a music and a
>> lyric components that need to sync with each other.  Another case
>> example is a lecture, where we want the sequence to pause at a point
>> until the user presses a key to continue. A playlist is essentially a
>> script, but currently the script only has the power of a simple
>> sequence and no conditional / subroutine / parameters.  How to create
>> more flexibility?
>>
>>   - 3a. One example application could be to export playlists that
>> mixes Spotify and Youtube music.  Each has a different URL scheme, and
>> some tricks are needed to export their playlists which are custom
>> formatted.  Exporting them to XSPF may require custom tags specific to
>> each.
>>
>> Possibly one simple solution is to combine a powerful scripting
>> language (like python) with XSPF as a data structure. But XSPF should
>> define the behaviour of undefined or unknown tags and provide test
>> suites.
>>
>> p.s. I am not aware what is the problem with Mailman, other than a
>> very old user interface. Obviously Gitlab can be an improvement  but
>> only if you know how to use it.
>> _______________________________________________
>> Playlist mailing list
>> Playlist at xiph.org
>> http://lists.xiph.org/mailman/listinfo/playlist
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20210902/6a750245/attachment.htm>


More information about the Playlist mailing list