Cable table latency/sync issue.

[Christoph Hart]

I've looked a bit at the clock_ramp code an there is a slight inaccuracy where it takes the last ramp value when trying to figure out the modulation value, so I changed it to use the mid value.

But the modulation inaccuracy is defined by the block size of the processing context - every block a single value is sent out and this introduces some inaccuracy within the block processing size - that's how scriptnode works and it's your responsibility to choose a block size that matches your requirements.

If you choose the lowest available block size with a fix8_block the modulation with the latest fix becomes pretty much sample-perfect.

And yes I've slapped a cable_table between the clock ramp and the add node so there's definitely no issue with this particular node

[lalalandsynth]

@Christoph-Hart Ok, will try this.

1. is this consistent between buffer settings ?
2. Does this get rid of the starting bump ?

[Christoph Hart]

1. Yes (at least for the part of the signal path that I've tested), not sure what you're doing afterwards
2. The starting bump is created by the stock LFO module right? I was only referring to the clock_ramp node.

[lalalandsynth]

@Christoph-Hart

1. Not doing too much afterwards and results were the same when I bypassed all that.
2. Starting bump was also caused by the Scriptnode, although I will test it again.

Is your testing done via the add to signal from the clockramp or is it audio through a gain module ?
My test was Audio on a track in reaper through Hise plugin exported as FX.
Scriptnode table controlling a gain module.

[Christoph Hart]

@lalalandsynth well the gain is smoothed so there‘s your source for the bump…

[lalalandsynth]

@Christoph-Hart I see, that will not cause a problem for me in this case as I am using this for cc output , no bump there.

Although if used for "sidechain" style volume, or as a send envelope into an fx this would cause a problem. Is there a way to get the table to operate on gain without any smoothing , or at least with settable smoothing, don´t need that much to get rid of clicks.

Also a bit strange that the "tail" shows up in the beginning, It would make sense when it loops.

[Christoph Hart]

settable smoothing

There's literally a Smoothing parameter on the gain node :)

[lalalandsynth]

@Christoph-Hart Indeed , but it was set for no smoothing.
Unless I messed up my test? I will check when I get back to the studio.

[Christoph Hart]

If you get away with it I would recommend using the math.mul node instead of the gain node, it's a bit faster and doesn't require a db->linear value conversion on each modulation update.

[lalalandsynth]

@Christoph-Hart There are still some problems.

Latest build.
Testing with 8 block, buffer set to 128 there are differences between Synced and Continuous.
Synced is earlier , 3.1 ms

There is also a lot of jitter on both.

Here is a demonstration of synced jitter. (recorded in a loop in reaper, switching between takes)

Here is a demonstration of Continuous jitter. (recorded in a loop in reaper, switching between takes) Maybe its not jitter as it seems to be earlier and earlier rather then just moving about?

It also looks like the "Jitter" or "earlyness" is worse with a higher buffer.
512 Buffer and it jumps from 127 samples to 433 in the next take.

As opposed to 16 buffer where it moves from 55 to 72 samples.

BTW: I did indeed have some smoothing on the gain module in my previous examples. ;)

[lalalandsynth]

Here is my setup , basically for this test though I am just sending a clock ramp to a cable table and from there to a gain module (no smoothing this time ;) )