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
Allright now I get it I'm kind of used to this system so that's why your approach was kind of confusing. but I want to to have some flexibilty in the future on what or where the 1.1.1. actually is. Or like have the possibility to change what the master loop is etc but I think with this modular approach that should be possible.
The second Idea would be terrific. Let's see what the future brings
I have my looper hardware now finished, (4 switches stompbox format with leds for looper state etc).
So if I can get basic 4 channel looper finished that roughly does what I want I'm quite glad already
P.S. I just fixed the chained recording When I have everything done I will share my patch here.
I have some aweseome footage from the coast of albania with the hardware and an older version of the looper that I will post here soon
I started working further on the chained recording concept and started to integrate a multimode button interface I built earlier.
I'm facing some problems with clicks doing chained recording and I thought you might have an idea how to get rid of them. My first Idea was of course envelopes. So I patched and ahd envelope using the rec out as trigger. The first loop is always perfectly clickless but the second on I do using the slot switching has really harsh clicks.
Problem with the envelope is that the moment when recording stops after the first loop is to short to let the envelope go back to zero.
Any Ideas on that? I tried to clean up the patch as much as possible.
I could get rid of the clicks with slot switching. It seemed to have to do something with the transistion from going to record into overdub. So I smoothed out the input of the overdub module in order to solve it.
I still have some issues however that seem to lie in the nature of your objects and thereby not fixable with patching, it mainly concerns overdubbing functionality:
when using either you looper_dub or the looper_slave module for overdubbing clicks are introduced into the loop. I think this is not a problem related to overloading the table. It also occurs if you only record one layer and then let overdub on. Already after 2-3 repeats the clicks a clearly audible. These clicks are not neccessarily at the loope boundaries but all over the loope. Since no more material than the first loop was added I think its not related to overloading the table. I also deliberately overloaded a table, this sounds completely different than the clicks I'm hearing.
the rec/dub input of looper_dub and looper_slave behave some what unreliable. When turning on and off there is a big irregular latency (I watched it with the b output of Looper_slave, or listened when using dub) I also had situations where looperslave wouldn't react to changes of at the rec in at all. Considering that leaving Overdub on will destroy your loops this is really annoying.
The clicks I had in the post above seemed to be introduced by switching from recording into overdubbing. I'm asking myself if you really need two modules for this. Couldn't overdubbing be integrated into the loop_multi module? I mean usualy it is always either overdubbing or recording and on only one of the slots.
Hi Simon, -'loop multi 4 axh' doesn't load correctly on my machine,it's missing all the subpatchers (a known issue).could you send it to ´me with embedded subpatchers? -'loop_slave' and 'loop_dub' are working as supposed in the object's help-patches, so I can't really tell what is introducing the clicks/latencies.
here is a newer version with embedded subpatches and 4 loop slots. It is a bit big since I want to wait with organising it into subpatches untill everything works, since all the parts are interconnected.
I did a test with the odub help patch, I did have no clicks. But in my patch it clicks a lot.
P.S. just tested the _dub object bit more, works reliably no clicks or latencies. BUT I can't use this one because it lacks overdub feedback. So my way to go is loop_slave wich causes me some trouble. Maybe because it's not intended to be used this way.
i did not look at your patch, but are you using external buttons to trigger the looper (connected to the axoloti) if they are not debounced (either in soft or hardware) you could get multiple triggers on pressing a button down...
Hey, I'm loving your loopstation! If I could make one request, I would ask that you could make it possible to sync to a clock. It would be nice to be able have the record start and stop points, as well as the loop phasor reset always line up with the clock, so that it could sync with external devices - midi daw, other sequencers, etc. I've been trying to see if I could tweek your patch to make it work, but so far haven't been successful. Thanks! Karl
Hi Karl, I'm quite busy right now,but I'll try to figure it out soon.. I think it's going to work,but I see some problems regarding jitter of the external clock...this is likely to introduce clicks in the loops..
Thank you! No rush, just maybe on your next pass. As far as jittering, maybe you could put in a ... (I forget what its called!) A thing that won't let it update if it has already updated in the last n milliseconds or something. Thanks for all your good work! Karl