Looper W/Midi Sync causes CPU spikes & Audio Glitching

#1

Hello all I've been lurking and learning for a long time but could do with some advise/suggestion.

I have been building a patch based around SirSICKSIC's Factotum & Loop4 modules, I have been slowly refining it and little by little getting it to where it's a lot of fun and I am learning new tricks as I go as the patch require it.

The patch isn't that complicated, but I have come unstuck, when the patch is running with an external midi clock I am seeing spikes where normal usage is around 70% it spikes to around 90-100% and this is causing audio glitching when recording loops. Is this due to the instability of the midi clock when recording the loop, is it that I'm straining axo's resources, is it how I have laid thge patch out....any and all ideas will be greatly received, thanks for the help.

#2

Loop4 Fact.axp (14.3 KB)

Here is the patch

Loop4 Fact.png2880x1754 922 KB

#3

Hi,

I had a brief look at your patch, nothing jumped out as obviously wrong. The only thing I did notice is you're using a lot of dials with red outputs. I'm only guessing but I think these might use more processing than a standard 'dial p' with a blue output. I also tend to use midi in objects rather than the cc drop down to assign controls, though I doubt that's the cause. I have no idea if these things have anything to do with your issue.

What's your clock source? I've had trouble with getting clock out of my laptop(ableton)... Not just for axoloti, It works fine with some gear, and not with others (My work around is to have a clip in Ableton that sends out the same note every 16th and send that to the axoloti, then use the note gate input as a 4ppq clock, works fine...).

If you can, try syncing to something else that sends clock and see if that's any better?

I also get problems if I have Ableton and the patcher running at the same time, just something to be aware of.

#4

Thanks Matt all great suggestions,

I'm getting midi clock from an Elektron Digitakt, will try other clocks to see if that helps.
I used the red output dials due to the red inlets on the loop4, from memory the blue dial p was having no effect.
I guess using the dropdown cc's maybe require more resources since they update graphically, will try to implement using midi objects. Thanks for the explanation of your workaround for the clock, that gives me another option. My goal is to not run the patcher at the same time as the loopers, so I will try to see if that has any effect on the glitching.

Maybe I need to smooth the clock somehow, thanks for all the help

edit: just realised the inlets on the loop4 are green, will try a few other solutions for midi control of these inlets

#5

You can connect blue outputs to green inputs, but remember that a blue positive dial goes from 0-64... So if what you're connecting it to is expecting different values you need to scale it.

For example, the 'qnt' input on factotum expects 0-32 (at least, that's the maximum on the parameter) so chances are if you connect a blue dial it'll do nothing above it's halfway point. Or do something unexpected.

This is how I'd connect a midi cc to that input=

20190207_134922.jpg2015x1511 1.71 MB

#6

Thanks again Matt, you're a legend

I'll try that, spent a short while earlier with your CC in suggestion and it may be optimism but I think it's better, really appreciate your knowledge and willingness to share it....I connected a cc midi in with integer outlet seemed to work, but, will try your scaling method later

integer in Factotum.png1132x796 82 KB

#7

i would try this for scaling, it will be cheaper:

#8

That's interesting, never quite got my head round the >> objects... I'll have a play, could be really useful. Cheers

#9

Thanks Lokki that's really helpful, so that effectivley halves it in that setup, and cheaper is exactly what's needed

#10

x>>n

where n equals number of divisions by 2.

so 32>>2 = 8

#11

no that is half of half! :slight_smile: as explained in my post before this...