.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 💪

[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.

[Alasdairbugs]

Its not unintuitive to call a file name for a song called "evil penguin march" as "evil_penguin_march.ogg"

And its not about opening one file, if you don't know that "evil penguin march" corresponds to "arctic 2.ogg" or some random shit like that, you have to open multiple to sift through and eventually find it. THAT is more unintuitive.

[Vankata453]

I agree with your point of as accurate as possible music filenames, but only if that wouldn't cause major drawbacks with existing levels. All new music should definitely follow this naming though, in my opinion.

[Alasdairbugs]

I'm not convinced by "major drawbacks". I think you're having a bit of PTSD from the tileset PR haha. I genuinely think its not that trivial to fix should this change occur... but for the map maker that is. If you're fixing a map that isnt yours... Perhaps you may miss a line of code. But you could also have a checklist of songs to crtl+F in the txt version of the level... wouldnt be hard to replace. Again, would take like 30 minutes (~25ish level map). For a map like TCC (47) which is bigger, maybe an hour.

[tylerandari13]

Again, would take like 30 minutes (~25ish level map). For a map like TCC (47) which is bigger, maybe an hour.

Read what Vankata said here.

[Frostwithasideofsalt]

I'm not convinced by "major drawbacks". I think you're having a bit of PTSD from the tileset PR haha. I genuinely think its not that trivial to fix should this change occur... but for the map maker that is. If you're fixing a map that isnt yours... Perhaps you may miss a line of code. But you could also have a checklist of songs to crtl+F in the txt version of the level... wouldnt be hard to replace. Again, would take like 30 minutes (~25ish level map). For a map like TCC (47) which is bigger, maybe an hour.

Honestly i just don't think it's worth the effort, to have every single level have to be slightly changed for the sake of organization and stuff. Like yes; it's not that hard to fix, but every single level and worldmap would have to be changed. And it's not even improving stuff that much.

[Vankata453]

I genuinely think its not that trivial to fix should this change occur... but for the map maker that is.

My main thought on this was that no matter how many levels have their music fixed, there will still be a lot left that will not have any music and just feel very empty (you know, levels with no music are half the fun) 😅. This could be avoided if we preserve the file naming, and instead use the name field in the .music file. The naming of the main game music files also isn't very bad from my experience, you can only get lost between songs which have the format {theme}-{index}.

[jamescdericco]

My intention for the title field is to display the artist's original song title in the hover help text for music in the level editor file browser. This way, we attribute the song to the original work by title and author, so a user can find the original source of the music.

I think that a discussion about renaming the music files as @Alasdairbugs proposed can happen in a new issue after this issue gets PR approved, merged and complete. That new issue can take advantage of the title field that I added to the music files (for most files, where I could find it). As we discussed, this renaming would have the advantage of being simpler (only one name for songs, not two, a filename and a song title), but also the disadvantage of migrating all references (levels) to the new file naming scheme and some cases where the SuperTux filename was easier for users to remember than the title field name, such as the song titled "Riding the Wind" with the filename "forest3.ogg" (the later shows that it is used in forest levels).

[wansti]

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!

Author of salcon.ogg is DJ Gentoo, based on the original by Mystical (aka Asbjorn Andersen). cave_old and fortress_old are mine (same license as the others).

[jamescdericco]

Thanks @wansti for the data and all your music! It's added to the PR now.

The remaining list of missing music fields is:

• christmas_theme has no author, license or title info on it.
• music/retro/classic is missing author and license.
• ice_music and worldmap_old both by ZhayTee are missing licenses.

I'm not blocked by this missing data, but adding it where we find it is great.

[jamescdericco]

My pull request #2674 is ready for review!

This pull request also includes a separate commit that fixes the display of long help texts (>4 lines) that occur for song music files. This commit changes the alignment of the menu item help text display to anchor at the bottom of the screen, preventing the help text from growing past the bottom of the screen.