Full Version:
OpenMPT v1.17.02.51
Has the bug occured in previous versions? If yes, please specify version(s): AFAIK, ever since the newer tempo modes were introduced.
Description of the bug:
I think I've found a problem with the "Modern" tempo mode. I think it's either sending the retrigger (or whatever it is) constantly to VST(i)s, or it's updating its speed all the time. Maybe neither. =D But what happens is that if I enable the metronome in Kontakt, it goes crazy (not even rhythmically!) "Alternative" mode seems to do the same thing, but more regularly. Using "Classic", I get a nice steady beat. Help! =D
How often does it happen?:
Constantly. :)
How to reproduce (step by step description):
Create a song using the "Modern" tempo mode, and fire up a VST that has a metronome. Although it'll get the right tempo (numerically), the reset seems to be strange...
This one's still not working. :(
And bump once more...
I've done a bit more digging. It looks as though it might be a fairly simple problem: the Steinberg SDK docs give this:
tresult PLUGIN_API getSignature (long index, long* numerator, long* denominator)
and in Kontakt3, I've managed to inspect what's being sent. It looks as though numerator is being sent correctly (rows/beat, rpb), but denominator isn't - it's being sent as rows/measure (rpm). I think that the correct way to do this would be to do the following:
1. Require that rpm is an integral multiple of rpb. This is, after all, only logical. This would have to be a flag, though, 'cos I'm sure there are people out there who haven't being following this convention. :)
2. Set denominator as (rpb/rpm), and keep numerator as rpb.
Also, comments like //Screw it! Let's just return the tempo at this point in time (might be a bit wrong). in the VST source code don't inspire confidence... ;)
To save the devs some effort, I think that the problem is in
...
long CVstPluginManager::VstCallback(AEffect *effect, long opcode, long index, long value, void *ptr, float /*opt*/)
...
timeInfo.timeSigNumerator = pSndFile->m_nRowsPerBeat;
timeInfo.timeSigDenominator = pSndFile->m_nRowsPerMeasure;
...
Quote from: "bvanoudtshoorn"Also, comments like //Screw it! Let's just return the tempo at this point in time (might be a bit wrong). in the VST source code don't inspire confidence...
Well you shouldn't be that confident about the source - it's open source ;)
Quote from: "bvanoudtshoorn"To save the devs some effort, I think that the problem is in
...
long CVstPluginManager::VstCallback(AEffect *effect, long opcode, long index, long value, void *ptr, float /*opt*/)
...
timeInfo.timeSigNumerator = pSndFile->m_nRowsPerBeat;
timeInfo.timeSigDenominator = pSndFile->m_nRowsPerMeasure;
...
Thanks for the advices. Have you tried the fix in practice?
Yeah, I just found that particular comment amusing. :) It reminds me of the sort of thing I sometimes do in my own projects...
QuoteThanks for the advices. Have you tried the fix in practice?
I haven't been able to. I still can't get OpenMPT to compile reliably under VS2008. And tbh, I just don't have the time to struggle with it atm. :(
Quote from: "bvanoudtshoorn"I still can't get OpenMPT to compile reliably under VS2008. And tbh, I just don't have the time to struggle with it atm. :(
I would be interested to hear what is the problem; I've used VC2008 as well but after some fixes(which have been committed to source repository) haven't faced problems compiling OMPT with it.
Hmm, I just got the newest version from the SVN, and it compiles ok. With 666 warnings, but that's ok. :) The only issue I can see is that I've lost XP styling - the manifest isn't getting included. :/ TBH, the last time I tried to compile was some months ago - I've been absolutely flat out since then, working on my honours project. :(
Any idea if this is still happening? I suppose it would a lot easier to follow this if it could be reproduced with a small free plugin. However, searching for "timeSigDenominator" on google offers that it could be worth trying to send values 1 and 4 instead of 4 and 16.
Using TobyBear's MetroGnome, I noticed that it doesn't count properly, so I was reminded of this topic.
timeInfo.timeSigNumerator = pSndFile->m_nCurrentRowsPerMeasure / max(pSndFile->m_nCurrentRowsPerBeat, 1);
timeInfo.timeSigDenominator = 4;
This seems to work, and it seems to be what I'd expect from the specs. MPT's tempo is specified in quarters, so f.e. using RPB=4 and RPM=16 would equal a 4/4 beat, RPB=4 and RPM=12 would equal a 3/4 beat. I can't think of an intelligent way of enabling anything but quarter tempos right now, but at least this seems to fix the issue for now (although it might not be very precise for some weird tempos like RPB=4 and RPM=10).
Here's another idea:
I suppose one could use the GCD here. With 4/12, the GCD=4, resulting in a 3/4 beat. With 8/24, the GCD=8, resulting in a 6/8 beat. But I suppose that wouldn't work very well, especially since the user is not informed when quarters are used and when not.
Can you please test if http://sagagames.de/stuff/mptrack.exe fixes the problem?
...or can you test if OpenMPT 1.19 fixes this problem? :P
Looks as though this is fixed in 1.19! A good steady beat from Kontakt's built-in metronome.
Although now I can see (or hear, rather) that OpenMPT and Kontakt can't seem to agree on what 90BPM actually is... The two drift out of time. I'm not sure who's at fault here, though.
I assume you're using modern tempo mode?
Yep -- 8/32 at 90BPM in modern tempo mode.
Weird... does setting the tempo on every pattern transition (using Txx) probably help with the drifting?
(Note: Actually this should be moved to the issue tracker since it's not really related to the original problem)
I synced MetroGnome to the host in both classic and modern tempo mode - even after 8 minutes, they were still in sync at 90 BPM. Either Kontakt is doing something wrong, or it's using some kind of internal timer...
Hmm, strange. It's not a huge problem, really. My guess would be that Kontakt's using an internal timer. I wonder if it's because both OpenMPT and Kontakt are calling timeBeginPeriod() with a different desired granularity, or maybe one's using QueryPerformanceCounter()? Perhaps https://bugzilla.mozilla.org/show_bug.cgi?id=640796 is relevant?
OpenMPT doesn't use QueryPerformanceCounter actively at least (there is one, but it isn't actually used).
I tried Kontakt 5's internal metronome, and it behaves as expected here - I set up a track with a beep every 8 rows and enabled Kontakt's metronome. There was no drift, even after one hour of WAV export and three minutes of "real" playback.
Sounds as though it should be fixed then. I'm still running Kontakt 4 (not enough of an incentive to upgrade from Komplete 6 to 8), but I've not noticed too many issues of late.