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.

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.

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.

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

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.

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.

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.

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.

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!

I had another stab at this and while I now have accurate PPQ reporting working, unfortunately it doesn't really solve your problem. The main issue here is that OpenMPT does not run any plugin processing while playback is paused, so the plugin also doesn't ask back what the current playback position is. It doesn't even do that when pressing the Set button. Essentially the plugin assumes that playback must always always running. That's something that might happen in the long term with OpenMPT to behave more like other VST hosts, but not something that can be fixed simply in the context of this issue here.

As of r21901 (OpenMPT 1.32.00.30), PPQ reporting is more accurate now. For modules made with older versions of OpenMPT, you first need to disable the compatibility setting "Report inaccurate PPQ position to VST plugins (like OpenMPT 1.31 and older)" (https://wiki.openmpt.org/Manual:_Compatible_Playback#Playback_Compatibility_Settings).

As mentioned in my previous comment, simply navigating around in the module while playback is stopped will still not give you the correct song position in the plugin (because the plugin doesn't ask for it while playback is stopped). However, if you start playing from the row and immediately go into row play mode, you can press the Set button in the plugin and remove the fractions that have since been added to the PPQ position.

r21904 improves the behaviour a bit further, there's one thing I overlooked that kept resetting the PPQ position when stopping playback. That no longer happens now, so you can also just start playback and stop it (instead of going into step mode) to keep the wanted PPQ position.

Okay, one more change as of r22309: When playback is paused, plugins are now asked to run for 0 frames after seeking to a new pattern position. This will update the PPQ position C700. THis is a really experimental change because I bet there are plugins out there which will happily crash when being asked to render 0 frames, but time will tell.

I would like to apologize for not providing feedback for so long. There are a couple reasons for this:

1. Apparently all of my email notifications from this project were put in my spam folder, so for around a year I didn't see any of the notes being added. Thanks, Google.
2. This is more of an excuse, but I've never compiled OpenMPT from source before, so, I've sort of been putting off figuring it out.

Again, apologies. I'm currently figuring out how to compile it to provide feedback as I type this.

Precompiled builds are available from https://builds.openmpt.org/builds/

I'm impressed that you were able to implement it given the struggles you described; however, there's a specific issue with it that makes it hard to get C700 to set the position properly and I'm not so sure the solution is possible; but hey, I kind of worried about this for the entire feature! When setting the row number in C700's recorder, you typically want it to be easy to set specific PPQ positions (usually rounded to the nearest whole row) so that you can loop the song properly. What would be ideal is, when "follow song" is clicked, if the cursor position could be output as if the module was playing at that position. If that's not possible, pausing the song should probably jump back to the nearest row, since it's going to pick up from that point anyway.

Thank you for your work, as always!

The main problem with updating the PPQ position on every cursor navigation is that there is currently no way of caching the position calculations; meaning that OpenMPT would have to through the entire song length calculation for every key press. It might not be very observable on a small tune but once it reaches a few minutes, it can become annoying very quickly when simple cursor navigation is delayed even by just a little bit. Hence OpenMPT currently does these calculations very sparingly. It would be great if these results could be cached for the purpose you describe, but also other purposes (such as live-updating the time display in the status bar), but it does require very deep changes (some of which are definitely planned, others aren't).

I'll see what other temporary solutions there could be to this issue.

Found the first plugin that crashes when trying to render 0 samples (Electri-Q)... so to avoid that, OpenMPT now renders one sample instead, and immediately afterwards reports again that the playback position changed, to avoid potential desynchronization by one sample. Let's see what breaks next..