bsutherland
Note trigger timing drift bug
I'd like to pick up where we left off and it's been a while since I've been here so I'll mark a few issues that I'm hoping are minor but realistically probably aren't.
-
Timing drift - The timing of note triggers isn't super consistent. I have two kicks on a track that sometimes hit together but mostly don't. There seems to be some timing drift.
-
The attenuation sliders are too short which means intermediate values are skipped. I've attached my revised version of the PluginGui files which should correct it.
JUCEOPLVSTi PluginGui files.zip
Hi Gene,
Thanks for your contributions as always. I last worked on the code back in June, but it's in a half-completed state, so I didn't push it. I've incorporated most of your ideas and fixed the slider length, but it's still a work in progress, sorry about that.
About the timing drift, do you mean that you trigger them at the same time in your host, but the plugin plays them at different times? Thanks.
Just wanted to let you know, I updated all my tools and pushed the code. I'll try to make some time to work on the plugin again before the end of the year. If you'd like to contribute changes in the mean time (definitely appreciated!), please fork the repo and create a pull-request when you have it in a state which builds and is ready to merge. Thanks!
Yes, sorry I wasn't clear. I trigger them at the same time but they seem to have some drift. I'm triggering two kicks because 2-OP can be kind of limited. I think it might have something to do with the way FM is handled in hosts versus in MAME.
I heard similar issues occur with this old school VST emulation of the YM2413 (OPLL). It also uses the 3.57MHz clock speed listed in the notes just below. https://github.com/keijiro/vst2413
The timing drift could be a result of a few things:
A) The unusual clock speed without any kind of correction. In PluginProcessor.cpp you have the sample rate set to 44100, but the true OPL sample rate is 49716. From one source of documentation: "The YM-3812 OPL2 chip outputs a 16-bit serial monaural digital signal at a sample rate of 49,716Hz. This odd sample rate is based on the input clock, 3,579,545Hz (a.k.a. the NTSC color burst frequency). Essentially this signal is divided by 72 to get the sample rate."
http://nerdlypleasures.blogspot.com/2015/02/digital-opl2-and-opl3-recording.html
B) From another source of documentation on the Adlib (listed below): "Unlike Adlib (OPL2), OPL3 doesn't need delay between register writes. With OPL2 you had to wait 3.3 us after index register write and another 23 us after data register write. On the contrary OPL3 doesn't need (almost) any delay after index register write and only 0.28 us after data register write. This means you can neglect the delays and considerably speed up your music driver. But using reasonable delays will certainly do no harm."
http://www.fit.vutbr.cz/~arnost/opl/opl3.html
I could be misunderstanding the logic but if the OPL2 writes all values serially, then there might be a delay when playing lots of simultaneous notes. The OPL3 has much faster write speeds, so it's less of an issue there.
As a side note, I discovered this great tutorial a few months ago for making audio plugins: http://www.martin-finke.de/blog/tags/making_audio_plugins.html (There's a section in there about presets that might be helpful to you)
The creator of the tutorial, Martin Finke created this repo: https://github.com/martinfinke/ReaX
Apparently ReaX makes it easier to hook up parameters to the GUI. I'm going to try to learn how to incorporate it into a JUCE project so it reduces the burden of creating the 4-OP OPL3 version since there's the huge headache of assigning all of the parameters 4x plus the added algorithms. I'll be trying out a demo project at some point just to see if I can get the hang of it. Just wanted to make you aware of it if you hadn't heard of it before.
Looks like a nice tutorial. Have fun working through it, hope you can get the hang of it.