Rbrt Contributions

#164

Order of execution has changed in your patch. Check this out, should work
simpleloopermidiclkslave repitch.axp (17.0 KB)
latch_1 and counter_2 must be in that awkward position for it to work.
Using ldrive has nothing to do with it, but has another drawback: it will loop when reaches the end of range, even if that occurs before the resync. Try recording 1,2,3,4 and set the loop point to 5, you'll have 1,2,3,4,1 looped. I'm not very good at explaining, hope I made myself understandable... :slight_smile:

Agreed, that's why in my live axolooping setup (first gig with it tomorrow!) I decided to sync tracks only with relation between ranges, an then generate a midi clock from the master loop length for external devices...

@rbrt : you are the man, and integer divided by integer to get a float is THE THING!!!!!!!!

#165


i loaded both versions and counter is set to max ....why?

#166

That's because it's not used as a cyclic counter; it will feed the number of 24ppq cycles occurred during the recording to the latch and reset. I didn't find a linear counter, is there any? I was lazy, but I think I could have done it with a latch, a +1 and some logic...

#167

yessss it does...
since as of now I can actually divide with axo,I re-worked 'lrec multi' and 'ldrive multi'.
I put them inside a new folder called 'testing' in the library.

basically,'ldrive multi' has a 'phase' outlet now,so every 'ldrive' could be the 'master-transport'.
no need for additional phasors anymore.'lrec' is just a bit more efficient,as well as 'lsync'.
there's a patch 'loop_multi_testing' with the new objects in there.
maybe you could give them a try?

#168

@rbrt

I quickly tried your testing patch. It works, but I was wondering how you would do stuff like multiplying or dividing the quantization phase.

@valmir
I got in to the habbit of ordering patches left right up down, since it's the most ram efficient way and helps me understand what's going on. I didn't realize you put the objects into this order on purpose.
The new patch you sent me works, thx :slight_smile:

I'm going to have gig with my setup soon and I jammed a couple times already with @logsol, looking forward to using it live :slight_smile: so good luck!

Great to share developments here guys!

#169

Blablabla.... @rbrt supplied us with another useful object -1shot- that solve also this...
simpleloopermidiclkslave repitch.axp (17.3 KB)
this idea start to be pretty solid, is it maybe time to get a second axo to slave to my other looping patch?
I love this little thing!

Looper project doesn't loop
#170

In my main patch I'm working on a quantization mechanism that can be freely set to 1/4, 1/2 1bar 2 bar etc. so that you can be really free with how long the loops should be.
I think I posted a version here. But it was worked around the quantization phasor and multiplying the the frequency input.

#171

Cool!
What I've done in mine is to have a master loop that is also the master clock for midi out, but the slave loop is synced directly to the master, from one fourth to any integer multiple of the master length, set on the fly depending on when you press the button, using range scaling and rounding... I would really love to avoid midi clock sync completely, but to do that across boards I guess I'll have to wait until @johannes implements a stable object to communicate digitally through gpios... well, my live setup became nearly 10x smaller thanks to axoloti, so I can already be satisfied! :smiley:

#172

2 more objects, stransport and ktransport
...take kticks ore samples as input and drive a phasor and a 16-step clock.
divide and multiply the tempo as you please!
'mode' selects whether to divide or multiply, 'factor' sets the multiplikation/division factor.

also,there's some new stuff in /testing

#173

looks great will test it later!

just from looking:
maybe an inlet for max value for the counter could be great

#174

Junge!

Thx to your objects I built a syncable and subdividable delay with tables.

Check this out:

Bildschirmfoto 2017-02-10 um 23.25.55.png2872x1370 459 KB
Table Delay 1_0_0.axp (10.9 KB)

Reason why I did this I want to have a delay and looper on one board and have the max looping time, leaving me no space more for the delay. so my idea was using part of the table for the delay. To be precise the first loop slot, leaving me still 3 tracks for looping. (wich is for the travel setup I'm working on still enough)
If you have any concerns about this let me know, theoretically it should work...

btw you can also to the drooney stuff you sent me but all synced to a clock.

P.S. Now I'm busy building user interfaces using your midi and seq objects. I find still a bit hard to do what I want to do with your blocks:
With my Launchcontrol I want to have different layers of button rows that I can shift with some other buttons.
Each row should either:
1. Have and off toggles or momentary behaviour
2. give me an integer, so notes 0-3 should give me i 0-3
I want to get this as efficient as possible since I'm limited on ram. The 1. is easy with your objects but I can't manage to get both.
My aproach is using tables for this, wich has the advantage that I can store default values. You have any Ideas how to do this with your objects?

right now I'm using step toggle and table sent note.

#175

...just updated 'stransport' and 'ktransport'...

..now with a selection of max counts and a 24-ppq-outlet
as 'steps' defaults to '8' , you might have to change this in already existing patches to '16'

#176

tcopy V2

...useful for copying data around in between tables.
v2:
it's now possible to copy data faster than audio-processing-rate (up to 16 x !)
this has a lot of potential regarding sample-mangling.
of course 16 x has quite an impact on CPU-usage...

'splat' == the contents of the destination table will not be overwritten,but added to.
'clear' == the contents of the destination table will be cleared (overrides 'splat')

#177

the lmangle mod pitch control is a bit iffy. the audio stops at 3 o'clock in a simple patch i made.

and i can't seem to get the inlet startpoint to work

#178

...going to check on that later...
'lmangle' deserves some tweaking anyway..

#179

i should expand... the pitch seems to work if you move the parameter continuously, but if you leave it static it goes off.

also, the startpoint does work... my bad.

really enjoying this object btw, lots of potential as a nice sampler

#180

..yeah the concept is nice ,but it doesn't work as it's supposed to...
thanks for pointing this out,e-hem...:grin:

something connected to 'speed' is really messed up,I'll fix it ASAP
and let you know...

#181

it would be nice to have an overdub with fade with a range out to feed to imangle. :slight_smile:

#182

waveshaping
just did some really quick and dirty lookup-table style waveshaping objects.

nothing fancy,basically just an adaption of existing objects.
I think they're fun anyway,check out the help-patches (especially for 'shaper 8 mod')
HEAVY aliasing,gritty sound.

#183

I'm beginning an effort to document all objects with help - patches.
here's the first, for 'rbrt/fx'.because there's not much there,yet :innocent:

fx help.PNG1086x570 41.4 KB