Maximum number of patterns (1000) and all patterns full

R3.1 x64 Win10 x64

This had never happened to me, because I never experimented with up to 1000 patterns.

Steps:

1. Start Renoise a new song
2. Fill data in several tracks of the first pattern (write notes, and other parameters).
3. Duplicate or insert new full patterns (all written), up to 1000 patterns.
4. Then it removes many patterns, about 30 or 50 or more.
5. Try to insert new empty patterns.

What happens:

• A warning window appears: “Sequence operation was aborted. The operation would create more than 1000 patters, which is the maximum supported amount of patterns per song.”

This window appears even with 850 patterns.I have not tried to remove more patterns, but it does not seem logical. It’s supposed to be able to add up to 150 more patterns, up to 1000.

I’ve been creating a pattern cloning tool, but I’m experiencing strange things with this limit.This does not seem to happen if the patterns are empty.What is happening?Is there a problem if the patterns are full?

Also, for my tool I used “renoise.song().sequencer:clone_range(from_sequence_pos, to_sequence_pos)” and I can not place the limit of 1000 (<=1000) reaching 997 returns me an error.With empty patterns does not occur. The limit is just 1000.

no bug

bug

no bug

???

ups sorry thought its about the hardcoded 1000-limitation.

It’s not a bug -

This window appears even with 850 patterns

Unless you have asked Renoise to “keep sequence sorted” (rightclick in sequence), any pattern you create will remain, even as you remove/add/duplicate other patterns.
So you reach the maximum because there are actually a pattern at position 999. It could be a “leftover pattern” which got pushed upwards, as you were duplicating patterns over and over again. Try double-clicking on the pattern in the sequence editor and enter a number, or CTRL+Left/Right to scroll through them?

On the user side, the creation of such “leftovers” can be avoided by having the sequence sorted, of course (rightclick sequence → “keep sorted”). This does not actually remove them, but makes sure that they does not appear in the middle of otherwise unused space. Doh - sounds complicated. and I guess it is.

But since you are creating your own tool you might want this lua snippet, which does (well, should do) the exact same thing as the action in the menu:

local rns = renoise.song()
local indices,min,max = {}
for i = 1,#rns.sequencer.pattern_sequence do
  table.insert(indices,rns.sequencer.pattern_sequence[i])
end
for i = 1,#rns.patterns do
  if not table.find(indices,i) then
    print("clear this pattern:",i)
    local patt = rns.patterns[i]
    if patt and not patt.is_empty then
      patt:clear()
    end
  end
end
rns.sequencer:sort()

And yeah, in your tool you would need to be check whether sorting happens and test with both scenarios.

On the user side, this can all be avoided by having the sequence sorted, of course (rightclick sequence → “keep sorted”)…

Thanks Danoise!I will look closely at the code. But forget the tools for a moment.Try to fill the 1000 patterns with the correct order, using “keep sorted” (without using tools).The same thing is still happening.Eliminates 100 or 150 patterns (now you will have 900 or 850 full patterns). Then try adding other patterns. You can not do it.The warning window will appear.It is assumed that there are still 100 or 150 patterns to be able to add again.It’s as if Renoise did not release the patterns. But it does not seem like a logical operation.If a user deletes a pattern, he should be able to add a new pattern, up to 1000.

Even I have made the stupid test of start Renoise and filling the first pattern of notes, and duplicate with CTLR + K up to 999 times (made with “Keep Sequence Sorted” enabled) without doing anything else. After, deleting patterns, it is impossible to re-add empty new patterns.This does not happen if you insert all the empty patterns from the beginning.

1000 - 150 = 850,150 missing to reach 1000.It is an example, try to eliminate more patterns.

Note: in my tool I always use “renoise.song().sequencer:sort()” as much as inserting patterns, as when cloning.,I do not think this is the problem, since what happens is without using tools.¿Occur something with the memory usage?

The extreme case:I have removed up to 999 patterns, and it is impossible to add one more pattern. The warning window appears with only 1 pattern in Pattern Matrix.It seems that if Renoise writes a pattern, it is never released.This should not happen.This has been proven withKeep Sequence Sorted" enabled.

Imagine the stage: you have only one pattern, adds one more pattern, and the warning appears"Sequence operation was aborted. The operation would create more than 1000 patters, which is the maximum supported amount of patterns per song."

It’s an extreme case, but it should never happen.The user may experience it sometime.If it is not a bug, something is missing under the hood to avoid this situation.

Delete Unused Patterns?

It is necessary that the user has to go to the menu and click on delete unused patterns? If you have already manually deleted them before.

“Delete Unused Patterns” take the throw to remove the empty patterns that you can see in Matrix Pattern (same as for tracks).If the user deletes a pattern manually has already eliminated it, already it is not in use.Why the deleted pattern “remains hidden”, if you can do it undo (CTRL+Z).Which is the reason?

“Delete Unused Patterns” take the throw to remove the empty patterns that you can see in Matrix Pattern (same as for tracks).If the user deletes a pattern manually has already eliminated it, already it is not in use.Why the deleted pattern “remains hidden”, if you can do it undo (CTRL+Z).Which is the reason?

In Renoise, removing a pattern from the sequence doesn’t delete it as such.

And that’s a very good thing: if removing some pattern from the sequence deleted it, a simple shortcut like CTRL+Left/Right shortcut could cause you to unintentionally remove patterns from the song.

So…they tend to hang around…“how” they do it is is the important part to understand.

Renoise has two modes: sorted and unsorted. To most people, “sorted” would be the obvious choice: a list of numbers, gradually increasing as you get further down the list (well, unless you include pattern aliases which can reference earlier patterns). Unsorted is cool to have when you’re old-school and want to use pattern numbers instead of names.

Imagine you are in unsorted mode and have yourself two patterns, first is 0 and second is 999. Now obviously inserting a new pattern is not possible (will display that error) because we already have a thousand patterns. If you do a sort() on this sequence, the sequence is compacted to just 2 patterns. You’ll have 998 patterns available - as expected.

But even with the sorted mode, patterns can stick around. This is where it gets a little complicated - if the pattern was removed from the sequence, and not empty, it will still retain it’s index after a sort.

Imagine that this time you are in sorted mode and have yourself two patterns, first is 0 and second is 999. You enter a note into pattern #999 and then you click “minus” to remove it from the sequence.

Being in sorted mode, you could then assume that running sort() would result in pattern indices being compacted to two patterns? At least, that’s how I understand you.

But the truth is, it will hang around too - still be present at #999 and so you’ll have a total of 1000 patterns. Why?

Well, otherwise tools could break all over the place. Because, as we have established, patterns are not removed - they hang around.

And a tool might work on memorized patterns indices - including patterns that are not actually in the pattern sequence, but just “hanging around”. For example, a tool might use a “temporary pattern” to do something before copying it into the actual pattern. There are many possible scenarios, as I’m sure you could imagine.

But, if Renoise did change the pattern indices that were not included in the pattern sequence, tools would have no way of knowing. Because, as far as pattern-indices go, a tool can only listen to notifications from the pattern sequence itself.

I’m not sure if this is the only technical reason it’s working like it is, but the bottom line is that this is a source of confusion for users.

The error messages could do a better job explaining why it happens and what can be done.

Hi Danoise

I am sure any user will be confused with this topic. It is not clear and maybe it could work otherwise.Maybe Renoise could withstand 2000 patterns, and have some spare for the “old school” or to withstand the disorder of the patterns without forcing to imagine the user who has hidden.

Regarding if it is the case that a tool (or many) breaks and for that reason not change Renoise,this philosophy should disappear.If something is justified that Renoise can improve and for that reason a tool breaks, it should not be an excuse not to implement it.

I am creating my own tool, with many hours of work. If an update breaks my tool, it will be my fault not to keep it.I know it hurts, but improving Renoise would always should have priority against the tools.

The truth is that this topic is a little confusing.By the way, I ask you, what is the maximum limit of tracks?

And a related topic about performance.Does Renoise have a processing limiter?Imagine creating a heavy function, with many orders.The time it takes a while to Renoise invokes a warning window to stop the operation.Is there any way to control it?On powerful computers this is a bit of a nuisance.You can give more time and the operation is completed correctly.

local rns = renoise.song()
local indices,min,max = {}
for i = 1,#rns.sequencer.pattern_sequence do
table.insert(indices,rns.sequencer.pattern_sequence[i])
end
for i = 1,#rns.patterns do
if not table.find(indices,i) then
print("clear this pattern:",i)
local patt = rns.patterns[i]
if patt and not patt.is_empty then
patt:clear()
end
end
end
rns.sequencer:sort()

Thanks for this!It works perfectly.It would be interesting to have a similar function for the “tracks”, and another for the “instruments”…

I’m not aware of a limit to the number of tracks, no.

And a related topic about performance.Does Renoise have a processing limiter?Imagine creating a heavy function, with many orders.The time it takes a while to Renoise invokes a warning window to stop the operation.Is there any way to control it?On powerful computers this is a bit of a nuisance.You can give more time and the operation is completed correctly.

For this you need to use lua co-routines. You basically ask an isolated part of your code to run as it’s own process.

There is a demonstration in the XRNXStarter Kit- I assume you’ve already downloaded that one. But what’s important to know is that these processes are running isolated from your normal tool. In other words, it’s “fire and forget” - in case something breaks during the process, it’s hard to tell what went wrong. So make sure your tool is bulletproof before you add process slicing to it

Regarding if it is the case that a tool (or many) breaks and for that reason not change Renoise,this philosophy should disappear.If something is justified that Renoise can improve and for that reason a tool breaks, it should not be an excuse not to implement it.

It’s not even that a tool could break. This is of course something to avoid if possible, but sometimes it isn’t.
No, the problem I describe is basically that if the pattern sequence was automatically compacted many things we can current do with tools no longer would be possible. And that’s a bummer!

But like I said,I’m not sure if this is the only reason.