What is Assign to Self used for?

I don’t understand the purpose of assigning a file to the recording buffer, because all that seems to do is make you unable to access the recording buffer. Could someone please explain?

1 Like

I was thinking about this the other day, agree that it’s useless when you’re saving something from buffer. Maybe for people saving a copy of a pre-existing file?

You still can access the buffer and replace the assigned to self recording.

It let you start a pattern with a previous recording that you can replace, or not.

It let you try and record different versions.

You can assign another existing sample too. (Left arrow).

5 Likes

Thanks @sezare56

I realized too that it’s a super quick way to work, because you don’t have to worry about scrolling around, and if you’re going use that slot again, you’re probably going to be using it in a different part anyway.

And you say you can replace? Does it change the saved file automatically?

Edit: Actually, no, it doesn’t work the way I thought it would. I thought that file setting whatever would get saved with the part, but it doesn’t.

Wait a minute… I just thought of a feature that I’ve always wanted, and I think this is it! It lets you name the recording so that when you go to save it, it prepopulates the name dialog with the name of the recording. That IS an awesome timesaver! I didn’t realize that’s how it’s done. Thanks sezare56! You totally helped me figure that out, it just took me a bit :blush:

1 Like

On a semi related note, not speaking of assign to self nessecarily but rather just loading things to recorder buffers in general, recorder buffer slots also act as flex slots. One thing you can do is load a loop to a pickup machine or any sample and then be able to overdub to it, another is if you have a recorder buffer all sliced up to flex and want to see how it sounds with a different pre existing sample. I haven’t thought too much about it but I’m sure there’s other uses.
If you go to the attributes section of the audio editor and “clear slot”, it will be cleared and labeled recording# again…

6 Likes

I was just trying to figure this out the other day, because of course if you just go with the recording buffer, and want it sliced, you have to re-slice it every time you switch the OT on. I need to try this out, but if anybody wants to give me a heads up on how to do it, that would be really great!

It doesn’t work with 1.25H os. You can downgrade to 1.25E.

Another possible answer for the OP: You can overdub it with a pickup machine

2 Likes

@Open_Mike mentioned it too above.
You can overdub with flex too. :wink:

1 Like

Yeah, looks like I will have to downgrade, this is not the only regression 1.25H has brought it seems.
But by saving and assigning the sample to self it seems to work just fine, at least in my quick test.

I guess it was a lucky strike… didn’t work again after that. So I guess 1.25E it is then!

1 Like

If you don’t need unequal slice length and are ok with equal slice divisions, start point locks work great for recorder buffers and have the advantage that they behave well with bpm change…

yeah that’s true. I guess I just find it easier to be able to set up a slice grid instead of having to do the math, plus I don’t really need this to work well with BPM changes, though. Also just working with start point locks will not work that well with randomizing stuff. Why would this be limited to equal slice divisions btw?

Start points = 128 slices so why it wouldn’t work with random stuff ?
I’m ok with equal divisions and in Slice mode there’s Lenth = Slice/time.
I’m not sure if default slice number is 1 or 64…

Start points divide any length sample into 128 divisions, I guess they don’t all have to be the same length if you program them accordingly, but the basic divisions are equal, and your length is based on multiples of those divisions, unlike slices where you can zoom in and define all of them to very specific different lengths.

For equivalent of 64 slice grid, each slice is 2 start points long starting with 0:
start point 0 is slice1, start point 2 is slice2, start point 4 is slice3, start point 6 is slice4, etc…

I set most of mine up a long time ago and haven’t looked at them since… I get different results by playing different things into them…

1 Like

With 64 slices, you have to think about that with midi CCs. The values are the same as start points.

1 Like

I think for 64 slice it’s:

(Slice# X 2)-2 = start point.

1 Like

Because if you have low number of slices (let’s say 8 or 16) then using a random LFO to play from specific points in a random order is very difficult, since it’s impossible to predict from where exactly it will play. With slices you can accurately set the start points and then the LFO can jump around between them.

Since I have rather short loops I will never have 128 slices, usually it’s 16 or 8. Keeps things easier to follow. So there is some wiggle room for non-equal divisions, but you need to do some math.

With an lfo designer modulated by a rdm lfo you can randomize start points accurately, even if there are 8/16 slices. :wink:

Slices are more confortable of course. 1.25E.

1 Like

I saw someone post once that Assign to self will load the saved recording into the buffer after you power cycle, I tested and yes it does… :slight_smile:

1 Like