Possible Rack feature request - built in sample delay option at inputs

VCV Rack
9

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.

1 Like
10

I stole the frozen wasteland idea. Sfz player delays gate input by 5 samples.

11

BTW, I do have attenuator cables for my physical eurorack, like this

12

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?

I am with @auretvh

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. :slight_smile:

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.

13

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… :thinking:

Will someone next build a cable with CV input in the attenuator to make it a full blown VCA cable?

That is meant as a joke… I think?

14

Hi gtilde. I found this thread where it is being discussed. It should clear it up:

I’ll see if I can post another example later.

2 Likes
15

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.

1 Like
16

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.

5 Likes
17

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

18

I voted

19

After 23 votes:

  • 15 votes = 65% - I think it is a good idea, and would definitely use the feature
  • 7 votes = 30% - I can see the value, but I would likely not use it
  • 1 vote = 4% - I don’t see any value in the idea, and see no reason to implement it

Thanks everyone.

I will leave the poll open, but I think I have seen enough at 23 votes to determine that the idea is worth submitting. It never hurts to ask.

3 Likes
20

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.

21

haha - automatic delay compensation. Most DAWs have it, and it’s super difficult to get right. Have fun working on that as a free module :wink:

22

:rofl: yeah, when you put it like that…

The difference I guess being that it attempts to compensate only for cable delays propagating through the module graph (not for, say, FFT performed by the module), but, yeah, a non-trivial problem to say the least!

EDIT: thought about this a bit (uh oh):

  1. Consider a scene in Rack as a digraph with modules as nodes, cables as edges, and inter-module delay as constant, positive edge weights (n=1). (Let’s assume we’re not using Little Utils Teleport or equivalent).
  2. This structure is highly amenable to well-understood graph algorithms. For example, the shortest weighted path between any two modules, if a path exists, can easily and efficiently be found with Dijkstra or a number of other simple graph algorithms, even when there are cycles (since the weights are always positive) and it won’t need recomputation unless there’s a cable operation (add, remove, repath).

One minimal, but useful, function, which I’d suggest as a proof-of-concept, is this:

  • Allow the user to define a source module (A) and a final module (B).
  • For each port on B, identify if there is a path from A to B that ends at the given port and determine its shortest weighted length. (In the graph formalism, we basically loop through the ports, temporarily delete all cables other than the one for the port, and then run Dijkstra or alternative).
  • If there are two or more such ports, set port delays for each such port on B so that the sum of the path length plus the port delay for each connected port equals the longest path length minus one. So if there’s a direct connection from A to port B1, a two-hop connection from A to B2, and a five-hop connection from A to B3, set the additional delays as 4 on B1, 1 on B2, and 0 on B3.

To what end? Well, if A is an oscillator and B is a mixer, this would allow on-demand, automatic syncing up of parallel audio paths from a common source without comb filtering in cases where the parallel paths go through different numbers of modules. (Or imagine that A is a mid-side splitter and B is a mid-side combiner; I guess that’s just a specialized form of mixing, but now you don’t have to count modules in order to ensure that your different mid/side processing chains don’t get out of sync). Note that we’re not trying to eliminate or even minimize sync differences along the paths from A to B; we only care about it at the end.

The port delay adjustment be re-run manually, or possibly re-run automatically when there’s a cable change (since by definition the outcome can’t change unless there’s a cable change).

I think that would be a useful advanced feature. The adjustment algorithm could be added via module, but despite Rack’s flexibility I’m pretty sure that a module couldn’t add the per-port delays (maybe there’s some terrifying hack, but a custom build would seem to be the way to go here).

I don’t know how many more use cases there are here, or whether more advanced approaches would need to be used to deal with them. For me, the (probably impossible) hope has always been to reduce cable delay to zero EXCEPT when a single-sample delay is necessary to avoid feedback. But why? No one cares about start-to-end latency of a few samples; it’s [probably] only an issue when signals get out of sync and are then re-combined, and what I really like about @DaveVenom’s suggestion of a variable port delay is that you can compensate for that at the point of recombination without it changing the visible structure of your patch (and, if the tool-assisted graph theory trickery pans out, maybe even without manually counting and updating).

1 Like
23

so yeah, that’s exactly what automatic delay compensation in a DAW does. It’s a good feature. The work is as you describe. Yes, it’s “basic” graph theory. Go for it! (btw, I think you need to break loops somewhat arbitrarily?)

Anyway, backing up, I think delay build into the port would be a cool feature. Thanks @DaveVenom .

4 Likes
24

One critical aspect that breaks graph/node processing latency compensation are feedback loops. Do you have any ideas on how that could be made to work?

For example: module A → B → C → A, which is not uncommon in modular setups. How do you decide which path takes priority? In feedback loops there is no possible way to properly compensate for the latency introduced by the loop, unless the API itself has some smart way to run some modules twice or something like that. I have not seen a single graph/node based API that has such functionality, if you know of any please do tell.

Some graph processing code even completely forbid the use of feedback loops, as it is the case of the JUCE AudioProcessorGraph class.

25

perhaps you didn’t notice I pointed out the loop issue in the previous comment.

26

ah yeah, you did not mention it by name so I missed it.

27

what “name” are you referring to?

28

feedback loop. that is the term I see always used for such things.

related discussion: AudioProcessorGraph with Feedback loops - General JUCE discussion - JUCE