Clockramp not reliably running.

[Christoph Hart]

@DanH it appears to be crashing in a routing FX. Are you using multichannels?

[DanH]

@Christoph-Hart I'm using routing fx yes. Not multichannels in scriptnode if that's what you meant?

I'll try without the routing now

[Christoph Hart]

@DanH no I meant more than 2 channels in the master chain.

[DanH]

@Christoph-Hart Yes. So I removed the FX Routing modules and it still crashed, but after reducing channels to only 2 it opens.

[lalalandsynth]

@Christoph-Hart My projects started crashing on opening (simpler were fine), I went back one version , to the "fix plugin compilation"

[Christoph Hart]

@lalalandsynth Yeah, I noticed that too. I've pushed a fix that fixes it here, but let me know it it still crashes.

[DanH]

@Christoph-Hart Projects open fine now :)

Will try an export

[DanH]

@Christoph-Hart Exports fine, working in Logic. It's an FX plugin. I set my LFO with Tempo Sync on and Clock Sync on. What should I be expecting? I ran a loop and the lfo loops normally without any retriggering when the loop starts again (I looped it between oscillations).

Setting sync to external was mentioned - should I do this and if so where do I do it?

[lalalandsynth]

@DanH ?
When everything is working like it should , you should be able to start your playback say at 1/4 into the bar and the lfo should start there. It should also allow seeking and looping within a bar , say a1/4 from the start and a 1/4 from the end.

btw, are you exporting as AUv2 or Auv3 ? Out of curiosity.
Did you use this code

// Create a transport handler
 const var transportHandler = Engine.createTransportHandler();
 
 // The grid callback needs to be enabled for the LFO
 // to sync itself to the clock.
 transportHandler.setEnableGrid(true, 8);
 
 // The clock will now prefer the external clock source. This
 // means that as long as the external clock isn't running
 // (the DAW playback is stopped) it will use the internal clock
 // and as soon as the DAW playback is started it will resync
 // itself to match the DAW position
 transportHandler.setSyncMode(transportHandler.PreferExternal);
 
 // Start the internal clock. This will cause the LFO to run
 // even if the DAW playback is stopped. (if you omit this line
 // the LFO will not move unless the DAW playback is started).
 transportHandler.startInternalClock(0);

[lalalandsynth]

@Christoph-Hart Works fine now !

[DanH]

@lalalandsynth Ah, there's the code! Will try again tomorrow, thanks!

AUv2. What's the process for v3?

[lalalandsynth]

@DanH The process is long, painful and arduous, and after that there seems to be an issue with resizing. :)

https://forum.juce.com/t/auv3-resizing-issue-on-macos-not-ios/43811/9

[DanH]

@lalalandsynth well I won't bother in that case!

[lalalandsynth]

@DanH We are only chasing AUv3 for the midi out. Unless its possible to have midi out in a midifx plugin for AUv2 ?

Not a logic user so I have no idea ?

[DanH]

@lalalandsynth I don't either I'm afraid!

[lalalandsynth]

@Christoph-Hart is it possible to retain seeking while enabling/disabling loop with a button ?

It can be useful to loop 4 bars in a daw while the table is set to 8 bars and does not loop on 4.

[Christoph Hart]

@lalalandsynth Not sure what you mean here?

[lalalandsynth]

@Christoph-Hart can the looping be disabled?
I am referring to it following/looping the selected area in a daw.

Not essential...but in some cases you might have a 4 bar loop set in the daw but the table set to 8 bars.

When set to loop as is now the default it would play half the 8 bar loop and then start again as opposed to being able to play the first 4 bars on the first loop and the other 4 bars in the second loop as it did before looping was added.

In these admittedly edge cases it could be useful to be able to disable the loop function (daw selection)

Hope i am making sense here?

[Christoph Hart]

@lalalandsynth I‘m afraid thats too much of an edge case for me - just make the Daw loop longer…

[lalalandsynth]

@Christoph-Hart Fair enough :)