Syncing calf delay plugin to external midi clk not working

Software
1

I’m not shure whether this is buggy or not, and whether it applies to other plugins too.
I cannot get the delay synced to the external midi clock. I tried a lot.
Tempo setting are on external midi syncing, plugin is on syncing to host.
With or withou a running pattern in the zynseq, the plugin delay time gets not synced to the bpm of the external midi clock. :roll_eyes:

Should I stop trying because it’s not working at all? Or did I misunderstand something?
sooperlooper gets synced to the external midi clock. But calf vintage delay does not.

System is:
zyncoder: stable (6d54a48)
zynthian-ui: stable (67b6afa)
zynthian-sys: stable (c0f40e8)
zynthian-data: stable (052465e)
zynthian-webconf: stable (d92c31d)

Any hint… regards

2

Hi @gitnob !

You should try the testing/staging branches. There are a lot of improvements and bugfixes in this area (clock/sync).

Could you tell the exact name of the plugin you are using? There 3 calf plugins in the delay category:

  • compensation delay line
  • reverse delay
  • vintage delay

Finally, could you explain the exact steps you are following?

Thanks!

1 Like
3

Hi jofemodo,
I’m using the vintage delay from calf on a audio single chain as audio fx.
As I said: In the overall tempo settings I’m using external midi clock syncing. An external source delivers Start, Stop and Clock Midi Events.
Within the calf vintage delay I was setting the sync to “Host Sync”, so I thought the delay time would be driven by the external midi clock source. But it wasn’t in anyway synced to the external source.
It doesn’t matter whether a pattern in the zynseq is playing or not.
The audible delay has always the same delay time independent of the external tempo. It is only influenced by the knob “Host BPM”.
IMO there should be no knob to influence the “Host BPM” because this bpm should be set by the jack transport clock.
Hence → plugin is not synchronized to external midi clock.
Is this a bug/not working feature? I think yes.

1 Like
4

It seems a bug of calf vintage delay. It doesn’t take the BPM from the host clock. It doesn’t matter if it’s internal clock or external MIDI clock, you have to put the BPM by hand in the plugin controls. Not nice. It should do it automatically when selected “sync”. Right now, the “BPM” and “sync” modes work exactly the same.

If you are not going to play a lot with the BPM, you could set the BPM by hand. It works quite nicely then :wink:

Anyway, i will take a deeper look. Please, could you open an issue in our issue tracker?

Thanks!

1 Like
5

I just tested it with a regular linux system.
Interesting…
If I was calling jalv to use the plugin, the jack transport to calf vintage delay was not working, but if I use carla and loading calf vintage delay, the jack transport was working perfectly…
Couldn’t test it in zynthian because the carla (after installing) was not showing up correctly :frowning:

6

OK! Let me investigate the issue. For your comments it seems it’s Jalv related.

Thanks!

7

I just pulled all recent changes from jalv’s upstream repository and it doesn’t seems to improve.
We will have to go deeper in the rabbit hole …

Regards

1 Like
8

Curious! I just tested with NoizeMaker, and the arpeggiator work perfectly OK and take the tempo from the “host tempo”, syncing to internal or external clocks. But when taking other delay with clock-sync, like Bollie-delay, it fails in the same way than Calf Vintage-delay.

1 Like
9

More! I checked the TTL files for both delay plugins and i found that Host BPM propiertiy (and only this one!) is marked like this:

lv2:port [
    a lv2:InputPort ,
        lv2:ControlPort ;
    lv2:index 0 ;
    lv2:symbol "tempo_host" ;
    lv2:name "Host/MOD-Tempo";
    lv2:default 120 ;
    lv2:minimum 6 ;
    lv2:maximum 1000 ;
    lv2:portProperty mod:tapTempo ; 
    lv2:designation  time:beatsPerMinute ;
    units:unit units:bpm ;
]

Observe the lv2:designation time:beatsPerMinute ; line. It’s referring to:

LV2 Time

I can’t find anywhere that propierties designated like this must be updated when BPM changes, but it could be easily done.

Regards,

1 Like
10

I also stumbled across these lines. Because I’m not a lv2-ttl-file-understander I was completely lost.
Fingers crossed that you’ll find a solution. :crossed_fingers:

1 Like
11

Where exactly should this property be updated? Is it updated automagically by the jack transport system? Or should it be updated anywhere in the zynthian system? I wrote an issue report to zynthian’s issue-tracker.

12
1 Like
13

I’ve a solution. It’s pushed to staging-2307 and testing branches. Simply update and test.
Don’t forget to change the plugin’s “Timing” control to “Sync”, in the last control page :wink:

The proof:

Enjoy!

3 Likes
14

Thank you, I saw you’re changed code(s) and would like to test … but …
I’m not sure to switch to staging-2307 branch, because I don’t want to break anything. Do you think it’ll be quite safe to do it and… can I switch back again? … can I only switch zynthian-sys to test it?
This is why I’d rather wait for the staging branch to be merged into stable.
BUt as I said, thank you for updating the (lv2) code. :+1:

1 Like
15

I recommend you to use another SD-card . Going back from testing/staging to stable is not 100% warranted operation. It normally works OK, but if you want 100%, better use a second SD-card.

Regards

1 Like