.music files should have an "author" entry.

[bruhmoent]

Presently, the identity of the composer behind the game's soundtrack might pose as an enigma. Simplifying matters, it would be highly convenient to incorporate an author designation. This could take the form of something like:

(supertux-music (file "forest-cave.ogg") (author "Marek Moeckel") (loop-begin 0) (loop-at 149) )

[Vankata453]

In my opinion, this attribution should show up when hovering over .music files in the FileSystemMenu, if it's available.

[tobbi]

I'm not sure. .music files are only used to denote start and end.

[tylerandari13]

While im not sure if it should be in the file itself there should at least be a spot in the credits for all the music and who made it.

In my opinion, this attribution should show up when hovering over .music files in the FileSystemMenu, if it's available.

If it can be pulled off i think it would be cool.

[Vankata453]

I'm not sure. .music files are only used to denote start and end.

Should they have to only note that? If necessary, they could provide more details about the music file.

[mrkubax10]

They could provide more details about the music file.

True.

[jamescdericco]

I started work on this issue in the branch 2617-music-author of my fork.

[jamescdericco]

I finished making a UI mockup for this. I would like your feedback before starting implementation. Do you all like this or is there anything you prefer added, subtracted or adjusted?

UI Design Mockup

In the design below, we display music metadata, including author, when hovering over music files in the hover "help text" below the menu:

This "help text" area is currently used by the SuperTux Options submenus which display additional explanation when hovering over options. I'm thinking that we could also use this help text area for displaying music metadata.

I also want to propose displaying the original titles of songs in addition to their authors, where the info is available, so that users can find the original song online, and so authors can display the original name of their work. We can store the title and author metadata as a "title" and "author" fields each ".music" files, and each of these are optional: when the information is not in the .music file, SuperTux will just not display that field in the UI.

If the "title" field is not available, but only "author" is, the hover info could look like this:

If no "title" or "author" is available, the hover info does not display at all.

And if just the "title" is available, we could display that too in quotes in the hover info.

Additional Designs Considered

I also considered adding the music metadata inline in the music filesystem menu itself, but this idea may be too large and cluttered:

[Vankata453]

In the design below, we display music metadata, including author, when hovering over music files in the hover "help text" below the menu:

Personally, I like how this first design looks. Only thing I'm not sure is needed is the music filename being listed in the description, despite it already being used for the menu item text.

[jamescdericco]

In the design below, we display music metadata, including author, when hovering over music files in the hover "help text" below the menu:

Personally, I like how this first design looks. Only thing I'm not sure is needed is the music filename being listed in the description, despite it already being used for the menu item text.

I also felt that repeating the music filename at the bottom could be extraneous, but there is one reason why we may want it there. With the music filename at the bottom, the user can keep their eyes focused only at the help text at the bottom as they navigate the menu with the up and down arrow keys. Without the filename there, the user may have to move their eyes back and forth between the middle and bottom of the screen more often. Also, there is also a case where only "by AUTHOR" appears in the text, which may be a bit too terse and confusing without the added context of the music filename.

The music filename does look a bit weird on its own line. If we keep it, I will add emphasis (use blue font or some other method) so it looks like the subject of the help box.

[Vankata453]

Was thinking that, because usually, help texts are used to add additional information, which extends what the menu item text says. Kind of like a title and a description.

[jamescdericco]

I tried a UI design where the filename was emphasized using a big font and activetextcolor (blue stroke). But I see your point @Vankata453, it may be better to be more consistent with the rest of the app by not repeating the menu item text. I think I'll take your suggestion @Vankata453, and remove the music filename headline from the hover help text.

In the case where a song has no title (or unknown title) but does have a known author, we can display the base filename in place of the song title like this example:

"jewels by Test Author"

Here is the UI design I tested today:

When the song has no title, but does have an author:

[Vankata453]

In the case where a song has no title (or unknown title) but does have a known author, we can display the base filename in place of the song title like this example:

"jewels by Test Author"

Sounds good to me!

[jamescdericco]

Thanks @Vankata453! That should settle all the UI requirements (so no filename headline in the hover text). Now I will start the real implementation of this. I anticipate reporting back with a pull request sometime next week.

[MatusGuy]

Great work man 💪

[tobbi]

Should we add licensing information as well?

[jamescdericco]

It would be good to show the license in the SuperTux UI for everyone to see. I think that a short license identifier, like "CC-BY-SA 3.0" (for airship_remix.music, "Airship Song Orchestral Mix" by David Kelsey) would be a nice addition to the hover help text in the music menu. It's also a legal requirement to link to provide a link to some licenses, like "CC-BY-SA 3.0", so it's important that we do it somewhere. Adding license info builds upon the work of this issue nicely because I'm already looking up the original song details online anyway to find authorship info.

It could be convenient to use all this music authorship and license info that will be stored in the ".music" files to build the music attribution list in the credits.

[jamescdericco]

Here is a screenshot displaying license information for a song that has 3 licenses. Does this look good? Any ideas for improving it?

In this design, "License: LICENSES" appears on a newline in a format similar to how multiple licenses are displayed in Level Settings in the editor (licenses separated with forward slashes):

---

Status Update

Progress: Basic functionality is done in my fork on branch 2617-music-author Next Steps: Add title, author and license data for all .music files, update the game credits, refactor code, test on non-Linux platforms.

[MatusGuy]

@jamescdericco You should open a draft pull request for this

[jamescdericco]

I finished adding all the author, license and title info to the .music files for all the songs in data/music. In some cases, there is missing information where I couldn't find it. Where we find this info, we can add it to my pull request, and if we can't, I think we can open a new issue to find the remaining info later.

Here are the songs that have missing fields author / license fields:

• salcon.ogg (has a missing author. This is a rewrite of a song by Mystical which had licensing issues. I don't know who did the rewrite, but Wansti left this comment in data/AUTHORS)
• christmas_theme has no author, license or title info on it.
• cave_old, classic, fortress_old in music/retro are missing author and license.
• ice_music and worldmap_old are by ZhayTee are missing license.

In the meantime, if anybody finds this info, please leave a comment here and I'll thank you and add it to my pull request!

[Alasdairbugs]

Status Update

Progress: Basic functionality is done in my fork on branch 2617-music-author Next Steps: Add title, author and license data for all .music files, update the game credits, refactor code, test on non-Linux platforms.

I think that saying the title of the song should be redundant, because the songs in the level files shouldnt be called "arctic 1" and "arctic 2" ... etc.

So perhaps the text box below can just say who the author is and a separate PR be made renaming the song files appropriately?

[Vankata453]

I think that saying the title of the song should be redundant, because the songs in the level files shouldnt be called "arctic 1" and "arctic 2" ... etc.

I don't agree, it's better for songs with longer titles, and is more readable.

[Alasdairbugs]

It's not more readable to give a song two different names for no reason? I'm really confused by what you mean. Should we just name supertux in the files as penguin man? Why give things a redundant name?

[MatusGuy]

i think the title label would still be good to have

[tylerandari13]

I dont wanna be "that guy" but renaming all the songs would break a lot of older levels music. :snowsmiley:

[Vankata453]

It's not more readable to give a song two different names for no reason? I'm really confused by what you mean. Should we just name supertux in the files as penguin man? Why give things a redundant name?

It's not two different names, it's a better formatted version of the actual name, which also allows for some forbidden filename characters. The filename doesn't necessarily have to be the exact song title.

[Alasdairbugs]

It's not a better format. If you're looking through the game files for a specific song, you now have to open up the .music file to look at what it's actually named or whatever, and then select it and so forth. I don't understand why it's awful to name files accurately. Same goes for level names too. Level file names more accurately reflect their actual name, for good reason. Because it's easy to use and recognize immediately.

[Vankata453]

Take this song title as an example:

Penguin Dance/Vibe Theme: "Lorem Ipsum?"

It contains:

• 1 forbidden character on Linux: /
• 4 forbidden characters on Windows: /, :, ", ?.

It's better to not fully rely on filenames to provide an accurate song title. Yes, they could closely represent it, if the exact name has forbidden characters, but to provide an accurate song title in all cases, an additional string in the .music file would be a must.

Additionally, the point @tylerandari13 brought up about level compatibility in relation to main game music is fair and shows that renaming the current main game music files is not worth it.

[Alasdairbugs]

1. Flawed logic. This isn't an excuse to not name the song file name as closely as possible? I can make a supertux level with those same forbidden characters - But I would still try make the file name as accurate as possible. That way I would know what level is what.

2. About @tylerandari13 point, I can understand how it can be annoying at first, but this isnt on the same magnitude as something like the tileset PR. I see worldmaps taking about 30 mins to fix if you're the creator and you know what to change. And then from then on, it wouldn't happen again.

This to me just seems like excuses and being complicit with a lazy file naming system :/

EDIT: there is also a degree in "so what" about point 2 - a lot of older levels are heavily broken anyway, like ones from decade old addons or whatever. a few even have missing music anyway! and by my estimates its easy to fix once we change.

[MatusGuy]

i think your suggestion will make it quite unintuitive for the devs and the end user. It's defined once, it's defined forever, all of this just so you don't have to open the file?

[Vankata453]

Flawed logic. This isn't an excuse to not name the song file name as closely as possible? I can make a supertux level with those same forbidden characters - But I would still try make the file name as accurate as possible

As accurate as possible, yes. But not exact in all cases, that's why levels have display names, saved in the file.

I see worldmaps taking about 30 mins to fix if you're the creator and you know what to change.

A lot of older maps are likely to never be updated to the new naming, which means a good portion of levels will not have music, unless they are edited by the player one by one.

A lot of older levels are heavily broken

This change also breaks levels as recent as 0.6.3/Nightlies. Also, why should we break them further, instead of try to not cause such issues?

This to me just seems like excuses and being complicit with a lazy file naming system :/

I wouldn't really care about a music/sounds naming system change, if it wasn't for the drawbacks listed above.