Prevent auto assign new pattern sequence number, when patterns are moved / copied / deleted

I currently testing to reuse pattern sequence numbers and pattern muting as fast simple song structuring workflow. How can i prevent that Renoise is assigning a sequence a new number, when i’m moving / deleting or copying patterns?

rns321_pmatrix

I’ve checked the preferences, maybe i’ve missed the option?

1 Like

Maybe disabling this:
image

1 Like

Ok I’ll try this when I’m back home. Thank you.

1 Like

Mhn, doesn’t work for me. :confused:

I think this is not working properly. I guess @taktik should check it out. You should inform him.

At the moment, use the matrix, and copy and paste the slots, instead of dragging down with the mouse to copy. In this way you will not lose the order in the sequence, in this particular case.

Sorry I can not help you anymore. It seems an internal error of Renoise’s behavior, probably a programming neglect or an unforeseen situation.

Yep you’re right. But i’m not sure if this is still intended. I’ll create a bug report.

This is intended. Renoise is doing what the gesture implies: it’s moving that section of the pattern below - without (magically) changing other patterns. This applies to everything you do in the pattern matrix (e.g. clearing, pasting slots).

There could in theory be an option to disable this, but there currently is none.

I think the issue here is that the pattern that is being copied from becomes the new pattern 3, but it should stay as 1 because nothing within it has changed.

@taktik Ok, maybe something for the feature wish list :slight_smile:

@Achenar yeah you’re right. This seems to be a bug. Nothing was changed in pattern 1, which become pattern 3.

As I see it, pattern 2 should also not change to pattern 4. It should continue at 2.

I have always understood that cloning down when dragging should be guided over the sequence index, not the pattern index. That is, it insert the information about the pattern that is deposited in the destination sequence. In no case should the pattern index change. As it is now, it can “drive the user crazy” using disordered patterns.

I don’t usually use disordered patterns. But this would be another reason not to use them.

As I see it, pattern 2 should also not change to pattern 4. It should continue at 2.

The pattern being copied into has been made unique through this process, so it should become the new pattern 3.

Yes, it seems. I imagine a more extreme case, with multiple messy patterns using drag cloning. Many indexes could change. The user should be very attentive.