Sjoerd

I have a problem with groove~ and can't solve it.

After recording, say, one bar, I calculate the bpm. Then, I tell the groove~ object (and the transport) what the originaltempo is. The weirdest thing here is, sometimes the groove~ object calculates an originaltempo which has nothing to do with what I have send. It can be a number 10 times as big. After that, the audio starts crackling, sometimes.

If this would happen all the time, I would know it was me. I started patching from scratch about three times and run to this same problem over and over again. Thoughts anyone?

Here is the patch. Just try to record one bar of music. Most of the times it works, but it is about that sometimes....

I have a problem with groove~ and can't solve it.
After recording, say, one bar, I calculate the bpm. Then, I tell the groove~ object (and the transport) what the originaltempo is. The weirdest thing here is, sometimes the groove~ object calculates an originaltempo which has nothing to do with what I have send. It can be a number 10 times as big.  After that, the audio starts crackling, sometimes.

groove-originaltempo-issue

Maybe croping the buffer at recording end causes that behaviour.

Try to just stop groove when recording starts, and send loop length at recording end,

together with 0 (start from 0) without crop.

Maybe croping the buffer at recording end causes that behaviour.
Try to just stop groove when recording starts, and send loop length at recording end,
together with 0 (start from 0) without crop.


This was just a short example to show you my question. I actually stop groove~ while recording. After recording, the buffer gets cropped and then send the original Tempo to groove~. Since I am following the global tempo, I have to crop in order t get the proper bar length. Groove doesn't understand groove points while following global tempo.

Or is there another way without cropping?

This was just a short example to show you my question. I actually stop groove~ while recording. After recording, the buffer gets cropped and then send the original Tempo to groove~.  Since I am following the global tempo, I have to crop in order t get the proper bar length. Groove doesn't understand groove points while following global tempo.

Or is there another way without cropping?


It is maybe the matter of execution order.

Try this patch with few little changes included.

It is maybe the matter of execution order.
Try this patch with few little changes included.



I have found another solution by sending the max loop point to groove as signal, than I don't have to crop the original buffer. Both work fine, is there one version you prefer?

Wow, yeah this works perfect.
I have found another solution by sending  the max loop point to groove as signal, than I don't have to crop the original buffer. Both work fine, is there one version you prefer?

It is definitely better to go without croping buffer.

You also don't need to send size messages to buffer, delayed

Well it is faster to upload cleaned patch...

It is definitely better to go without croping buffer.
You also don't need to send size messages to buffer, delayed
loop size etc
Well it is faster to upload cleaned patch...
May I ask why You use ramp for Tempo ?


Unfortunately it doesn't work with the max looppoint as sig~ After a while (very irregular, mostly 24 - 32 bars), the groove~ just restarts and isn't locked to the global transport anymore. Why is this happening?

And I have been experimenting with gen~ ipoke~ since I want to be able to overdub in different speeds, but keep the pitch. I get glitches there as well. Will send the patch in the next post.

And I have been experimenting with gen~ ipoke~ since I want to be able to overdub in different speeds,  but keep the pitch. I get glitches there as well. Will send the patch in the next post.


Here is the patch with the gen~ ipoke~ included.

It works sometimes, but after a while I get gen~ audio processing exception: Too many iterations (runaway loop) and then the audio starts crackling. I am planning on releasing this software the sooner the better, but can't get my head around this problem for weeks now.

Here is the patch with the gen~ ipoke~ included. 

It works sometimes, but after a while I get gen~ audio processing exception: Too many iterations (runaway loop) and then the audio starts crackling. I am planning on releasing this software the sooner the better, but can't get my head around this problem for weeks now.


Why don't You stay with old crop version ?

One can find better ways of copying and croping buffer,

which would not disturb (I hope so) the other loop parts.

And what for do You use the global transport ?

Syncing to other loops ? It is not visible from the patch You posted.

Talking about overdub in other speeds than 1, 05, forward and reverse :

only karma~ external does the job decently.

Why don't You stay with old crop version ?
One can find better ways of copying and croping buffer,
which would not disturb (I hope so) the other loop parts.
And what for do You use the global transport ?
Syncing to other loops ? It is not visible from the patch You posted.
Talking about overdub in other speeds than 1, 05, forward and reverse :
only karma~ external does the job decently.


The patch is pretty big, lots of GUI as well... I have two loopers, synced or not synced. You can set how many bars you want to record, or x (even, yet) or free running. Then, you can play or stop up to 200 pre-recorded loops, all synced to each-other. With launch quantisation, all synced to the global transport.

If no loop or looper is running, the first one to play starts the global tempo. All the others will follow.

Does karma also deal with splice or interpolation or time-stretching, so I can record a loop at 120 bpm and overdub at 100 or 140 bpm? And the fact that it doesn't have an audio sync out made it hard to sync other loops to. I could give it another go...

If no loop or looper is running, the first one to play starts the global tempo. All the others will follow. 

Does karma also deal with splice or interpolation or time-stretching, so I can record a loop at 120 bpm and overdub at 100 or 140 bpm? And the fact that it doesn't have an audio sync out made it hard to sync other loops to. I could give it another go...


Hey man, could you pm me ( sjoerd (dot) sanden (at) gmail (dot) com)? It would be great if you could help me out for a week. There are just somethings I can't see through anymore. I have been working for months on this patch and I am sure there are things which can be optimised. Are you interested in such a thing? I can pay you as well... Cheers

Unfortunately, I am too busy at the moment, to get involved into Project that has such complexity.

In addition, I am leaving for 1 month tour next week, so getting involved is impossible.

But of course if I can help with this or other part, when I get time to log here,

Unfortunately, I am too busy at the moment, to get involved into Project that has such complexity.
In addition, I am leaving for 1 month tour next week, so getting involved is impossible.
But of course if I can help with this or other part, when I get time to log here,
I would be glad to try to help.


Too bad :) But thanks a lot helping me out this far, I will keep you posted once in a while.

Too bad :) But thanks a lot helping  me out this far, I will keep you posted once in a while.
Enjoy your tour!


You are welcome, I know that feeling - getting a bit stressed when things don't go the way they are expected.

But from that experience, I learned also that sometimes it just isn't possible to do a project without

making a proper plan, and analyse if it is realistic.

And I mean really doing commercial project for custommers, just to find out that it does not work

the way I expected, being forced to reduce functions and options, in order to make it rock steady.

So if You allow me, I will give You this advice - consider at least some options - what to do in case

Maybe going down from 200 to 50 loops could fix the things for You, maybe something else,

You are welcome, I know that feeling - getting a bit stressed when things don't go the way they are expected.
But from that experience, I learned also that sometimes it just isn't possible to do a project without
making a proper plan, and analyse if it is realistic.
And I mean really doing commercial project for custommers, just to find out that it does not work
the way I expected, being forced to reduce functions and options, in order to make it rock steady.
So if You allow me, I will give You this advice - consider at least some options - what to do in case
this or that does not work.
Maybe going down from 200 to 50 loops could fix the things for You, maybe something else,
but something has to be done.


It's been a while, but I still have problems.

I have to crop the buffer before I send the originaltempo to groove~, otherwise groove~ calculates the originaltempo based on the first length of the buffer~ (which is 10000ms and I calculate the new length based on how long I record). I can't send originallength and originaltempo both to groove~ if the length of the buffer doesn't correspond.

How do I know the cropping is finished, so I can proceed to the next command?

It's been a while, but I still have problems. 

I have to crop the buffer before I send the originaltempo to groove~, otherwise groove~ calculates the originaltempo based on the first length of the buffer~ (which is 10000ms and I calculate the new length based on how long I record). I can't send originallength and originaltempo both to groove~ if the length of the buffer doesn't correspond. 

So calculate length,
crop buffer
send originaltempo
start transport

How do I know the cropping is finished, so I can proceed to the next command?


Hi Sjoerd, just logged in to see what is going on arround, and saw Your post.

I am still on the road, but get a bit time to post here.

So, let's get to the stuff - what You want has to be done very fast and secure.

I don't know the structure of the whole project, but looking at the the part I know allready,

I had a thought to use 1 dedicated buffer to record into , and copy / replace recorded audio

into playback buffers which would be linked to groove objects with all that transport, tempo etc stuff linked.

Mr. Eric Lyon created el.buffet object which does very fast buffer copy, and many other usefull operations.

Max 6/7 32/64 bit is available, and what is important for You, this objects bangs when operation is done.

So You could record into rec buffer, on recording End resize and copy recording into playback buffer,

and when copy is done, use "done" bang to update messages to groove.

I think that even OP.buf java based can bang when done, but it is veeeeery slow compared to el.buffet.

This is download link for the whole package:

http://disis.music.vt.edu/eric/main/wp-content/uploads/2016/06/LyonPotpourri-3.0-Package-06132016.zip

Hi Sjoerd, just logged in to see what is going on arround, and saw Your post.
I am still on the road, but get a bit time to post here.
So, let's get to the stuff - what You want has to be done very fast and secure.
I don't know the structure of the whole project, but looking at the the part I know allready,
I had a thought to use 1 dedicated buffer to record into , and copy / replace recorded audio
into playback buffers which would be linked to groove objects with all that transport, tempo etc stuff linked.
Mr. Eric Lyon created el.buffet object which does very fast buffer copy, and many other usefull operations.
Max 6/7 32/64 bit is available, and what is important for You, this objects bangs when operation is done.
So You could record into rec buffer, on recording End resize and copy recording into playback buffer,
and when copy is done, use "done" bang to update messages to groove.
I think that even OP.buf java based can bang when done, but it is veeeeery slow compared to el.buffet.
This is download link for the whole package:
http://disis.music.vt.edu/eric/main/wp-content/uploads/2016/06/LyonPotpourri-3.0-Package-06132016.zip


I ran across Eric Lyon a couple of years ago, but forgot about him., thanks. This is a good direction, definitely the fact that it 'bangs' when an operation is finished. The idea of working with two buffers, one to write one to read and copy in between them, is an interesting approach. This way, I don't have to use crop.

Nonetheless, I get an error now saying, 'buffer~ can't resize now' ... Regardless in which order.

I also changed my approach of telling the groove~ what the length is, instead of the bpm. May be that helps

Hey man,
I ran across Eric Lyon a couple of years ago, but forgot about him., thanks. This is a good direction, definitely the fact that it 'bangs' when an operation is finished.  The idea of working with two buffers, one to write one to read and copy in between them, is an interesting approach. This way, I don't have to use crop.

Nonetheless, I get an error now saying, 'buffer~  can't resize now' ... Regardless in which order.

I also changed my approach of telling the groove~ what the length is, instead of the bpm. May be that helps 

Here is a simple patch which might help You to sort the order of executing the resize, copy, crop etc messages.

I don't use max 7, and can't help You with groove tempo and other things, but the idea is

to get recording done, copy sound to dedicated playback buffer, crop it, and then set buffer and it's length, tempo

The trick is to get this all done without noticable drop out in playback, and to have background operations

like initialising the playback buffers ( setting time to max length) without affecting playback of allready playing buffers

Here is a simple patch which might help You to sort the order of executing the resize, copy, crop etc messages.
I don't use max 7, and can't help You with groove tempo and other things, but the idea is
to get recording done, copy sound to dedicated playback buffer, crop it, and then set buffer and it's length, tempo
or whatever is needed to groove object.
The trick is to get this all done without noticable drop out in playback, and to have background operations
like initialising the playback buffers ( setting time to max length) without affecting playback of allready playing buffers
or new recording ones.


Something like this. only, I get the message can't resize now...

gen~ does the job right now. It is fast, but still not accurate enough. I also chose not to use ipoke~ anymore, since it doesn't do what I want.

I am having issues now with the amount of groove~ objects in my patch. The audio is already distorted after 8 instances of groove~. Though in timestretch, I was not expecting this. Any thoughts on how to solve this? maybe with play~ and stretch. It would be offline then, but it seems the only solution.

Something like this. only, I get the message can't resize now...
gen~ does the job right now. It is fast, but still not accurate enough. I also chose not to use ipoke~ anymore, since it doesn't do what I want. 

I am having issues now with the amount of groove~ objects in my patch. The audio is already distorted after 8 instances of groove~. Though in timestretch, I was not expecting this. Any thoughts on how to solve this? maybe with play~ and stretch. It would be offline then, but it seems the only solution.


The message can’t resize now… indicates that the order of copy-crop is not executed in right order.

In the patch I posted it works, so You must have placed it into some other situation.

It is difficult to give further advices, one can throw ideas, but that is just fishing in the dark,

You say audio is distorted (CPU overload ?) when 8 grooves~ in stretch mode are involved ?

What is I/O and Signal Vector size set to ?

For real time Loop recording without direct audio-through, it can be left at default 512/64.

The message can’t resize now… indicates that the order of copy-crop is not executed in right order.
In the patch I posted it works, so You must have placed it into some other situation.
It is difficult to give further advices, one can throw ideas, but that is just fishing in the dark,
without knowing the whole situation.
You say audio is distorted (CPU overload ?) when 8 grooves~ in stretch mode are involved ?
Is that the limit of Your CPU ?
What is I/O and Signal Vector size set to ?
For real time Loop recording without direct audio-through, it  can be left at default 512/64.


just wanted to let you know that I have a steady looper now. I use a combination of calculating the original length (in ticks) based on the tempo and the (unchanging) length of buffer 1 with 'translate'. Then, the max loop point is set in ticks as well, this all is working within 3 ms, which is great. After my 'deferlow' I duplicate and crop the audio in another buffer and set the new original length.

This was all necessary to keep 'groove~' in @lock 1, which it does now.

I changed the I/O to 128 and now 20 grooves can play at the same time with @timestretch 1.

Thanks for your help. And still, if you know an alternative for ipoke~, then my looper will be able to overdub after I have changed the tempo...

Hey man,
just wanted to let you know that I have a steady looper now. I use a combination of calculating the original length (in ticks) based on the tempo and the (unchanging) length of buffer 1 with 'translate'. Then, the max loop point is set in ticks as well, this all is working within 3 ms, which is great. After my 'deferlow' I duplicate and crop the audio in another buffer and  set the new original length.
This was all necessary to keep 'groove~' in @lock 1, which it does now.

I changed the I/O to 128 and now 20 grooves can play at the same time with @timestretch 1. 

Thanks for your help. And still, if you know an alternative for ipoke~, then my looper will be able to overdub after I have changed the tempo...


Hi Sjoerd, nice to hear from You , and in first place to hear the good news about the looper.

Overdubbing in speedchanged looper is damn difficult.

I know that syncing several loops together makes karma~ no option for You,

but it is only looper external I know of being able to do that kind of stuff.

There were also some Gen versions, but no sync of several loops either.

Hi Sjoerd, nice to hear from You , and in first place to hear the good news about the looper.
Overdubbing in speedchanged looper is damn difficult.
I know that syncing several loops together makes karma~ no option for You,
but it is only looper external  I know of being able to do that kind of stuff.
There were also some Gen versions, but no sync of several loops either.
Maybe that'll change one day...


Groove~ originaltempo issue