View Issue Details

IDProjectCategoryView StatusLast Update
0000826OpenMPTlibopenmptpublic2023-01-24 12:04
ReporterSaga Musix Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Target VersionOpenMPT 1.32 / libopenmpt 0.8 (goals) 
Summary0000826: Richer libopenmpt metadata (e.g. sample filenames)
Description

It is currently not possible to retrieve a lot of sample and instrument related metadata through libopenmpt.

The most simple missing metadata are sample and instrument <em>file</em>names, which sometimes may contain a "hidden" message in addition to the regular names.

Maybe this could be resolved by providing metadata facilities for samples and instruments in general, which then could also contain more data such as sample lengths, sample quality, middle-C frequency, etc.

Plugin metadata would also be interesting to have, maybe also with the possibility to control plugins trough the interactive interface (bypass, dry/wet comes to mind, adding to / removing from channels and instruments).

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

Relationships

related to 0001493 new Compare modules 
related to 0000780 new Add libopenmpt-info for querying module metadata in shell scripts 

Activities

Saga Musix

Saga Musix

2016-09-15 20:01

administrator   ~0002668

Last edited: 2016-09-16 23:59

More interesting metadata would be retrieval of the time signature (rows per beat / rows per measure) - either the current time signature (least versatile), retrieve time signature by pattern ID, or some function to check if a given row is the start of beat or measure (most versatile, also supports more than one time signature per pattern, in case we ever need that).

This can be used for syncing or pattern drawing purposes.

Saga Musix

Saga Musix

2016-10-20 11:56

administrator   ~0002702

It would probably make sense to have separate metadata APIs for numeric metadata, such as the aforementioned rows per beat stuff (unless we want to put that in its own API function, of course). For samples and instruments, this would also make sense. It would certainly be better than just having string-based metadata APIs where the user basically has to convert the string back to a float (or int) on every invocation.

Blazer

Blazer

2022-09-01 19:44

reporter   ~0005293

I would like to get all the info from a sample/instrument. Name, size, loop start, sample data etc. Just return a vector with with the sample/class/structs. Take a look how libxmp did it.

emoon

emoon

2023-01-03 11:17

reporter   ~0005447

Just want to add that this is something I want as well and including the sample data.

manx

manx

2023-01-03 11:43

administrator   ~0005448

Including sample data would not really be "metadata" any more. It would be a useful feature nonetheless. But, when we include sample data, we could as well include pattern data. At that point, the issue would be somewhat equivalent to "diffing modules" (see <https://bugs.openmpt.org/view.php?id=1493>). It's kind of tricky where to draw the line here.

emoon

emoon

2023-01-03 11:50

reporter   ~0005449

Right that makes sense. In my case I have have two use-cases for this:

  1. Module "diffing" In my case it's to find duplicates in the modland ftp. I already calculates a hash for the pattern data in order to compare if it's the same. Having the sample data would allow me to do it on samples as well.
  2. For my music player I'm thinking of potentially show samples (that are being played) as a visualizer and having the sample data would make it a bit more interesting.
Saga Musix

Saga Musix

2023-01-03 12:28

administrator   ~0005450

I think there is quite a big difference between sample data and pattern data here. Sample data has a well-defined format - PCM - that is extremely unlikely to ever change, and thus can be easily exposed to library users. The raw pattern data has no fixed, well-defined format and may change at any point in time, and there are already limited retrieval options for that anyway. I'd rather treat those two as a completely independent things and not make the implementation of one depend on the other, and in particular I don't think that exposing sample data has to wait for module diffing to be implemented.

emoon

emoon

2023-01-03 12:36

reporter   ~0005451

I think the current way of retrieving pattern data is good enough and I agree that these two shouldn't depend on each other. I also think it makes sense to expose sample data before diffing as it allows libopenmpt users (such as me) to just build "diffing" or whatever on top.

Issue History

Date Modified Username Field Change
2016-07-04 15:39 Saga Musix New Issue
2016-07-27 00:11 Saga Musix Description Updated
2016-09-15 20:01 Saga Musix Note Added: 0002668
2016-09-16 23:59 Saga Musix Note Edited: 0002668
2016-09-16 23:59 Saga Musix Note Edited: 0002668
2016-10-20 11:56 Saga Musix Note Added: 0002702
2017-08-27 09:28 manx Relationship added related to 0000780
2022-09-01 19:44 Blazer Note Added: 0005293
2023-01-03 11:17 emoon Note Added: 0005447
2023-01-03 11:43 manx Note Added: 0005448
2023-01-03 11:44 manx Relationship added related to 0001493
2023-01-03 11:50 emoon Note Added: 0005449
2023-01-03 12:28 Saga Musix Note Added: 0005450
2023-01-03 12:36 emoon Note Added: 0005451
2023-01-24 12:04 manx Target Version OpenMPT 1.?? (libopenmpt 1.0) (goals) => OpenMPT 1.32 / libopenmpt 0.8 (goals)