That seems like something is up with the settings.xml file as both the interface zoom and the reset phase is controlled by this file.
Gavin.
On the bright side, the new XML parameter to force C to play at C1 seems to be working. I’d definitely add three feature requests to the backlog and consider prioritizing them for 1.1.2:
-
Allow users to define their own preferred quantization range for the X-Sub. I think you have the real estate to do this at the bottom of the current quantization display area in the X-Sub UI. Even a simple row of check boxes for C1, C#1, D1, and D#1 would do it. I don’t think you need any more than those four checkboxes. No producer will prefer an E1 over an E0 (and for any higher notes). But you will have some producers who will very much want to avoid the X-Sub playing any of those four notes in the zero octave.
-
Allow the above quantization settings to be configured in the UI and saved on a per-instantiation basis. You might have a producer who has a good reason to write a Trap song in C or D one day and will want the lowest zero-octave X-Sub behavior possible, because they’re going to layer the hell out of that sub (probably an 808-type sound). But that same producer might write a Future Bass song the next day and very much want the X-Sub in that project to avoid the zero-octave for any of the four notes listed above.
-
Also add another checkbox to that same area of the X-Sub UI that turns off quanitization entirely and lets the producer decide exactly which X-Sub notes to play via the controlling MIDI clip. This will enable producers to “go low” when moving notes in one direction, and to instead “go high” when moving in another direction. Or just have any behavior they desire out of the X-Sub.
I might have more bugs to report. Need to break for a meeting. Barely touched the beta 3 yet.
1 Like
I’d say there might be a lock on the text file and something is going wrong there either post editing the xml or if you have it open in a text editor while changing the settings. I’m around all afternoon so just give me a shout when ever 
When I saw this “window-resizing” behavior in Beta 2 last night, I had not ever touched the XML file nor had any editor windows open.
I’ll do some more testing in about 3-4 hours when I have another window for doing so.
Okay, final testing of 1.1.1 Beta 3.
- X-Sub is now behaving almost properly with no transient pop, no sudden reversal of waveform, and the XML-based config toggle between C0 and C1 transposition is working fine.
- REGRESSION: However, both the X-Sub and the Synth are no longer respecting the menu option “Reset phase on new note: ON”. Both of these now drift the phase regardless of this menu setting. Of course, with the Sampler it’s moot because of the nature of playing a Sample.
- The Sampler is still doing that transient “waveform sudden reversal” thing.
- I took a close look at the Synth (both sine and triangle shape) and although you can’t hear a transient pop, it absolutely also does the weird “waveform sudden reversal” thing if retriggered during a decay envelope. It’s not consistent–I’d say it happens about 30% of the time. Oddly, when it happens on the Synth osc, it’s a very short reversal jump before it course-corrects, and that’s probably why there’s no obvious transient like the Sampler still does, and like the X-Sub used to do.
- I got the window resize thing to happen only once during this testing, and the only pattern I can discern between this morning and when it happened recently, it seems to be triggered in part by using the menu dropdown. Even if you only open the menu, look at it, and then click away from the menu to close it again without changing anything at all.
Here’s a screenshot of the Synth doing its small “sudden waveform reversal”.
@Baphometrix, can you check the version and time of this build via the about page?
Definitely seems to be something up with you settings file. If you can grab it and send it over to me I’ll have a look. I think we’ll add a small interface for these settings rather than having people editing the xml file.
Gavin.
I’ll send the settings.xml to you via email, I guess? FWIW I’m familiar with XML, JSON, all that jazz, and just used Windows notepad to edit the settings file. That shouldn’t have changed the encoding or charset or anything like that.
Here’s the build date used for the bugs experienced above.
Hey @Baphometrix,
I had a look at the issue, you’re describing in depth. What your seeing is not a phase reversal, but a sudden increase in volume due to the envelope increasing. I can recreate it in Ableton if I set a loop with midi notes similiar to the image below. If the glide is set to instant and the frequency of the new note that comes in at the start of the loop is different to the note at the end, then it will look more like a glitch or a phase shift. Also if the frequency of the wave does not complete a cycle exactly within the loop, you’ll see less or more of a glich, hence why you are not catching it every time. What you reckon? I’m pushing out a new build this afternoon, would be much appreciated if you can take the time to have a look.
All the testing I’ve done and the screenshots I’ve taken have been based on a single MIDI note. The same note. Just manually playing it, repeatedly. Not on some type of legato or overlapping riff that would normally cause gliding behavior. So those screenshots above have nothing at all to do with the oscillators (or sampler) putting out a different pitch/frequency than the note that’s still decaying in its release envelope.
And FWIW, Sublab is the only Synth/Sampler I’ve ever come across that does this, and which produces a weird “sudden wave reversal hitch” like shown in the screenshots above.
But yes, I’m happy to test.
I think if it is phase, we should see the waveform actually change direction. There could be something up for sure, but lets see what comes out.
Just pming you the beta 4 so you can test with that 
Gavin.
Let me shoot a quick video and demonstrate the problem. I’ll compare what SubLab is doing to what Bitwig’s Poly Grid device is doing. All the native instruments in Bitwig use several types of voice handling and ONE of them is type of envelope retriggering that you describe. Bitwig oscillators (of various types) will not do what SubLab is doing. Neither will Serum oscillators. Neither will Phase Plant oscillators. Give me 30 minutes or so and I’ll have a video comparing/contrasting.
1 Like
One thing to make sure is to have a similar attack time and frequency on the sine wave. I know Serum goes down to 1mS attack time, but they also then reduce the volume it has to climb to when you go sub ~10mS attack, so 1mS might be 1mS to go from 0.0 to 0.2 rather that 1mS to go from 0.0 to 1.0 as in SubLab.
Gavin.
Okay, here are two videos. The first one shows the problem with SubLab’s Sampler in detail, comparing and constrasting how it treats the same exact Sub37 sample versus Bitwig’s own Sampler (which is using the same type of voice handling as SubLab does). The second video goes into a little more detail about Bitwig’s voice handling modes, demonstrating how the “True Mono” mode demonstrated in the first video should be identical to what you’ve been describing to me as SubLab’s voice handling mode. The second video also demonstrates how several different oscillators in Bitwig’s “Poly Grid” device all behave exactly the same way as Bitwig’s Sampler when using similar Hz waveforms at a 1 ms attack.
First Video:
Second Video:
BTW, you can test in Bitwig–with the same exact (and very useful) oscilloscope–by downloading a trial copy of Bitwig. It’s not crippled in any way other than: A) you can’t save a project, and B) you can’t export a project to audio. But you can use it for testing SubLab to your heart’s content and benefit from the really nice native Oscilloscope device in Bitwig.
@Baphometrix, ok so I think I know what is happening here. What we have in SubLab is a small cross-fade buffer. When a new note comes in, we always reset the phase on the sampler, due to fact we want to have a the thump of a kick or transient on all new notes if legato is turned off. What this means is that if a voice is already playing and we’re say 600 samples into the audio file, instead of jumping back to zero instantaneously and therefore cause a large audible click, we take samples 600 to 663 and put them in a buffer: our cross fade buffer. We then jump back to the start of the sample and over the next 64 samples we cross-fade from this copied cross fade buffer into what we are reading from the file starting at sample 0.
If we’re good on the oscillator phase, what we’ll do is release v1.1.1 and then right away jump into having a look at the sampler. I’ve a few ideas on how to make it work better, but it could take a couple of weeks and we’ve got some hot fixes that need to go out in v1.1.1. How does this sound?
Btw, the videos are super useful. I’ve spent the last ~15 years looking at clicks like these and its always good fun to find out the cause The square wave definitely shows the the envelope rising fast much better than with the sine.
Gavin.
Works for me
jfjfjfjffjfjfjfjfjfjfjfjfjf
1 Like
I’m also going to take a look at Bitwig, scope looks very handy. One thing that would be really useful is if you could zoom in once you freeze/trigger the scope. I’m using Oszillos Mega Scope and it doesn’t have this feature.
1.1.1 Beta 4 Regression A:
X-Sub and Synth phase is still drifting like in Beta 3, even when explicitly set to restart phase ON. No way to stop the phase from drifting.
1.1.1 Beta 4 Regression B:
SubLab window will still randomly resize itself to smallest dimension possible when you close the focus window for the VST and re-open it. It is semi-random and this started happening in 1.1.1 Beta 2. In Beta 3 I’ve gotten it to happen 3x within 2 minutes across two different instances of SubLab in the same project.
Basically no change to either of these problems in Beta 4. X-Sub still will not phase lock. I can live with the window re-sizing weirdness, but the lack of phase lock is pretty mission-critical.
I’ve been testing with the VST3 version. Yes, it’s absolutely the new Sep 9 build.date. And the installer seems to have overwritten the settings.xml with a newer version dated today (when I installed Beta 4). And the X-Sub is clearly reverting to play C at C0, which is not the state that I last left the settings.xml file in.
Okay here’s some video proof that the Beta 4 build still allows the phase to drift for the X-Sub and for the Synth, just like in Beta 3. This time I fired up Ableton 10.1 and used a 3rd party oscilloscope called “Schope” to visually demonstrate the phase drift even when the setting to “restart phase at note ON” is enabled. Note that in Ableton I used the VST2 version of Beta 4.
The phase drift happens on both the Synth and the X-Sub. The Sampler is of course okay and always plays in the same phase, because sampler.
I did this test in Ableton and with the VST2 SubLab and with a different 3rd party oscilloscope just to prove that the problem exists in SubLab (both VST2 and VST3). I get identical results in Ableton with VST2 as I do in Bitwig with VST3. You’ve already seen a video of this behavior in Bitwig, back in Beta 3 comments.
@Baphometrix The filter envelope is longer though, I can see from the video that it hasn’t finished by the time the new note comes in. Try shortening the the filter envelope and seeing if the voice resets.
Gavin.