View Issue Details

IDProjectCategoryView StatusLast Update
0000826OpenMPT[All Projects] libopenmptpublic2017-08-27 09:28
ReporterSaga MusixAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version 
Target VersionOpenMPT 1.?? (libopenmpt 1.0) (goals)Fixed in Version 
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 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).

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

Relationships

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

View 3 revisions

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.

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 View Revisions
2016-09-15 20:01 Saga Musix Note Added: 0002668
2016-09-16 23:59 Saga Musix Note Edited: 0002668 View Revisions
2016-09-16 23:59 Saga Musix Note Edited: 0002668 View Revisions
2016-10-20 11:56 Saga Musix Note Added: 0002702
2017-08-27 09:28 manx Relationship added related to 0000780