View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000826 | OpenMPT | libopenmpt | public | 2016-07-04 15:39 | 2024-03-16 09:43 |
Reporter | Saga Musix | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | new | Resolution | open | ||
Target Version | OpenMPT 1.32 / libopenmpt 0.8 (goals) | ||||
Summary | 0000826: 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 filenames, 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). | ||||
Tags | No tags attached. | ||||
Has the bug occurred in previous versions? | |||||
Tested code revision (in case you know it) | |||||
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. |
|
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. |
|
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. |
|
Just want to add that this is something I want as well and including the sample data. |
|
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. |
|
Right that makes sense. In my case I have have two use-cases for this:
|
|
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. |
|
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. |
|
This'd be a very nice thing to have! It'd let us keep a general timeline of historical music for preservation purposes (including even the stats on the most popular samples :) and one's own library, too. |
|
For OpenMPT like pattern view i miss openmpt_module_get_sample_default_volume. |
|
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) |
2024-02-27 18:32 | Kaens | Note Added: 0005845 | |
2024-03-16 09:43 | DrSnuggles | Note Added: 0005876 |