Hi, here's what i'm working with: I've got sixteen 64kb arrays functioning as loopers.

Now, recording to them is sometimes quite challenging, if there's a quick sound, I might "blink and miss it", and then have to ask for that sound to be played again, hoping I'll be quick enough to catch it (I basically use a metronome to record, i.e. when I click on "X" (tgl) - recording starts, and then when I click on "X" (tgl), if i'm lucky, the waveform I'm seeing in the array stays.

Now, fixing that would be pretty cool (I can provide a screenshot at the bottom of this post and am open to any suggestions) but I'm now looking at this idea of "record a large amount of audio, and set a copypoint and copy a 64kb chunk from the copypoint (startpoint, really) onwards to a 64kb array.

So, how would one go about doing that? I'm currently using this to copy between the sixteen loopers. So I click on one looper number, and then click on another looper number, and a copy from A to B is made:

that's pretty great and useful!

but now i'm looking to finally have this "long array", with maybe a slider underneath it to define what the startpoint of the copy is, and only copy the next 64kb chunks after the startpoint.

so is it [array sum (startpoint) (specific length, i.e. 64kb) (arrayname)] that i would then be using, with a slider defining the startpoint, and a hard [64000( to get "from there"?

so here's the [metro 2000] I use to sample - what I'd prefer to do is record one full 64kb chunk and then if the chunk is visible already, and I press [tgl] - the recording stops there. instead, the visible chunk might get overwritten, if i'm unlucky enough:

should i be using some sort of method of splitting the [tgl] into a [start( and a [stop( ? i'm not 100% sure. or could i somehow time the 64kb sampling so that if i press stop, and the tabwrite~ gets to the end of the array, it stops when i untick the [tgl] ?

@esaruoho The chance that you will always catch the start point is not great.
I would suggest a pre-roll...... so press the toggle before the sound is played and then you will not miss it.
A long array for that, as you say, so that nothing is overwritten and the capture is reliable.
A bang to start and a [stop( message to end recording can be separate or controlled by a [toggle] but when separate you might not make mistakes.
Then the edit, which although a bit of work is probably preferable to losing a good take.

You can use a slider for finding the start point, and use [lop~] to "scrub" which should make that easier..... https://forum.pdpatchrepo.info/topic/11850/explanation-for-lop-object-in-this-patch-requested

I don't understand why you are using a [metro] for the recording...... a bang to [tabwrite~] starts writing sequentially to the [array]..... and maybe the [metro] causes the overwrite problem if you do not stop recording before the end of the [array]...?
David.

@whale-av said:

@esaruoho The chance that you will always catch the start point is not great.
I would suggest a pre-roll...... so press the toggle before the sound is played and then you will not miss it.

unfortunately this is simply not possible. i work with a friend and they play whatever at any point in time and it's up to me to pick up the pieces and get tons of happy accidents. but surely metro 2000 is not precise enough, maybe i should change it to metro 1000? or is it a case of by the time an array visually updates, it is already recording more to the array?

i found that with the 1mb array, it does not visually update until the whole array has been recorded, so you don't see "content appearing in the array during the record".

i'm not at all sure now how to take a specific segment of an array and copy it to another array, because it seems that [array sum startpoint + specificlength + arrayname] isn't what i'm looking for. or am i mistaken? i couldn't seem to find an example from the help. EDIT: well it helps to be using [array get] instead of getting confused with [array sum] documentation which is something else altogether

You can use a slider for finding the start point,

i'm not 100% how that would visually look like though, i mean, is it possible to visually show that "this is where the startpoint is at? should i have two arrays, with one being controlled by the slider, and one with the audio content?

my array is X size 600 and Y size 90 - so pretty huge and wide. i guess i should make a 0 to 1048580 slider and hope for the best?

and use [lop~] to "scrub" which should make that easier..... https://forum.pdpatchrepo.info/topic/11850/explanation-for-lop-object-in-this-patch-requested

thanks, i'll have to study this, since it seems very interesting.

since i'm working without audio plugged in, i'm not sure how glitchy this is, but this is looking pretty crazy!

and result of dragging the slider is (click on the animated gif since it doesn't seem to autoplay within this forum)

now, mind you, it's hardwired to plom1 of the 16 ploms, but if this actually reasonably plays (without clicks), this'd really help. but was i supposed to put in a [lop~ 10] between the get and the set?

ok, plugged in the audio, it is pretty choppy. do you think there's some way of making sure that the audio is less choppy when overwriting an array that's already playing?
i tried putting in [line 1 3000] before the f but that did not seem to have any effect.

then put one after the f but no effect again

ok, issue has been solved, there's a way to get rid of the jittering/stuttering clickiness by just doing

now my next step is how to solve the [array set plom5] to be controllable, i.e. i'd like for it to be so that i use a [hradio] (16 radio buttons) to define which looper i write to.

any ideas?

@esaruoho

Set the track number before setting the start point with the fader.
David.

@whale-av said:

@esaruoho

Set the track number before setting the start point with the fader.
David.

wow. just. wow.
i need to wrap this into an abstraction, and will. this solved everything. i can now record really long stuff (well 1mb feels long) that my mate is playing to me, and then isolate bits out of it to the loopers i want to isolate bits into. this is just pure perfection.

thank you so so much!

after some cleanup it looks really nice

@esaruoho "thank you so so much!"
You are welcome..... we all like to help, and are able to because so many others have helped us in the past.
Well done with your patch.... it is looking good..... and useful!
David.

@whale-av said:

@esaruoho "thank you so so much!"
You are welcome..... we all like to help, and are able to because so many others have helped us in the past.
Well done with your patch.... it is looking good..... and useful!
David.

i actually ended up starting a second thread about how to update the 1mb array while it is recorded to (i.e. some sort of "chunk display update" thing), and how to pause/resume recording, as these two things would be super-important for just safely recording more and more and more content. and just seeing what is being recorded, before audio recording is sent a [stop( .. or before the array content is filled to the full - which is also when the whole array is visually updated

but this "longer array to shorter arrays" has been pretty much something i've wanted for years, so it's amazing to get it working in less than a day with advice from here

@whale-av said:

Well done with your patch.... it is looking good..... and useful!

oh noes! i went and decided to implement loading + saving, but since the slider is hardwired to 1048580, and the array might change depending on length of sample loaded in, i'd now need to figure out a way to change the slider max to fit the array size.

oh noes, looks like the number doesn't come out properly, even in print.

Pd prints floating point numbers with 6 decimal digits only, but it may be accurate below that (or it might not be).

In this specific case, 1048580 in fact requires only 6 decimal digits of precision! 1.04858 * 10^6 happens to be exact. So the number did come out right.

1048580 by my calculation needs 21 bits. In 32 bit floating point, the mantissa has 24 bits of precision (23 encoded bits + 1 implicit bit). So 1048581 and 1048579 should also be precise internally, though they will not print the 1s digit.

hjh

ok so in the end i ended up looking at [array size( from the array docs , and [range $1 $2( from within the hslider documentation, and while this probably is very convoluted and could be simplified, the slider is now resized according to the array content:

feels like this looks less messy