Looking for a one cycle CC LFO for SYNC Restart

The one shot pipe I am looking for was asked for in other threads, so I hope it will be available in the near future.

It could also work as a ADSR ENV.

What I am tryin to do is generate a single message from a constantly midi synced CC LFO - I had a try to make the CC LFO spread out different events behind a dispatcher and take one of them to midimapped Bypass the pipe after one cycle. Problem seems to be that I have to kill the output of the pipe, cause the Input must constantly feed MIDI Clock into the CC LFO.

I will have a try with the Delay Pipe now, which can be used very creative as some user has shown

Have you tried using CC LFO in One Shot mode? You could map the Retrigger param to make it start once more for one cycle. PWM waveform could be used for a single message.

1 Like

This is one of the things I did already but:
I want to generate START Messages on Beat, so I have to let the CC LFO running. If it is stopped after one cycle then I have no chance to generate START Messages on Beat again cause I´ve lost the sync.

But if it is running all the time, it shoots START messages on every beat continously and this drifts apart so the restarted device is after all out of sync.

I still think that there must be a chance to map a Mute anywhere inside this pipeline after one single Start (on beat) is sended

Hey @racecube Eddy, just to be clearer on your scenario (which I only partially understand, I think :smiley: )

  • let’s say you have a running synced PWM LFO giving CC X with the correct values…

  • then you have Drop Transform which ordinarily discards those values…

  • …under what conditions would the Drop Transform be Bypassed:
    so allowing a value through (to create the Start message)?

A Drop Transform maybe a solution.

The thing is: I have a key pressed once generates an arbitrary STOP message and then the same key pressed again generates a START message but (!) in Sync.

So the START pipe has to have a CC LFO feed with constant clock that on the first beat creates a single START. No problem to make the Transform generate a START on beat 1 (dispatcher or arpeggiator helps here) so it does not on the other beats -but: It does it continously on every (!) beat 1, cause the pipe can´t be muted concerning the output of the pipe

OK, so I think you’ve got all your component parts of the solution

  • have your dispatcher/arpeggiator system generate the “START-making note”;
    running into the active Drop Transform

  • Have your START-STOP key generate a Toggle Mapping so that:

  • ON generates your immediate STOP whilst

  • OFF generates your “Drop Transform UnBypass” anytime in the beat before it is due to be triggered

Does that figure?

Aahh, the missing bit is to have the “Drop Transform UnBypass” message also trigger a delayed message to “Re-Bypass” the Drop Transform!

I think you got me (I ve seen your interest in “impossible” things over many other threads :+1: you are a real creative plumber of pipelines)

again we are missing simple toggle functionality :weary_face:

what about Toggle Mode?

Still struggling with Toggle Mode in the Map Section. You have to always save the whole Preset before Mappings get active?

Thats what I read from the linked site..

Not heard of that, Eddy, I use them like other mappings.

I’m not as confident with Toggle as I am with Scale, Slice and Clip so I tend to test a lot to make sure I’ve got the right settings.

In your case though, I think Toggle Note On & Off [0~127] should do the trick.
I’d need to see your preset to know how best to use it.

Midihub 2026.03.16 23.55.47.mhp (2.9 KB)

Maybe you want to have a look: I was already closer to the solution some hours ago, this state represents the rest of the work this evening and somehow lost in the forest again..but with some entertaining mapping :slight_smile:

Just feed it with clock (sequencer) and trigger it with note F#2 (the DIN MIDI CH3)

I’ll try to grab some time tomorrow (else it’ll be Thursday)

2 Likes

Nearly worked it out with this patch, needs a little fine tuning (not perfectly synced start (the SYNC CC 90 sometimes starts with value 65 sometimes with 64) and the whole patch should be independent of the state of F#2 when system comes up)

Midihub 2026.03.19 09.44.46.mhp (3.0 KB)

didn´t know that we can comment Pipelines, which is great!!…next step: Colours :wink:.

seems to be that a CC LFO is not reliable enough for that purpose. Maybe I have to take a dispatcher or a arp

Try mapping the “Manual Retrigger” parameter instead of the “Started” checkbox - it might align the LFO phase better.

1 Like

The CC LFO must constantly and reliable run as long as the whole system runs, it is kind of a parallel clock that only generates the trigger to restart a stopped device. So it is totally SYS common guided.

Maybe MAN RETRIGGER mapping on top and also try a mapping of OUTPUT ENABLED instead of BYPASS, experimentig with waveforms,depth and bit solution was not the key here

Hey, Eddie, sorry to have to tell you that something huge fell in to my lap since last reply so I won’t have headspace to study your presets closely.





just on this:

LFO must constantly and reliable run as long as the whole system runs, it is kind of a parallel clock that only generates the trigger to restart a stopped device…

…experimentig with waveforms,depth and bit solution was not the key here

if you want to let your LFO just run, another way of only listening on demand is to put a Filter after it which discards its output…
…and have a separate synced OneShot (PWM?) send a 0 then 127 to enable the Filter just for the period the next START is required.
Here, the OneShot receives Manual Retrigger within the required beat

one note to be aware of in case it comes into play:
if you’re using say a synced Saw Up with 0 on the beat: 127 won’t be because 128 (= next 0) will!.

still not reliable but close:

MIDIHUB ONE LFO SYNC.mhp (3.0 KB)

Try using 128Hz resolution on both LFOs.

1 Like

the problem in the last pipe is that it switches correctly the filter but the START message won´t get through reliable, because the filter swaps in some mysterious way.

I guess it´s got something to do with velocity of F#2 from the first pipe.