Can libopenmpt write to a specific Effect field?

[ryansupak]

...I've scoured the API documentation and I don't think so, but just double-checking.

I'm working with chiptune2.js. I have altered chiptune2.js to expose several libopenmpt methods all with the goal of, in effect (no pun intended), allowing my code to order the Patterns, on-the-fly, as it chooses.

The solution I came up with was to check the playhead position on every tick, and to invoke the method ".setPositionOrderRow(order,row)" to specify an Order of my own choosing. The problem with this is that the timing is loose enough that it makes glitchy sounds, or gets noticeably off-rhythm, about half the time on a Pattern switch.

Rather than try to solve the timing problem (which seems like a rabbit hole to me), I'm thinking I could solve it by just programmatically adding a "BXX - Jump to Order" effect on the last row of a Pattern, but I can't see a way to do this with libopenmpt, unless I am mistaken.

Another stone I turned over was trying to add a "BXX" to a track and then muting that track (which I *can* do programmatically with libopenmpt via ".set_channel_mute_status()"), but it appears that "BXX" effects are triggered even if the track containing them is muted...so no dice on that as a solution.

Thanks for any guidance! rs

[Saga Musix]

No, libopenmpt only offers read-only access to its internal pattern representation. At the moment it is not planned to allow for write access to patterns, as the most common actions (stuff like changing tempo and volume of channels) is already possible without modifying pattern data. For your specific use case, there is some functionality planned in the future that is being discussed here: https://bugs.openmpt.org/view.php?id=1017 - if you cannot wait, you could of course modify libopenmpt itself in the meantime to add the functionality you need.

As a side note, being able to change pattern data would for example have consequences on any time-related libopenmpt functions, because e.g. the length of each (sub)song is cached (so retrieving the song length repeatedly doesn't have to go through every pattern again and again to calculate the final length) - so changing pattern data would potentially make subsequent calls to some libopenmpt functions more expensive.

[ryansupak]

Thanks for that info. In my specific case, the inaccuracy of total Song/Subsong length wouldn't matter since I'm playing "an arbitrary jumble of patterns" only (and never a Song/Subsong from beginning to end), but good to know. rs