Im trying to get looper with external midi sync work. Ive tried numerous different setups. Few times i thought i was close to getting it work but always something wrong with the setup. For the looping part i have successfully set up. The syncing with external midi clock seems to be the hard part. Im confused how to connect the looper to the clock. I messed around with a looper contribution made by user SPTKN (if i recall correctly ), there was somekind of syncin possibility but didnt find how to connect it to midi clock yet :(. I also have this weird issue that if I move any of my controller midi cc knobs the playing loop stops immediately, ive been trying to fix that for few days now with no luck.. Frustrated but also very very excited about the possibilities of this awesome device and software. My greatest achievement so far has been getting informative midi synced metronome led blinks with axoloti leds 
and few majestic synth patches. This was my first post btw 
sorry about my newbishm and poor english
Rbrt Contributions
@mindsetup
midi clock sync for loopers is something even the big companies that make hardware loopers seem to struggle with.
The approach posted here will work semi well, but hey it's a start 
I'm trying to make a delay with your ldub object, on the basis of the patch you mailed me. I was wondering if it was possible to sync the delay time to a clock.
ps more brutal aproach, still doesnt really work...
...yep because midi-clock tends to be unstable,and even if it was stable,the resolution of the clock is not as high as the samplerate.this will cause the loop and the clock to 'drift apart'.
so,either the clock or the loop has to be re-synced every once and then.it's probably easier to re-sync the loop,but this will introduce clicks.
I could imagine a scenario where the loop is crossfaded with itself (fading out the playing loop,at the same time re-starting a second instance of the loop and then fading in again)
but this would introduce some latency...since the loop has to be faded out before re-syncing.
hmmm...
Yeah I also read a little bit about that. But there are loopers that do this without clicks.
You're two loop playbacks crossfade Idea sounds reasonable but I don't understand why there will be latency.
Any Ideas on the range/digital table delay thing? That one doesnt need to stay tight or anything I only want to have a time synced delay effect, but no need for 100% correctness.
btw just working with you midi objects, pretty great actually for midi feedback! But I hate novation for having an octave jump from button 4 to 5 that makes patching a bit unpractical...
What does "Blocksize" do?
'blocksize' is a concept that I think makes sense for step-sequencing with 'parameter locks' a la elektron.
example :: if 'blocksize' is set to '8' ,
one step of a sequence corresponds to 8 consecutive elements of a table.
the first step is always note on and velocity.
so,objects that receive a 'step count' of zero will send out (or display via midi) a block of 8 elements at the same time,
starting from zero,'step count' 1 will read 8 elements starting from 8...and so on...
I will introduce/document some objects for step-sequencing using this concept soon.anyway,they are already in the library under rbrt/seq.I think they are stable enough to start using them.
...simply because axo doesn't know when the next midi-clock comes in.once it arrives,the first 'player' has to be faded out BEFORE its stopped (while the other one is faded in).otherwise,clickyclickyclick.
so,the latency I was going on about will actually be the time needed to fade out the first 'player'.
but I guess a maximum of 5 milliseconds will work..
...I will have a look at it soon,I hope tomorrow.aah also at the beat-slicing-thingy...
ok makes sense. couldnt you some compensate for the latency with the table read then?
cool!
I made a patch with a simple looper that should stay synced to a clock even if the clock is moving... hope it's relevant to post it here since it's the most looper-friendly thread!
simpleloopermidiclkslave.axp (12.4 KB)
Wow that works extremly well, thx for sharing this here!
I tried to open a thread in patching for this, where I described a similiar Idea as your aproach but no one really posted yet.
I will definately implement this in my patch.
One thing that could be great if there was option to let the loop change speed according to the clock, like with a tape or abletons looper.
To do so one would need to store the tempo during recording, measure the current tempo and divide current tempo by old tempo. The resulting ratio would be hooked up to the speed playback.
Sounds simple but dividing is really hard in axoloti
please have a look of what I just stumbled upon!
if this works for you,we can finally divide integer by integer and get a float result!
i by i.axp (5.3 KB)
rbrt you are a hero!
It works perfectly well!
simpleloopermidiclkslave repitch.axp (17.0 KB)
The only thing that doesnt work now is the retriggering since I use Ldrive instead of wave play. Could you help me out @valmir?
I'm also wondering:
Your aproach waits for the next 24ppq tick to start recording. What is if my transient slightly before the tick? I just tried out in Ableton how long a 24ppq is, musically speaking it could be a lot.
Originally this is what I liked about rbrts aproach, you always have the transients and all that.
Some solutions:
- higher resolution 96ppq, there is an object in the library for 24-->96pp
- measure the time between record start and first clock tick. feed this into startpoint so that loop is being resetted on clock tick.
Which object is that?
I have just been multiplying 24ppq with 4 = 96ppq This works fine too, but always nicer with dedicated objects
Order of execution has changed in your patch. Check this out, should work
simpleloopermidiclkslave repitch.axp (17.0 KB)
latch_1 and counter_2 must be in that awkward position for it to work.
Using ldrive has nothing to do with it, but has another drawback: it will loop when reaches the end of range, even if that occurs before the resync. Try recording 1,2,3,4 and set the loop point to 5, you'll have 1,2,3,4,1 looped. I'm not very good at explaining, hope I made myself understandable...
Agreed, that's why in my live axolooping setup (first gig with it tomorrow!) I decided to sync tracks only with relation between ranges, an then generate a midi clock from the master loop length for external devices...
@rbrt : you are the man, and integer divided by integer to get a float is THE THING!!!!!!!!
That's because it's not used as a cyclic counter; it will feed the number of 24ppq cycles occurred during the recording to the latch and reset. I didn't find a linear counter, is there any? I was lazy, but I think I could have done it with a latch, a +1 and some logic...
yessss it does...
since as of now I can actually divide with axo,I re-worked 'lrec multi' and 'ldrive multi'.
I put them inside a new folder called 'testing' in the library.
basically,'ldrive multi' has a 'phase' outlet now,so every 'ldrive' could be the 'master-transport'.
no need for additional phasors anymore.'lrec' is just a bit more efficient,as well as 'lsync'.
there's a patch 'loop_multi_testing' with the new objects in there.
maybe you could give them a try?
I quickly tried your testing patch. It works, but I was wondering how you would do stuff like multiplying or dividing the quantization phase.
@valmir
I got in to the habbit of ordering patches left right up down, since it's the most ram efficient way and helps me understand what's going on. I didn't realize you put the objects into this order on purpose.
The new patch you sent me works, thx
I'm going to have gig with my setup soon and I jammed a couple times already with @logsol, looking forward to using it live so good luck!
Great to share developments here guys!
Blablabla.... @rbrt supplied us with another useful object -1shot- that solve also this...
simpleloopermidiclkslave repitch.axp (17.3 KB)
this idea start to be pretty solid, is it maybe time to get a second axo to slave to my other looping patch?
I love this little thing!
Looper project doesn't loop