...thanx!!!
the old 'loop_drive' is the same BESIDES I changed the names of the inlets
(because 'hz' was really misleading since it's definitely NOT hertz)
'loop_drive multi' should work as well,as long as 'offset' is zero.
so far,as I understood,this shouldn't be a problem because objects are saved with the patch,
and are static with a patch?!?maybe I got something wrong there...
this happens with the patches i put into my github account as well sometimes. i have not yet found a pattern. clicking on the missing object and simply searching it again, fixes it for me.
4 slot loopstation.axp2 (58.2 KB)
works fine for me here... 1.0.11, with recent sync libraries.
this should not be necessary... if this is happening this mean the unique UUID of the objet has been changed, since the patch was saved.
... this would happen if you used 'add to library' to add an existing object to a different library.
objects are only saved in the patch if they are 'embedded objects', normal objects like these are not.
so if you change the object you should also upload a new patch.
this is why Id recommend, either uploading the patch to the community library (under library/patches/yourprefix), or save the 'example' as a help file (axh) which then goes in the same directory as the object.
Sorry for the late answer.
Syncing libraries was the solution.
I don't know why I thought that was automatic at start up.
Sorry again and thanks!
this is an option, if you go to preferences and then the library you can turn on auto sync.
(i dont do it by default, as not all users would like this, so manual seems the 'safest' way)
Ok I had to change some subpatches now everything works again.
I tried your new blocks, especially the patch you posted. I think the concept with one table for multiple loops is really efficient and the fact that there is only one recorder module makes it really transparent.
However the sync mechanism doesn't make to much sense for me, since I've kind of build my own mechanism. Maybe an Idea to make this more modular?
Furthermore it would be nice if you could for example select slot one, press rec, then select slot two press rec again and thereby end recording in slot one and start recording in slot two.
This is how I have it set up in my looper patches so far and I really like it because it allows for super fast build ups.
I am missing either a feedback inlet for the overdub module or a replace mode. The latter would allow for patching a feedback path yourself.
Because of these reasons I'll stick to my looper patch for now, wich I can send you if you like.
hey Simon,
I'd definitely be happy to get your patch,AND we should meet (I know it doesn't happen because I'm so fucking busy.and I got quite stuck with 'loop_multi' recently..I'll drop you a PM soon..)
in general I'm posting custom objects on this page,and I'm happy about feedback regarding the objects...
things like switching slots during recording is definitely a GREAT idea but this can be patched,there's no need to implement this in an object.
what does matter to me is the modularity,as you said:
during development,I tried a lot of different approaches .what happens,if you try to implement sync via patching (instead of inside one object) you get a lot of messy drifting of the loops,because in between objects,you are bound to K-rate.
with 'loop_multi', you get synced loops that only have a drift of 1-3 samples per loop.if at all.
I know this somewhat breaks modularity,but avoids the need to patch re-syncing mechanisms and most of all CLICKS.
cheers,Robert
Yes let's do it. My patch is a bit messy, but I'll send it to you later. And working on this together in the analog world seems like a great Idea, I've been out of town for a couple of weeks but am back now 
But can this be patched using only one loop multi? If that's the case I'd like to know how
Ok maybe I should investigate a little more how your sync mechanism works. My personal goal is to be flexible with the record quantization, like recording even 1count loops on top of 2bar our the other way around.
Could you also achieve clock sync too with it?
...should be possible with quite a bit of logic-patching around.the problem is recording has to be stopped shortly and then restart,and the logic has to manage this.I suppose it's going to involve 'kdelay' and quite a bit of 'flipflop' 
I just synced libraries again and did a small change to 'loop_multi' to allow switching slots while recording without creating a mess.
yep.I just did a phasor with a frequency divider..with some logic around,very looong master-loops can now set the global transport to 2/4/8 times the speed of the master loop.
there are help-files now for 'loop_multi' and 'loop_master', it's all in there.
...I started writing some help-patches for 'looper blocks' now,you can load them from the object's drop-down-menues.
Yes I thought it would be complicated, that's why I suggested implementing it into the object
I'm just at your help patch works really great for understanding, thx!
Any Ideas how to sync to clock? Set the master phasor according to incoming tempo?
thahanxx!
I just discoverd the 'wrap' - object 
and did a quick mod to it...
so the patch will be updated in some minutes..
implementing this feature is even more complicated,at least for me as a C+ novice...
midi clock?
but in general,yeah it's the phasor..
So you're actually implementing it? that would be awesome.
I hope you got what I meant, I meant like chained recording, so in the case of your object it would mean that if rec is on and another slot is selected, recording of the slot before is stoped and started in the new slot. Same procedure again for the slot and so on.
yes midi clock for example. Cool I think I have some clock sync aproaches from a month ago that I can apply here.
I'm still at your help patch. How I would record a 1count loop on top of a 1bar loop? Is there any way of dynamically changing how the quantization behaves?
now that would really break modularity 
but sounds like FUN...I'll give it a shot but it'll take some time..
fuck modularity when you can have Fun haha.
I'm not quite sure if I get this. Should I apply this to the signal that gets to loop_sync?
Just added overdub with feedback using your loop slave object. There is some abstract ticks/loop degradation going on but I think I like it. Kind of like the tape loop of the digital era.
hmm..just put another 'wrappo' behind the first...continue from there..
but I just found a limitation (I knew it was there)::'loop_multi' doesn't like recording in sync to a very fast tempo.
the shortest synced loop reliably working is around 1 second.I didn't find a workaround yet,I tried quite a bit..
yeah!it does work,doesn't it?!
the degradation is due to the the fact that after some iterations of overdubbing,you're reaching the dynamic limits of the table (32 bit) and then...CLIP
...I like syncing to 1 note so much that I improved the precision of 'loop_multi' and 'loop_sync' a bit,
so they should be working with very short loops now.
Very cool. 1quarter loops are really nice for setting up a 4/4 Bass drum, or in general have a really tight rhythmical foundation to build up further loops
I played a little bit more with your quantization engine and realized some things that don't make sense to me:
For example you record a one bar master loop. It is a short loop and you see the phasor going in one bar.
Then you want to layer a 2 bar loop on top. I assumed that If you press record it will wait until the phasor is at zero for recording and the same for stoping the recording but it doesnt seem to work like that.
If I press for example record on 3/4 of the phasor and then do the same for stopping I end up with a three bar loop. In order to get it right I need to press recording very short before the phasor is at 0, wich is extremly difficult and not how I would expect a syncing mechanism to work.
I would expect that if 1bar is the reference all of my actions are quantized to this reference. You know what I mean? Like the quantizaion value in Ableon that quantizes all of your trigger/stop/record action acoording to quantizazion value.
I also tried chaning the quantization with the wrappers but it didnt really work, mainly because of the problem described above.
P.S. Right know the table is split into 4 equal parts right? since we are limited on ram thus on recording time I think it would be great if the loop_multi could somehow dynamically split the slots according to the space actuallally used. So if you start with a short loop, only use that part of the table actually and adjust the offset according to how much space is still left.
klaro!!but personally,I don't work that way..actually,one thing I really dislike about ableton is having to wait until 1.1.1.
I do stuff like this: https://gumroad.com/rbrt to break the 1.1.1. system
(PM me for a free copy..)
so what loop_multi does is to start ANYWHERE in the current bar AND THEN record for x-bars.if you stop recording 'within' the current bar (or PHASE) ,you get a 1-bar loop and so on
anyway,I'll sketch up something 1.1.1. ish and add it to the help file..should't be too hard,just some sort of mechanism with 'loop_sync' hooked up to the 'master-phasor'.
yeah would be great,but I think it's very very hard to get there..conceptually and in terms of coding..
another possiblility I can imagine to be more realistic is to create an object that writes the recorded loops to SD-card in the background,and once done,plays them from SD-card...
I've posted a request for this here
