Many of my patches are sensitive to sample delay differences. A common issue is when I have divergent gate or trigger paths, and I want to use logic gates on the two inputs. It is critical the signals be in sync down to the sample level to make sure I don’t get any false positives.
There are a number of options for introducing sample delays to compensate. Grande in particular has a very nice polyphonic variable length sample delay for up to 4 inputs.
But what if VCV Rack was enhanced to offer the option to set a sample delay when you right click on the input port? (assuming Windows - or whatever the equivalent is on Mac, etc.) I know I would love that feature, but would others find that useful?
Ideally there would be some graphical indicator that a port has a delay set. Another option would be a menu option to display a delay count atop (or beside) input ports that have delay configured. The display could be turned on and off at will.
I’m thinking the option should support up to at least 10 samples, I have already had patches that needed that much. So doubling the max to up to 20 sounds reasonable.
I assume a low level API and “standard” output port upgrade could be implemented that automatically causes the option to appear in most existing modules. But maybe some developers out there could tell me if I am wrong.
I don’t think a sample delay option makes sense on output ports because they can support multiple cables, and each one should probably have its own delay. But an input port can only ever have one cable, so there can never be any ambiguity.
So what do people think?
If enough people think it would be useful, I will submit a feature request to support.
I don’t see any value in the idea, and see no reason to implement it
I can see the value, but I would likely not use it
I think it is a good idea, and would definitely use the feature
And said law should also specify that the main parameter knob’s value becomes an offset and the dedicated attenuverter adds to the value. Let’s put that in the constitution.
I thought about that, but I think the port is the better option
Cables seem like passive things to me. It doesn’t feel right bestowing a property that requires some form of logic to cables. I can envision some little imaginary delay circuit associated with a port within a module, not so much a cable. I realize the delays are an artifact of the fundamental design of VCV Rack, so why be concerned with “realism”? But still, I like the feel of the port solution.
There is already a UI with a menu for interacting with ports. Adding an additional option feels like a natural extension.
I get what you’re saying. While we’re on the subject, how do you know the amount of sample delays to add? Should I be counting the cables and modules, or just the cables? I always just end up winging it until it sounds right.
The way I (perhaps naively) understand how Rack works - the main “engine” iterates through all modules in a patch once per sample cycle. Each module may have input voltages to process, does its work, and than outputs voltages. Once complete, the outputs “travel through the cables” so they may be processed as inputs in the next sample cycle. The one sample delay for “travel” is a clever way of isolating all the modules so that the order of processing does not matter.
The processing for all modules must complete within the timespan of 1 sample cycle. When a patch becomes too large for the capabilities of the machine and the computations cannot be completed in time, that is when you get audio glitches - sample cycles get dropped.
I wouldn’t be surprised if the CPU meter is really a measure of how much of the sample cycle time is being used for module computations, and not really a measure of CPU usage.
I believe all bets are off if your path runs through VCV-HOST, as I believe that buffers an entire array of samples to be processed in bulk. I struggle developing a model in my head how that integrates with the rest of VCV.
Thanks for bringing this into the spotlight Dave, signal delays are indeed very important to keep in mind in certain areas of patching, so this deserves consideration. As to the best way of doing it, and its pros and cons, I’ll just say that I would definitely use it, although it does add a level of abstraction that makes it harder to assess when quickly looking at a patch. If a new user tries to replicate a patch and cannot see those extra delays, it might make for confusion. As it is now, at least in my patching, very few cables need these delays, and I always implement them by patching the signal through a utility module. That said, avoiding the need for these superfluous modules would still be a good thing in my opinion, but if it can be done with a little visual cue it would be even better.
Absolutely, having a visual cue would be an important design consideration. I tried to address that in my initial write up.
Hidden sample delay patch differences can already be an issue given that some modules already have custom options for delay at some inputs. One that immediately comes to mind is the Frozen Wasteland Probably NOTe quantizer. I’m pretty sure I have run into it elsewhere.
Apologies, for being such a noob. However, I am, confused. With all do respect @DaveVenom, shouldn’t this be a development issue? An issue for the vanilla app itself? Is this a compensation that is needed due to the inherit way the app calculates and runs?
For a user, when is this an issue? May I see, very basic simple example please? Then, how to then fix it when there is a problem? I haven’t voted, cuz, I gotta understand what I am voting on.
wouldn’t you agree, especially in the Window’s environment there is a plethora of tasks that could contribute to audio glitches / anomalies?
Perhaps, I just don’t understand what this is . . . since I never concern myself with it.
Whoah - that is freaky. At first I thought that would be a mighty expensive cable, and seemed ridiculous. But then I thought some more and realized it is a hell of a lot cheaper than an attenuator module. And it conserves space in your rack when you don’t need the capability.
Hmmm…
Will someone next build a cable with CV input in the attenuator to make it a full blown VCA cable?
Absolutely - which is why I filed the post under “VCV Rack”
I didn’t file under “Development” because this is not about how to do something, but rather whether people thought a suggested feature is a good idea.
See Auret’s post above. Thanks @Auret for that post.
Absolutely - our statements are not mutually exclusive. I didn’t say anything about why the machine is unable to complete the processing within 1 sample cycle. As you imply, it could be because of other processes that are sucking up machine resources.
If you never run into the problem, then my guess is you would vote for the 2nd or 3rd option.
Here’s another example where sample delay can help - using (the current version) of ShapeMaster Pro. Only mentioning this as it is something we are currently looking at.
The scenario:
• Set SM to T/G (Trigger/Gate) mode, so the envelope will fire when triggered.
• Turn Sync on (with lock off)
• Make the clock you are triggering the channel with and the cycle length the same (like a /4 clock and a 1 bar cycle length)
Now in channel settings, turn retriggering off - so that incoming triggers will only be accepted if the current cycle has completed.
What happens is the envelope will now only cycle every other bar. The reason for this is that SM’s cycle lengths are hard synced to the master clock - which means that the current cycle ends at the exact same time as the new trigger pulse arrives - the cycle has therefore not ‘completed’ when the new trigger arrives and therefore the next cycle will not be triggered.
Adding a couple of samples delay to the trigger input fixes the problem and the envelope will cycle every bar which is probably what users want/expect in that scenario.
Thanks @steve and @auretvh for the examples. It is entirely possible I have indeed encountered the problem but did not know what was going on. I could have simply thought it was my own muppetry error, concluding well that doesn’t work, and moved own. I do own ShapeMaster Pro. I will study what you both provided, thank you both
This is interesting. I’ve been fruitlessly mulling over the one-sample situation for a while but never thought of integrating delays into the UI/UX. Definitely has some benefits!
By the way, if port delay gets added to the port API, it would be possible to write a module that (presumably on button-click or with a new right-click action, since it would be an expensive and disruptive operation) does some graph analysis and attempts to synchronize the signals reaching a particular module, by reaching in and adjusting port delays in that module and possibly its parents. It wouldn’t always give the results you want (lots of complexities here), but it would work sometimes, and might provide a useful starting point at other times.
