And if the step’s probability is 4.5675? In the latter case it won’t trigger, in the first yes.
I can reduce the CV resolution to 0.5. But I’ll end up with the same problem at tie-breaking: if two consecutive CV are 0.2499 and 0.25 (and the step prob is 0.4), the latter still play (snapping to 0.5) while the second (snapping to 0.0) won’t.
And if I have a square CV signal (or whatever signal with fast ramp)?
A basic Fundamental LFO-2 will do it: the values are correctly not smoothed at all.
Even there, delaying the CV reading of about 1ms, with one cable I could read 1.0, with 2 cables 0.0.
As said above, I don’t think we can assume this. Square waves (or with fast ramp) are part of the game
“Typically CV signals don’t change that fast” is a wrong statement, considering any of your own mod generators (if he’s really Andrew Belt that is writing these posts, and not some fancy ghost developers).
Just consider your LFO-2 module with a Square wave output, and that statement is not valid anymore.
How would you evaluate this compensation delay to be applied to the receiving module, when you have chains of different signals path between the sender and the receiver module?
The reason I say essentially “I’ve outlined the problem, fix it yourself” is because this is not an issue with Rack but with time causality, electronics which Rack emulates, and universal logic itself. If you want a module to function a certain way, you need to make sure that you’re not entering a realm of impossibility, such as creating an ideal brickwall filter or perfectly predicting future signals. If you want to solve an “impossible” problem, you need to get creative and prepare to make compromises…
I wouldn’t call this a “time causality” issue: you are aware how many cables there is for a potential samples compensation.
If there wasn’t any 1-sample delay, this problem won’t happens.
And by design, that’s a Rack feature.
So yes, its an issue with Rack
Its similar to PDC in DAWs, except you know there which value to delay, and process works per block.
Wouldn’t be nice to consider a solution to this problem?
But first, I think you should consider this a problem
Really do you consider an “Impossible problem” to keep consistent the read of a CV due the number of its cables?
Unfortunately it is still a time causality issue in general. In the most simple case, when the (module) dependency graph is a tree, yes, it could be solved by removing all cable delays, but in general a 1-sample delay must be placed in every graph cycle. How would Rack choose which cable to delay in each cycle? The only solution which preserves delay in subgraphs when the graph is modified is to delay all cables, so this is what Rack does. Not an issue with Rack, an issue with universal logic.
@Nowhk, try forking Rack and rewriting it so that there’s no delay on cables. See how that goes! By the way, cables aren’t instantaneous in the physical world either (the effective “sampling rate” is just a lot higher).
That is definitely Andrew Belt, there are no ghost developers (fancy or otherwise), and he’s given you a ton of time on this point. Why does your sequencer need to clock at sample-level accuracy to the origin signal and operate identically no matter how many cables the input signal traverses? Having a sense of why you want this might help others help you here.
I believe it serves to guarantee repeatability of the values sent to the CV inputs, regardless of where it is in the signal path, right now it is if you send a signal to a CV input, and you choose to insert a new module in the signal path, the value on which the functionality of the module receiving it was based, cannot be guaranteed, will have a random component not wanted in the design phase of module, and the operation of each module is now truly unpredictable with complex signal parhs.
@flowstoner: Right–but what’s the problem with that kind of unpredictability?
Put differently: I think that sensible behavior over a range of upstream inputs is the essence of modular synth design. If a module’s intended behavior is that tightly coupled to its inputs, it’s probably not going to work well in a modular ecosystem (whether or not there’s a 1-sample delay on cables).
Think of a HW sequencer module. Cable delays aren’t an issue, but if the output is completely scrambled by the ms-level delay involved in, say, running through an ADC/DAC pair, it’s not going to play well with others.
I (and others) would be happy to help with the programming side of this, but I think you have a design question before your programming question. If you need sample-level coupling between subcomponents of your sequencer, they should probably be part of a single module, and not subject to patching at all. If you’re taking patched inputs you need to be robust in how you handle them as a design matter.
(Remember that people are using VCV Rack in hybrid systems as well, so the CV input could actually look more like @Vortico’s graph than you think).
