View Issue Details

IDProjectCategoryView StatusLast Update
0001864OpenMPTFeature Requestpublic2025-03-29 06:41
ReporterNicu Assigned To 
PrioritylowSeverityfeatureReproducibilityalways
Status newResolutionopen 
Platformx86 / x64OSWineOS Version(version plz)
Product VersionOpenMPT 1.31.14.00 / libopenmpt 0.7.13 (upgrade first) 
Summary0001864: Scan current folder by default when external samples are missing
Description

OS: Linux Mint 21.3 Cinnamon 64-bit + wine-10.1 (Staging)

A friend sent me a zip of an .mptm file with an .ogg as external sample. After I unzipped them (same folder) and opened the .mptm, OpenMPT said that it couldn't find the external sample. By using "Scan Folder..." I pointed to the .ogg file and everything worked just fine.

When I closed it, OpenMPT asked whether I wanted to save the .mptm. I did so and opened it again, and this time it loaded normally. Then I moved the two files in a different folder, to check if the saved path is hard-coded. Fortunately it wasn't, and the sound files played as expected.

This made me think that OpenMPT could gracefully handle missing samples like this:

  1. Check the paths saved in the .mptm;
  2. If there are missing samples, also check the current folder - next to the .mptm file.

The missing external samples dialog could visually mark the missing samples with a sign in front of the samples' name:

  • if detected in the same folder, add an exclamation mark (⚠️)
  • if missing, add a stop sign (�)

The message in the "Missing External Samples" dialog could be updated to:

The following external samples could not been found *in the expected location*.
The current folder was automatically scanned for matches,
and *all | some* samples were found and can be used instead.

The other two lines of text in the dialog can stay as they are.

At the bottom of the dialog, some space could be allocated to explain the icons:

⚠️ = Sample with identical name found in current folder

� = Sample not found

I initially thought these would fit between the buttons, but then I considered that some translations may be longer. So making room for these two lines above the buttons seems like the better idea.

P.S. Great project, by the way, and nice to meet you! :)

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

Saga Musix

Saga Musix

2025-03-13 23:05

administrator   ~0006327

I think this goes against how the feature is meant to be used. The presence of those paths in the file is a feature, not a bug, and a file meant to be released publicly to other people should be prepared to not contain full paths (i.e. the author should move all samples next to the module file before saving the file - this is maybe something that could be automated with an export function in OpenMPT to make it easier) - if not for technical reasons, then at the very least for privacy reasons (random files dumped on the internet should probably not contain any references to your instrument library structure).

In general I wouldn't want OpenMPT to automatically scan any folders without the user's consent - in particular because we cannot know in advance how long such a search would last, and it's possible that we would be scanning problematic files (just imagine the file is placed at the root of the C:\ drive and OpenMPT was now searching the entire Program Files and Windows folders).

As a short-term solution, it might make more sense to add the module path to the "Places" list in the directory browser that shows up when clicking the "Scan Folder" button, but I'm afraid that wouldn't help you particularly because this feature is not currently present on Wine. Longer-term, the aforementioned Export option could prevent this situation from turning up in the first place.

Issue History

Date Modified Username Field Change
2025-02-20 20:48 Nicu New Issue
2025-03-13 23:05 Saga Musix Note Added: 0006327