Rbrt Contributions

[SmashedTransistors]

If you need some multisegment mappings (2, 4, 8 or 16 for unipolar or bipolar inputs/outputs),
i have made a series of objects in tiar/kfunc,

[rbrt]

the help-patch for 'ldub' should be working now..

[Djeremaille]

Hi!

Excuse me but is the Slot input mean that you can use multiple loops. If yes, how to use it?

[rbrt]

...basically,it just defines which area of the table you record into,or a recording offset.
for example,if you set the attribute 'slots' to '8' , the table is divided into 8 slots.
then,you can select via inlet 'slot' which area of the table you want to record to.

technically,you could also use 8 instances of 'lrec' with 'slots' set to '1' and record into 8 different tables,
but using 'slots' greatly simplifies patching and it's a lot more efficient.

[rbrt]

keyb zone poly

an approach to handle polyphonic midi at patcher-level.
provides information about held notes and writes a 'map' of these notes
to a table with the same name as the object.

a pulse at the left inlet clears the table and resets note-count.

[rbrt]

Sample Bank Recorder (sb rec)

so here's another sampling-thingy,

...you can record a bunch of samles quickly after each other to a table,slicy slicy style..
the start/endpoints are accessable from 'outside' by referencing the object's name..
you can record up to 128 samples in 'slots' (as many as there are midi-notes...)
when a 'slot' already contains sample data, it's locked for recording.
furthermore,you can also delete 'slots' and 'clean up' the resulting empty areas in memory by defragmenting the table!

'sb params' translates start/end to 'in fraction of a table' - values to be used with my 'ldrive' - objects.
there's a help-file to explain all the details.

it's inspired by a great idea of @Ott

Recording to SDRAM with a trigger

Hi all, I have a patch idea where I record the audio input to SDRAM, but only when a key is held down. If you press a new key, recording resumes. If you press an old key, the portion of audio that was recorded for that key is played back. The problem is, none of the delay objects have any trigger inputs. Is there some community object that will let me do this?

it may or may not be tied to this cool thingy by @SirSickSik:

SirSickSik Contributions

NEW MODULES LOGIC "rndLGC" 4 inputs, 16-multi-logic stages and 4 outputs that can select any of them and a randomisation trigger and chance. Turn any 4 gate-patterns into something completely different. (eg. the track of the audio-link in the former message is made by 4 unchanged gate-patterns that are mangled by 2 slowely randomised rndLGC modules.) SAMPLER "liveRecord" and "livePlayer" These modules are set up in the same way as the sampler (using a table for the samples and a table f…

maybe,in some time,I will try to implement saving and loading selected slots to SD-card..

[SirSickSik]

"Hi all, I have a patch idea where I record the audio input to SDRAM, but only when a key is held down. If you press a new key, recording resumes. If you press an old key, the portion of audio that was recorded for that key is played back. The problem is, none of the delay objects have any trigger inputs. Is there some community object that will let me do this?"

this should be doable... though remind that you are limited to the buffer in the time that you can record. So, for example, what should happen when you go over the available amount of buffer?

But this gives me an idea... a recorder that can either record to a selected midi-note (any value between 0 and 127) and a mode that would play a selected buffer, pitch-shifted by the midi note. Though, then again, this will be bound to be very short hi-res recordings if you want 128 samples.. or do it in 8 bit and have a low quality, but long recording time...

[rbrt]

his should be doable... what should happen when you go over the available amount of buffer?

erm...this is exactly what I did . Once you reach the end of the table, recording simply gets stuck there..
it's just a recorder, after recording is done, it writes the start/endpoints of what was recorded while the 'arm' - inlet was '1'.a 'session' can have several 'takes'.
CHECK THE HELP-PATCH!
I'm using a 32-bit-array internally,where each recording has 4 parameters:startpoint in samples,endpoint in samples,unused,and 'active'.you can acces these in a patch with whatever player by referencing object's name..

and a mode that would play a selected buffer, pitch-shifted by the midi note.

so,this would be subject to a playback-object.

(OOPS it just occured to me that 'active' may be unnecessary.it's only used for defragmentation and I found a different approach while coding..I will double-check..)

[SirSickSik]

Do you really need the "endpoint"? Isn't the endpoint the same minus one as the starting point of the next sample? Saves you 1 32bit value for each sample. As for the active/inactive values, perhaps you can put them all together in a single 32bit value for 32 samples?-> Each bit sets the state of another sample. For 64 samples, you'ld only need 2 32bit values..
You could save all these values in a single 32bit array, taking the first couple of slots for amount of recorded samples and active/inactive samples, and use the rest for the starting point of the samples (end point is always startpoint of next samples minus one).

[rbrt]

Do you really need the "endpoint"?

yep.the indexes are stored for each of the 128 possible 'slots'.when you start recording to slot 64 and then to slot 16,the startpoint of slot 16 is not the endpoint of slot 15...

As for the active/inactive values, perhaps you can put them all together in a single 32bit value for 32 samples?-> Each bit sets the state of another sample

yeah,it's possible,but it's easy to get confusing for others who want to write objects that use the sample start/end info created by 'sb rec'

what I think makes sense is to get rid of the 'active'-info by using 'endpoint' as a boolean instead:if 'endpoint' is true,this automatically means the 'slot' is active.
so,this would compact the size of the array used internally to 256 32-bit-values

I'm going to check...

[SirSickSik]

"yep.the indexes are stored for each of the 128 possible 'slots'.when you start recording to slot 64 and then to slot 16,the startpoint of slot 16 is not the endpoint of slot 15..."

From this I understand that you record the audio-samples one after the other in the same table and save the sample-slot next to it in it's own table to be able to tell which sample belongs to which index of sample-slot. Then you should be able to use that table to see what the starting position is of the next sample in line, no matter what slot in belongs to..right?

[rbrt]

sort of but...
hey I've been working for it quite some time,especially on the defragmentation-part...and i'm still a bit surprised it's actually working.
I really like to just bam! record a lot of samples and decide later on to delete some of them,but this will result in unused chunks in the table and thus,you'll loose recording time.
so,defragmentation is built in.
it gets quite fuzzy there, and maybe I really dont't have 'the big picture' anymore.
anyway, I always ended up with the need for at least an endpoint,without,the code would just get too complex.
also,people probably won't use a lot of recorders in one patch,rather a lot of players.so I decided to try to keep it simple,even if it gets a bit uneffiecient in terms of ram-usage.

but you are invited to dig in the code,I will put some comments inside for the next version,
which definitely won't have the 'active' - flag anymore (so,just start/endpoint)

[jaffasplaffa]

Hey @rbrt

Have been using your object "rbrt/launchpad/launchpad" in to communicate
between Axoloti and Launchpad. Very nice object

It works very well when using it as the only midi device connected to Axoloti via USB Host port.

But I noticed yesterday I tried to connect a second midi device, a Launch Controller(via computer) to Axoloti, that there might be some midi crosstalk going on in the object.

It seems like the top row buttons, midi cc 104-112, are affected by any other incoming midi CC values that is fed to axoloti. For example if I set the top row to nr 5, and then touch one of the knobs on my Launch controller, the top row is affected and jumps to value 0.

And it doesnt matter which midi channel i send midi cc's from midi channel 1, 2, 3 they all seem to affect the top row.

Would you have a suggestion for a workaround this?

Thanks for some great objects, btw

[rbrt]

...ah uh nasty.

actually, I never tried the object in a midi-setup that incorporates more than a single launchpad..
and the code regading midi in is taken from someone else's object,
so it's quite possible that this is a bug.

I'll have a look as soon as I get my hands back on the axo!

cheers,Robert

[jaffasplaffa]

Hey @rbrt

Thanks, I actually think I figured out what the problem is. It happens cause, the top out shows the midi cc number that is last dialed in.... So If I dial a knob on my Launch controller, the rbrt/launchpad/launchpad in "catches" the midi cc number from the dial from Launch Controller ad changes the output of the "top" row. Not really sure how to fix it though. I am thinking about maybe adding some kind of minimum/maximum value so it cant go out of range. But it would probably be more of a work around than a fix.

I have previously had succes with passing data through a table first, before sending it to its destination. Think I'll try that too for this setup.

[srodillof]

hey!
would you mind sharing your patch?
I'm planning on making a very similar machine to the one you have described.
4 track loop station, made out of 2 axoloti boards with midi clock sync.

also BIG thank you to you, @rbrt and @Blindsmyth . this whole thread has taught me a LOT about axoloti and loopers.

also, I have a small question:
I'm interested in the "1.1.1." style looper that was discussed previously.
how did you manage to solve this?
I got a bit lost in the technical vocabulary, so it would be great if any of you could help me with this one.

again, THANKS A LOT to all of you and everybody else who has contributed!!!

[valmir]

hi there!
I think that sharing my patch at this point would be fairly useless, because there a lot going on unrelated to loop but mixed in the patching(highly human unreadable), I used the old @rbrt loopers and it relies specifically on the hardware I use to control it... and the final version by the way has syncing only per board...
If you want I can offer the little knowledge I retained after doing it and help you a little if I can.
Upper in the thread I posted a trivial looper that can sync to a clock.
I remember it was very easy to make a midi clock from the range output of lrec.
You should definitely implement yourself a way that fits your needs to sync the start/stop between boards.

[srodillof]

you reckon it's possible to set the clock with the length of the first loop (fist 2 taps), and sync every other loop module across the 2 boards to that clock? I was thinking on doing this by connecting via both MIDI IN and MIDI OUT on the 2 boards, so that any of the 4 modules can be the "master loop"

also, does your looper sync the recording and playback of a new loop with the first bar of the master loop?

I have read a lot about patches and everything else in the site, but I still haven't tried anything because the 2 boards I ordered have been delayed. I'm also working on a deadline (university project) so I'm gathering as much info as possible before actually doing anything.

From what you guys have discussed here, I'm pretty sure all of this is possible, but I'd just like to confirm since my interpretations of the technical terminology might be wrong.

thanks for the reply!

[valmir]

you reckon it's possible to set the clock with the length of the first loop (fist 2 taps), and sync every other loop module across the 2 boards to that clock?

Yes indeed. That's what I did for a while but my needs were different. My opinion is that this approach works best if you preset the loops relative lengths, like track1 is 4 bars, t2 is 8, and so on... and of course you always play 4/4, otherwise you'll have to set different math for different time signature. (that's why I changed to a different system, which won't be syncable between boards unless SPlink gets finally developed...)

I was thinking on doing this by connecting via both MIDI IN and MIDI OUT on the 2 boards, so that any of the 4 modules can be the "master loop"

(mind that I always used @rbrt old loopers, never the new ones which may be different and, probably, better)
I actually wasn't able to do that, but maybe it was me... I had a track that was always the master. When you record a loop the object lrec spits out the number of samples the loop is long. Divide that integer number for the number of bars, multiply it by 24, feed it to s2f (sample to frequency) and use the output as the frequency of a square wave oscillator. Et voilà your clock. Use something like the patch i posted somewhere up in the thread as a slave track.

also, does your looper sync the recording and playback of a new loop with the first bar of the master loop?

Yes! My method use position sync and @rbrt loop_sync, but it will also work with clock sync ( I don't have the patcher installed on the pc I'm using right now, that's why I'm typing so much instead of uploading a patch...)

From what you guys have discussed here, I'm pretty sure all of this is possible, but I'd just like to confirm since my interpretations of the technical terminology might be wrong.

I'm pretty sure you'll be alright... for me the hardest part (which I suggest you think thoroughly before starting) is the logic underneath how you want it to work I.E: you're allowed to record only one track at the time or not? If so, if you are recording loop1 and press record for loop2, what do you want to happen? (like, 1 starts looping and 2 starts recording, loop1 is recorded but stops... all this kind of options... this took me some time to be refined to my needs, but I actually make a living as a livelooping musician, so I'm quite picky about it )

[srodillof]

I have most of the functions planned but I had not thought about starting REC while another loop is already recording! I'll go through every possible escenario and figure those details out.

thanks for the clear explanations!

on a side note, could you share a video of one of your performances (if you have any)? I'd like to see your show and how an axoloti-based looper behaves in a live setting.

cheers!