View Issue Details

IDProjectCategoryView StatusLast Update
0001766OpenMPTlibopenmptpublic2024-06-10 18:33
ReporterSaga Musix Assigned Tomanx  
Status confirmedResolutionopen 
Target VersionOpenMPT 1.32 / libopenmpt 0.8 (goals) 
Summary0001766: Provide a way to retrieve numeric values of +++ and --- values via libopenmpt API

Right now libopenmpt users have to assume that +++ patterns have pattern ID 65534 and --- patterns are 65535. These values should be retrievable via an API call instead.

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


related to 0001017 new Tick boundary rendering (was: Provide access to next play position


Saga Musix

Saga Musix

2024-03-30 13:15

administrator   ~0005893




2024-03-30 13:18

administrator   ~0005894

This is also somewhat related to tick boundary rendering, because we need to decide whether to expose the intermediate state of hitting a skip pattern or not.



2024-03-30 19:57

administrator   ~0005898

There are basically 3 approaches possible here:


bool is_order_skip_pattern(int32 ordernum);
bool is_pattern_skip_pattern(int32 patternnum);
bool is_order_stop_pattern(int32 ordernum);
bool is_pattern_stop_pattern(int32 patternnum);


int32 get_skip_pattern_num();
int32 get_stop_pattern_num();


enum pattern_type {
pattern_type get_order_pattern_type(int32 ordernum);
pattern_type get_pattern_pattern_type(int32 patternum);

I have no idea which one would be best. Suggested names are not final, of course.

Option 2 has the disadvantage of requiring an API change if there ever should be multiple possible magic numbers per type.

Saga Musix

Saga Musix

2024-03-30 21:56

administrator   ~0005899

Last edited: 2024-03-30 21:56

In fact the skip / stop indices used to differ between formats, for no good reason. I unified them a long time ago and I don't think we'd ever want to go back to that.

Saga Musix

Saga Musix

2024-06-10 18:33

administrator   ~0005968

Option 2 would allow for writing code with the fewest calls into libopenmpt - the values would only have to be retrieved once and then the whole order list can be processed using those values. Of course it would mean that adding a new type of pattern index would require a new function instead of just adding a new enum value - but with 50+ formats supported by now, and with the knowledge of other formats that are currently unsupported, I'm not even sure what that new type of pattern could be.

Issue History

Date Modified Username Field Change
2024-03-30 13:14 Saga Musix New Issue
2024-03-30 13:15 Saga Musix Note Added: 0005893
2024-03-30 13:16 manx Relationship added related to 0001017
2024-03-30 13:16 manx Assigned To => manx
2024-03-30 13:16 manx Status new => confirmed
2024-03-30 13:18 manx Note Added: 0005894
2024-03-30 19:57 manx Note Added: 0005898
2024-03-30 21:56 Saga Musix Note Added: 0005899
2024-03-30 21:56 Saga Musix Note Edited: 0005899
2024-06-10 18:33 Saga Musix Note Added: 0005968