Rbrt Contributions

[Blindsmyth]

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'.

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.

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

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.

[rbrt]

P.S. I just fixed the chained recording When I have everything done I will share my patch here.

yes please!!
and pictures of the hardware!

[Blindsmyth]

yes please!!
and pictures of the hardware!

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.

loop multi 4.axh (52.7 KB)

[Blindsmyth]

Hey there,

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.

[rbrt]

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.

[Blindsmyth]

Hi robert,

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.

This is a test patch for loop_slave. The rec status almost instantly freezes.
loop multi 5.5.axh (93.6 KB)
loop_slave test.axp (2.2 KB)

P.S. I tried with an internal test signal too, so the clicks dont come from external input.

[lokki]

are your trigger inputs properly debounced? just a shot in the dark really.

[Blindsmyth]

are your trigger inputs properly debounced? just a shot in the dark really.

what do you mean by that?

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.

[lokki]

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...

[Blindsmyth]

ah ok. I tested with only internal components and still have the same problems.

[rbrt]

loop_mangle

something like 'play pitch loop' to mangle audio in tables.
check out the objects help file.

[studiokpg]

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

[rbrt]

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..

[studiokpg]

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

[Blindsmyth]

If you want to try something yourself the first thing would be to interfere with the quantization phasor in Rbrts patch. If you sync that one to clock the lenght of your recordings will relate to midi clock. You could maybe replace it with a counter, since only the moment when the phasor is at 0 is important, right @rbrt?

But still if your clock drifts or you change the tempo, the timing will get fucked up.

The next step could be to multiply the frequency inlet of the playback phasors with the ratio of the current tempo in relation to the tempo during recording of the loop. That way your loops will pitch down (and slow down) or up when you change the tempo. That ratio part is not so easy in axoloti, since you have to divide the current tempo through tempo during recording and dividing float values in axoloti is not that easy.

Last part could be a mechanism that retriggers the loops. You could have them either automatically retriggering after each cycle, or make it optional like on the Kaosspad. I think the kaosspad only quantizes recording length, at a certain moment loops start to drift. Then you can press resync to put them back in phase.

I made several efforts in all of these directions, unfortunately it is somewhat spread among several patches, but I can try to get it together for you.

[studiokpg]

Thanks, that gives me some more ideas to work with. I'm really digging rbrt's loop toolkit! The ultimate looper is within reach!

[rbrt]

some thing else before I return to them BLOCKS

tinit

...sets or inits the indexes of a table to the values defined by the sliders/dials on rising edge of 'trig'.
useful for example to initialize parameter banks when using 'tablestore'

[rbrt]

here's LOOPER BLOCKS V2

these are driven by sample-increment rather then frequency;
before,changing the loop's range was also changing it's pitch which was really annoying....
performance-wise they are about the same as the 'old' objects.

I added a 'play' - input and a 'speed' - parameter to simplifiy patching
(although the objects are quite big now)
it's also possible to create 'release-loops' now with 'ldrive multi' and 'lmangle',
and 'lmangle' can do palindromic (switching from ffwd to rev at loopends) playback as of now.

there's a '1-shot' - object playing back an area of a table once and then stopping.

there are already 2 help-patches,more to come...
aaah and 'ldub' now has a 'feedback' - parameter!!

I do think these make more sense than the 'old' blocks,but in order not to break patches,
I will keep them.thus,the new folder 'loopv2'.

[Blindsmyth]

aaah and 'ldub' now has a 'feedback' - parameter!!

Yes yes yes yes you are my hero
the rest looks really good too

[rbrt]

step seq BLOCKS

here are some modules for building step-seq's.
my main focus was to simplify visual feedback for controllers that feature bi-directional MIDI,
like the LIVID BASE or the NOVATION LAUNCHPAD.the help-patch should work with the
factory-mapping of the BASE.
I had a hard time recently to acieve this with 'regular patching',so I did an object for this,'seq midi feedback'
would be good to know if it works with the launchpad...

besides,there are some other custom objects that I feel make sense for step-sequencing.
-step toggle : will toggle an element at an index (or step).if the step == 0,it will be set to a defined value,if its non-zero,it will be set to 0.
-step set : will set a step to a value.optional,the step will ONLY be set to the value if it's already non-zero (useful to change velocities without creating new steps)
-read step : reads at an index and outputs the value.
outlet 'trig' puts out a pulse if the value is non-zero,outlet 'vhold' will hold the current value until the next pulse.