Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior on sample delay modules #447

Open
Yoppez opened this issue Dec 1, 2022 · 6 comments
Open

Unexpected behavior on sample delay modules #447

Yoppez opened this issue Dec 1, 2022 · 6 comments

Comments

@Yoppez
Copy link

Yoppez commented Dec 1, 2022

Version 22.11

When using Grande's SampleDelays, VarSampleDelays and Bacon Music's SampleDelay there is the same unexpected, but consistent, behavior.

I measured the samples by recording the stereo audio with the left channel having the original signal (for example, a trigger) and the right channel connected to the delayed signal with the delay module (or more of the same delay module chained together), and then confronted the samples.

When setting a sample delay module to n samples, it actually behaves like it is set to n - 1 samples.
So, setting the delay to 1 (or connecting a cable to the +1 on Grande's SampleDelays) it makes no delay, setting to 2 (connecting a cable to the +2 on Grande's SampleDelays) it makes a delay of 1 sample, and so on.

I tested the modules with different sample rates (to be precise, on 48000 Hz and 192000 Hz in the corresponding Jack session), on Cardinal Jack standalone and as a plugin (I tested the plugin version through Ardour), both on Windows and Linux, the behavior is consistent.

I also tested the same modules on VCV Rack, and they behave correctly.

@dromer
Copy link
Collaborator

dromer commented Dec 2, 2022

Change in this behaviour is likely due to #410

@falkTX
Copy link
Contributor

falkTX commented Dec 2, 2022

yeah this is more like a feature than a bug. on VCV Rack there is a 1 sample latency per cable, but Cardinal is able to bypass this in order to reduce latency.
Rack modules assume this 1 sample latency is always present and compensate on the UI for it, which now ends up being wrong.

@falkTX
Copy link
Contributor

falkTX commented Dec 2, 2022

Try with 22.10 Cardinal release if you can, and compare results. That release still behaves alike Rack regarding the cable latency (apart from host audio and midi modules)

@Yoppez
Copy link
Author

Yoppez commented Dec 2, 2022

OK, I made some tests with Cardinal Jack 22.10 at 48000 Hz on Windows, and the results are very weird.
I'll write exactly what I have done in the hope that these results would be reproducible.

I first opened a new Cardinal session, I removed everything except for the host audio and selected the three delay modules that I have tested before + Pulses from VCV and Grande's Logic (to test the delay of a normal module). Then I recorded like I did before, meanwhile moving the cables to connect a different module to the host audio. So far so good, Logic makes 1 sample delay, but like you said before this is expected on 22.10, and the sample delays worked correctly with the set delay on the modules.

Next I leaved only Grande's SampleDelays, Pulses and Host audio, and made 128 copies of SampleDelays chained to the +1 delay. I made that by repeatedly ctrl-shift-d to get from 1 module to 2, then 4, then 8 and so on, while connecting the first half to the other in the while. The expected delay should be of 128 samples, but I measured a delay of 62, even when generating more triggers.

Then tested the same previous setup with only 64 copies of SampleDelays by ctrl-z the last copy/paste that I made before. The expected delay should be 64 but I got 29.

I don't remember the exact details later, but then I re-tested only one Grande's SampleDelays with output cable connected to +1 by removing all the delay modules and picking a new one, but I got no delay this time. Then I tried to remove Pulses and get a new one too, this time there was the expected 1 sample delay.

I also retried to make the 128 copies test again, getting a new Pulses module, this time i got 52 samples delay instead of the previous 62 and the expected 128.

I tested 128 chained Grande's Logic as well, but even with this the results are inconsistent.

tl;dr: on Cardinal 22.10 it's not clear how the sample delay (on normal modules as well) behaves, but it seems that it depends on how the modules are created / deleted.

@falkTX
Copy link
Contributor

falkTX commented Dec 2, 2022

it seems that it depends on how the modules are created / deleted.

yep, and this is the behaviour on VCV Rack as well.
that was the main reason for the change in 22.11, so we can finally get consistent results.

when connecting a bunch of modules in series, the latency from 1st to last should be zero, but on Cardinal 22.10 and VCV Rack it is arbitrary, based on when the module was first added to the engine.

if you try the same as you did with Cardinal 22.11, in theory the results will be consistent.

@Yoppez
Copy link
Author

Yoppez commented Dec 2, 2022

but on [...] VCV Rack it is arbitrary, based on when the module was first added to the engine.

I tested on VCV rack and it was consistent there, both normal modules and sample delay, even when removing / adding modules.

if you try the same as you did with Cardinal 22.11, in theory the results will be consistent.

I made the same things that I made when testing the 22.11 version, creating and deleting the modules like I did before.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants