View Issue Details

IDProjectCategoryView StatusLast Update
0001731OpenMPTPlugins / VSTpublic2023-10-19 18:23
Reporter02FD Assigned To 
Status newResolutionopen 
Platformarm64OSWindowsOS Version11
Product VersionOpenMPT / libopenmpt 0.7.3 (upgrade first) 
Summary0001731: VST ppq is not updated when the cursor is moved

For VSTs like SNES emulation plugin C700, which read the ppq value for setting the recording positions for hardware exports, this makes getting accurate timings for loops nearly impossible. This might work best as a toggle in the options as this may not be desirable for everyone, but currently, when the module isn't playing, the ppq value is always 0, and if you play next row one by one, the value continues increasing as if the module was playing between rows.

Steps To Reproduce

1) Download C700 VST and load it into OpenMPT

2) Click "Set Recorder"

3) Place cursor anywhere in the song and click "Set" on any of the recording parameters

4) Value is still 0.00

5) Play the next row in the song from that position

6) Click set again

7) Value is not 0.00

8) Click set again

9) Value continues to increase despite the cursor being stationary

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


Saga Musix

Saga Musix

2023-10-03 18:51

administrator   ~0005785

Unfortunately this is technically not really possible at the moment, because the ppq is entirely derived from the number of samples rendered so far, which of course must keep increasing while the paused row is playing. Generally the PPQ generation is not stable at the moment for this very reason too, just changing the tempo in the middle of the song will cause the PPQ to change accordingly. So I'm afraid there is no simple fix for this.



2023-10-18 21:07

reporter   ~0005791

Rats. I figured that might be the case.

I have a workaround for my problem that could at least be put in the hidden settings; not sure how you feel about it, though. Would it be possible to have a "default PPQ position" that controls the value outputted when the song is stopped so you can adjust manually until this is sorted out? I understand if my request is unreasonable, this is a very specific issue I'm having. I'm also not sure, given your description, the feasibility of that idea.

Saga Musix

Saga Musix

2023-10-19 17:20

administrator   ~0005792

I don't think that's a good idea. However, looking at the time retrieval code, it appears that OpenMPT pretends that the transport is in playing mode even when it is really paused. Maybe unsetting the kVstTransportPlaying would also make the plugin behave more nicely.



2023-10-19 17:46

reporter   ~0005793

Last edited: 2023-10-19 17:48

Wait, hold on... Why is PPQ being calculated based on the samples rendered?
PPQ is not a tempo-dependent measure of time. It's "Parts Per Quarter", as in a Quarter note. This measure should be handled completely independent of the samples rendered.
And this is, in fact, the way C700 reads it when you change the tempo. I've had an inconvenient fix for a while now where I just slow down the tempo until it's so slow that restarting the song over and over from the same point allows you to hit an even 0.0000. You can do the same thing with a point from the middle of the song as well

Saga Musix

Saga Musix

2023-10-19 17:49

administrator   ~0005794

Wait, hold on... Why is PPQ being calculated based on the samples rendered?

Because OpenMPT as a tracker has no concept of PPQ, doesn't keep track of anything even remotely similar to PPQ, so the easiest way of implementing it was an estimation based on the current sample position and tempo - which is accurate if the tempo never changes. As I said, it would definitely make sense to have proper PPQ calculation but that would require nontrivial changes to the playback logic, not a simple workaround.



2023-10-19 17:58

reporter   ~0005795

And the number of rows that have played in the song isn't "remotely similar to PPQ"?

I don't question your knowledge; you're much more experienced than I am. I just want clarification.

Saga Musix

Saga Musix

2023-10-19 18:00

administrator   ~0005796

OpenMPT does not keep track of how many rows were played. Even if it did, that would still not help as soon as any time signature changes are involved. You can only keep track of PPQ by actually counting PPQ. Any other proxy metric, be it rows or total samples rendered, will fail at either tempo or time signature changes.

Saga Musix

Saga Musix

2023-10-19 18:10

administrator   ~0005797

FWIW - there would be other interesting use cases for keeping track of PPQ time in OpenMPT, such as sending and receiving MIDI time codes to/from other devices. So that would be one more reason for properly implementing this.



2023-10-19 18:23

reporter   ~0005798

I see. I understand you're incredibly busy, so I'm happy hear that there's some interest in this. In general I think OpenMPT has some amazing potential in terms of MIDI support!

Issue History

Date Modified Username Field Change
2023-09-29 15:04 02FD New Issue
2023-10-03 18:51 Saga Musix Note Added: 0005785
2023-10-18 21:07 02FD Note Added: 0005791
2023-10-19 17:20 Saga Musix Note Added: 0005792
2023-10-19 17:46 02FD Note Added: 0005793
2023-10-19 17:48 02FD Note Edited: 0005793
2023-10-19 17:49 Saga Musix Note Added: 0005794
2023-10-19 17:58 02FD Note Added: 0005795
2023-10-19 18:00 Saga Musix Note Added: 0005796
2023-10-19 18:10 Saga Musix Note Added: 0005797
2023-10-19 18:23 02FD Note Added: 0005798