Rbrt Contributions

rbrt 2017-03-26 16:37:41 UTC #190

-about 'ktransport' and 'stransport':
...code looks good to me,
the value at the inlet 'factor' is ADDED to the object's parameter 'factor'...
the parameter is set to a minimum of 1 (it has to,everything else would cause problems)
so,if the value at inlet 'factor' is set to 1,the ACTUAL factor is 2.
maybe that was the problem on your side...
anyway,I added a helpfile and just synced.

about 'fade' for ldub:shouldn't be much of a problem to add this.
I'll add this to my agenda for the next issue of the looper-objects,
there will be quite a few fixes and also performance-improvements...

valmir 2017-03-27 07:39:15 UTC #191

Looking forward to the updates!
And BTW, there is one little behavior of the /ldrive object that drives me crazy... the count outlet is 0 when there's no loop or one is being recorded, and then starts to count from 0 when the loop is running...I've tried some approaches to sync multiple devices with a simple /change object linked to the /ldrive counter, but as for now it only works starting from the second count...would it be possible/easy to change that? Like 0 as a default state and then counting from 1... Thanks

rbrt 2017-03-27 12:29:13 UTC #192

ah,I see!
no problem,it will now be -1 when the loop is not playing,
so 'change' will work

Blindsmyth 2017-03-27 15:13:31 UTC #193

ok that was confusing. I thought that the external factor would be multiplied with the internal. wouldnt that be more logical?

so the best thing would be to set to one and feed it the factor I want -1?

nice, thx a lot!

rbrt 2017-03-27 15:36:18 UTC #194

precisely!...but I'll think about multiplikation,maybe it makes more sense...

rbrt 2017-03-27 21:26:40 UTC #195

...hmm still thinking,
I do agree multiplying inlet 'factor' and parameter 'factor' makes sense in this special case,
even if most other objects simply add inlets and parameters...
hmmm...what to do when inlet 'factor' is zero?
maybe ignore zero?
that could work..

Blindsmyth 2017-03-28 11:42:12 UTC #196

Multiplaction would eliminate the need for external patching.

No need for a -1 and you could still use the internal factor to trim the factor up or down to a practical value instead of doing this with objects before the inlet.

May you can tell it to use the internal factor when external inlet = 0.

Blindsmyth 2017-03-28 16:26:06 UTC #197

Hey @rbrt and @valmir I've got a new aproach for midi clock syncing:

I used rbrts sync mechanisms but replaced the phasor with a counter that is being scaled to a range of 0-64:

Loop start is quantized to the next 24ppq loop stop according to rbrt's quantization mechanism.

I don't have all the extra stuff of @valmir's example, still didn't really get most of it, but it seems to work and doesn't produce a lot of clicks as of now.

Maybe I will also change to alway having a clock in my system. Could come handy for stuff like sequencing retrigger of a loop, or mlr like retriggering.

This is the patch:
O Clock Sync New.axp (13.2 KB)

mwvm 2017-03-28 18:17:34 UTC #198

i'm looking forward to trying this!!!

mwvm 2017-03-28 19:56:41 UTC #199

A couple of things.

This works great Thanks!!

Has anyone ever sorted a clear loop?

Also, if overdub is engaged pre recording you get a nasty distortion ...this is something i've noticed in other patches

mwvm 2017-03-29 05:31:54 UTC #200

There is a couple of other things actually.

Stop/play are fairly important with looping.

Simply a case of toggling between constant values of 0 - 64 with the speed control?

valmir 2017-03-29 06:48:17 UTC #201

Nice! I don't have the /Runtergeladen/dynamic counter, but replacing with /phi/logic/counter i seems to work.
!'ll try it a little more later...

Blindsmyth 2017-03-29 10:13:08 UTC #202

In my bigger looper patches I have multibutton interface:
1. press rec
2. stop rec, start playback in overdub mode
then toggle between playback and overdub

the whole thing works with a counter, that you can reset and thus clear the loop. I shared an older version of this a bit more up here.

Oh yeah that one seems to be from the pre community library days. the one from phi does the same I think!

mwvm 2017-03-29 11:25:52 UTC #203

Would you share this patch?

I think I'll toggle the midi with a tap tempo.

I used a korg sq1 as a master clock to sync the looper and eurorack. Very exciting potential

valmir 2017-04-26 13:10:20 UTC #204

Hi @rbrt ! I have a little problem with your /div iif object.
Basically I want to extend the loopstation I made across two boards (still testing general ideas because the second is yet to arrive); for the approach I'm trying I'd need to have a float representing the range of the master loop on both boards so that I could sync all the slaves with the criteria I want without being bound to a clock or record a fake master on board two, and I found this way.
multiboardsync.axp (7.2 KB)
When you record the master loop on board one, timeri and a little math (div iif) will do the trick on board two to get me my range. And it works! But on hex display the last couple of digits differs on longer loops... why? I think is a very small difference, not even shown in the dial, but may be enough to make loops drift...

rbrt 2017-04-28 09:37:01 UTC #205

Hi @valmir ,

...I haven't looked at your patch yet,but very basically,all we have for calculations are
integer,32-bit numbers.
so , when doing a division of for example 7 by 3 , we are not going to get 2.3333 ,
but plain integer 2 as result...
'blue float' is not actual float,but just a concept to use our 32- bit headroom to display numbers
as 'fractions of a phase'.
the result is the 'range' will most of the time NOT be sample-accurate if you try to get there by division.
(besides, or more important,a 'sample' is a defined integer adress inside a table...)

one solution could be to measure the actual drift of the 'master' and the 'slave' - loops,
and modulate the speed of the 'slave' slightly until the loops are in sync again...

valmir 2017-04-28 12:05:09 UTC #206

Thanks for the quick reply!

So how do you get blue float range values in your lrec object?
I naively thought that you divide the table length for the recorded samples, and if there is approximation or rounding because of the 32bit resolution that would be the same also if you do it with div iif...
Because my goal would be to do exactly the same but without the lrec itself, or better, without the need for a table. That's because my plan is to have the same reference(master) range on multiple boards, but only one of them will actually record the master loop.

rbrt 2017-04-29 11:56:10 UTC #207

...recording is toggled at k-rate,which is sampling-rate divided by 16...
so the length of a recording is always some multiple of 16 samples..
to 'transform' the length of the recording in samples to 'blue float',
the object applies some bit-shifting.

however,when you record a loop in 'sync-mode',especially with a quantization
that's different than the 'master-loop' , there will be some difference in the relative lengths,
resulting in 'drifting'.
but not too much,actually,a sample here,a sample there
sometimes,it's even accurate.
check out the 'smps' - outlet...

valmir 2017-04-29 12:42:14 UTC #208

So, I guess also your stimer object works the same way? I always get the same results from it and form the smps out of lrec but then the calculated and the real (out of lrec) ranges differ of a very small amount. (see the uploaded patch)
Sorry I feel a little dense but I still don't get it...

That's the part that interest me, I'd like to patch the same calculations outside lrec

I don't think thats the case here, at this point there's no real sync, I'm just trying to have the most accurate copy of the master's range... hope that makes sense and thank you for your time!