Okay, another update, Phasor Burst Generator does show this behavior as well, but seems to take slightly longer. VCV LFO is the most stable. I’ve had it running at 109 Hz for about a minute and it’s still phase-locked with the Timetable.
So, TODO:
Rewrite the phasor algorithm for Phasor Generator and Phasor Burst Generator. Use the VCV LFO phase accumulator as a model, but add in all the modifications for jitter, freeze, and burst count tracking.
Add a Resync jack to Timetable.
Add buttons to Reset and Resync on Timetable.
Add a Clip output to Phasor Mixer. The phasor from Bitwig Grid has a little artifact on its reset point due to downsampling once it leaves the Grid. Once there’s a good way to constrain that phasor, I can write a tutorial on sample-accurate VCV sequencers for Bitwig.
EDIT: Ah, joy, the VCV LFO is now out of sync with the Timetable as well. 3-4 minutes at 109 Hz is pretty solid, but not perfect. Back to the drawing board.
Woohoo, I’m not crazy. I definitely was feeling crazy and like I was doing something wrong. Blessed be bugs, for when they shine, they become shown.
Edit: just as an aside… it is at least both half there but maybe a distraction. If one would setup a source from Ableton or Bitwig as the ‘phasor’ e.g using CV Tools from Ableton to send a ‘Saw’ to VCV Rack, could a ‘tight sync’ be latched?
Yes, actually! I had reached out to Claes at Bitwig, because using Bitwig Grid to generate the Saw has a little artifact at the reset point that kind of breaks this functionality. This is because the Bitwig Grid is oversampled, and the downsampler adds this spike at the reset point.
As a workaround, I’m adding a Clip output to the Phasor Mixer module. That will mostly eliminate the artifact so that you can use VCV’s audio input for sample-accurate sync.
For now, the recipe I showed above (using Bitwig or Ableton CV Tools to generate a phasor that is then used to modulate an offset generator) works very well unless you are hoping for massive subdivision resolution. However, I have found it to be more accurate than clock syncing in every test.
In drift news: I’ve created a hotfix (2.4.1) that upgrades the HCVPhasorDivMult class to use double precision on the phase tracker and additionally on the speedScale (multiplier/divider) variable. I tested it this morning by running the VCV LFO at 109 Hz for 40 minutes, and the output from the Timetable has not drifted at all. I still plan on adding the additional features that I listed in a post above, but overall I think that this is already a massive increase in accuracy and reliability, so I want to get that portion posted quickly.
Nightly builds should be available shortly. I’ve submitted it to VCV for the Library.
Also, I have a request/suggestion. The Phase Driven Sequencers are very useful for creating an arbitrary curve across a the duration of a sequence. Controlling phasor step shaper for different curves in each step for example. Very cool stuff. It is however very finnicky with the tiny knobs.
Any chance you’d be interested in making a module for just CV sequencing? Think like:
Vertical sliders per step, for easier overview and fine control.
“Steps” control just like all the sequencers have.
Maybe a “Scale” dial instead of width. -/+10v…0v…+/-10v, With +/-5v as default.
Stepped and Slewed outputs.
Oh, and btw. I’m using the nightly and the Phasor Timetable is now in the groove. Big thanks for that especially. These are working pretty dang perfectly for me now.
If there were, there would be a followup on your tracking issue on github. If there was something non-blocking that they think you might want to look at, they open an issue on your project’s github.
Looking at the Project page, your plugin is at the Build Update phase, which means it’s queued for the next library update. Should happen any day now. A github notification goes out when your tracking issue is closed by the publishing automation. At that point it is available in the library for update.
I believe the problem in this case is that HetrickCV has been in the Build Update phase since 30 Sep, fully two months ago, and it still hasn’t been built.
Presumably there is a backend issue of some kind which caused it to fall off Andrew’s to-build list despite it not having been built or released at the time.
Here’s hoping they get the issue resolved. I have had my own locally built version running since the end of September, but it’d still be good to know that the library build process is back in sync.
I too thought this process was completely mechanical once, but then a release of mine got delayed by a month, so only when I updated my bug thread that did they notice my previous release had been missed. That leads me to believe that the algorithm for releases is not quite as bulletproof as you might think.
I suspect the bullet, in this case, was the 2.4.0 release.
Based on a comment in the relevant Github issue, it appears that the bullet in this case was that Andrew had a submodule that was out of sync in his local repo. Having sync’d it—as of an hour or so ago—I am hopeful that the problem will be rectified with the next library update.
I’m not the developer in this case, just an interested user. (Also, because the behind-the-scenes issue was resolved earlier, the updated plugin is now available).
Still, as a would-be developer—I’ve maybe been down that rabbit hole enough times through the years/decades and am now happy for a change just to enjoy playing with what others have made—your advice is (as so often around here) good as well as appreciated.
this is just scratching the surface. There’s a lot more to explore!
Big thanks for that especially. These are working pretty dang perfectly for me now.