MintberryCrunchPlease implement a switch that allows users to revert to versions prior to 3.4.1 in terms of latency. We electronic drummers do not want any additional latency when using the plug-in, even if it is only a little more than a third of a millisecond! (which is the case with v.3.4.1 and which is also completely unnecessary for our purposes!)
Especially those whose latency chain has already reached the acceptable maximum of 10 ms (because of not using the fastests modules and audio interfaces) will not be happy about a further extension of the latency chain.
And there are so many benefits from using the plug-in in a DAW, so please don’t answer “use the standalone”.
Please implement a switch that allows users to revert to versions prior to 3.4.1 in terms of latency. We electronic drummers do not want any additional latency when using the plug-in, even if it is only a little more than a third of a millisecond! (which is the case with v.3.4.1 and which is also completely unnecessary for our purposes!)
Especially those whose latency chain has already reached the acceptable maximum of 10 ms (because of not using the fastests modules and audio interfaces) will not be happy about a further extension of the latency chain.
And there are so many benefits from using the plug-in in a DAW, so please don’t answer “use the standalone”.
WolfgangSo why not let choose users if they want to sacrifice some latency for more security? Just like some audio interfaces provide in their driver settings.
One question though: If I’d run my SD 3.4 with 32 samples buffer and after the update switch to 16 samples. Should latency and performance be about the same as before? Or is the new extra buffer handled somehow different?
MintberryCrunchIf I’d run my SD 3.4 with 32 samples buffer and after the update switch to 16 samples. Should latency and performance be about the same as before?
Check the reports of your audio stream out latency of your audio interface at 32 and at 16 samples at the native SD3 sample rate 44100 Hz (btw, it’s good to have an audio interface that reports reliably like RME devices) and then add 0.363 ms in case of the 16 samples setting.
MattiasEksHi all and thank you for your feedback!
Some technical background on the issue:
Parts of our code require 16 sample chunks in order to run highly optimized code. Most of the time, hosts ask for buffer sizes that are multiples of 16, and in those cases this requirement is not noticed and no latency is added. As Petter wrote, some hosts (Ableton Live for instance, and FL Studio, and many other hosts when looping) tend to ask their plug-ins to render blocks with unusual block sizes (sometimes as few as one sample). This is when some buffering is required and latency is introduced.
Before 3.4.0, this was adjusted for by temporarily adjusting the buffers (both the audio buffers and the incomming MIDI buffers), which caused the MIDI events to sometimes be rendered at the “wrong” time (it could vary up to at most 16 samples in 44.1kHz). This has not been popular so we chose to aim for predictability and correct timing, and the price of that was to have a fixed latency of 16 samples instead of a variable “jitter” in the timing of the MIDI events that occured even though 0 latency was reported.
In 3.4.0 this buffering started at the first occurance of a buffer with a size not a multiple of 16, which could cause a pop at that instance. So for 3.4.1 we chose to make the latency permanent instead, for predictability, better stability in MIDI timing and to avoid strange pops.
Your feedback is obviously super valuable, and I’ll gladly take your opinions and raise them when we discuss this in our dev team. Did you prefer the pre-3.4.0 behaviour, where the reported latency was 0 at the expense of the MIDI timing being potentially off with up to 16 samples when dealing with unusual block sizes in 44.1?
Cheers!
/ME
Mattias Ekström - Coder
Toontrack
MintberryCrunchDid you prefer the pre-3.4.0 behaviour, where the reported latency was 0 at the expense of the MIDI timing being potentially off with up to 16 samples when dealing with unusual block sizes in 44.1?
Yes, that’s exactly what I prefer as most e-drummers work with usual block sizes (multiples of 16). Thank you!
Bear-Faced CowDid you prefer the pre-3.4.0 behaviour, where the reported latency was 0 at the expense of the MIDI timing being potentially off with up to 16 samples when dealing with unusual block sizes in 44.1?
This reversion sounds reckless. 16 samples is imperceptible to the human ear, but is more than enough to introduce comb filtering and phase problems for those of us who use a DAW for its intended purposes. Not to mention that the issue of pops and clicks within a mix is far more alarming.
Not to mention that I believe that the 16 sample change addressed issues that other users were having.
I want a test case with a method of reproducing the above. Otherwise I would be dead set against such a reckless revert.
jord
1
Thanked by: drumjack52
BradWould it be possible to put a preference setting under Settings >Performance. With the understanding that changing the setting would require a restart of your DAW (I assume).
Mac Studio M1 Max, RAM 64 GB, 1TB Drive, OSX 12.x/13.x and Windows 10 (VM)
DAW: Studio One Pro (always up to date)
DTX Express III (Extreme triggers), Nektar LX88
OWC Thunderbay Mini (4 X 1TB Sata SSD), Express 4M2 (4 X 2TB M.2 SSD), Envoy Express (1TB M.2 SSD)
Presonus Quantum, Faderport & Faderport 8
Black Lion Sparrow Mk2 A/D, FMR-RNP-RNC, MIDI Xpress 128, BM5A, KRK VXT4, Equator D5
2020 Macbook Pro 16GB RAM, 512GB SSD Audio(mobile rig)
1
Thanked by: MintberryCrunchMintberryCrunchWould it be possible to put a preference setting under Settings >Performance.
This! Such a setting would be most welcome. 🙂
Bear-Faced CowIt’s more than a simple preference. Along with that preference comes a parallel set of supporting code that has to divert and process the sound. Extra processing means more bugs and a greater chance of reintroducing instability as was mentioned in its previous revision by @MattiasEks above. This instability could wind its way back in a broader scale. Who knows. The question is not if it is possible, but if it is feasible over the 350 microseconds (worst case) that Superior Drummer needs in order to not only keep it stable but phase aligned with surrounding audio?
jord
1
Thanked by: BradBradIt’s more than a simple preference. Along with that preference comes a parallel set of supporting code that has to divert and process the sound. Extra processing means more bugs and a greater chance of reintroducing instability as was mentioned in its previous revision by @MattiasEks above. This instability could wind its way back in a broader scale. Who knows. The question is not if it is possible, but if it is feasible over the 350 microseconds (worst case) that Superior Drummer needs in order to not only keep it stable but phase aligned with surrounding audio?
jord
- The post has been modified 2 weeks, 5 days ago by Bear-Faced Cow"> 2 times, last modified 2 weeks, 5 days ago by Bear-Faced Cow.
Absolutely agree, the code supporting SD3 must a bear to manage already. Putting a widget on an interface is probably the easy part. It’s the functional code behind that widget that may be complexed and result in downstream issues, and as you eluded to, must be supported.
Just thought it was a question worth asking.
From my perspective, mixing mostly, with very little “live” playing, at the end of the day it’s the quality of the audio that matters most. 16 samples is negligible when I am laying down my own MIDI, I remember I was lucky if I could get 128 sample response with stability back “in the day” so to speak, so 16 samples is of little consequence. IMHO.
BTW Go Jays….
Mac Studio M1 Max, RAM 64 GB, 1TB Drive, OSX 12.x/13.x and Windows 10 (VM)
DAW: Studio One Pro (always up to date)
DTX Express III (Extreme triggers), Nektar LX88
OWC Thunderbay Mini (4 X 1TB Sata SSD), Express 4M2 (4 X 2TB M.2 SSD), Envoy Express (1TB M.2 SSD)
Presonus Quantum, Faderport & Faderport 8
Black Lion Sparrow Mk2 A/D, FMR-RNP-RNC, MIDI Xpress 128, BM5A, KRK VXT4, Equator D5
2020 Macbook Pro 16GB RAM, 512GB SSD Audio(mobile rig)
Bear-Faced CowFrom my perspective, mixing mostly, with very little “live” playing, at the end of the day it’s the quality of the audio that matters most. 16 samples is negligible when I am laying down my own MIDI, I remember I was lucky if I could get 128 sample response with stability back “in the day” so to speak, so 16 samples is of little consequence. IMHO.
from a mixing point of view, that 16 samples is now, accounted for with delay compensation because it is reported. However, in the other situation where it is not reported, and that bug rears its ugly head in the middle of a mix, our audio suddenly finds itself shifted by 16 samples. That slight phase shift will be noticed and will require more work to fix.
as far as entering MIDI goes, many DAW‘s Support live mode which pretty much surpasses all reported latency for the selected channel. I use this all the time in Logic with all of my MIDI controllers, including a pad controller.
jord
No products in the cart.
Get all the latest on new releases,
updates and offers directly to your inbox.
Note: By clicking the 'I WANT IN' button, you will not be creating a Toontrack user account. You will only sign up to get our newsletters, offers and promotions to your inbox. You can unsubscribe at any time from a link at the bottom of each email. If you want to learn more about our privacy policy, please find detailed information here.
