save an instrument
inject xml beatsync to 8192 (or anything over 512)
zip it up
load the xrni, plays correctly
save the song, load → crash.
I’m just curious to understand why, from a programing and math perspective, 512 is the limit for both pattern length and beatsync. Would love to read about it.
I know most values are multiples of 2 (64, 128 … 2048 etc). But why does it stop at 512 for line count?
1 Like
I suppose 512 is a limit chosen intentionally to maintain reasonable performance in certain cases, including compatibility with other formats (Renoise is not alone). For example, in the length of a pattern, as designed, each line can contain a lot of data. In large projects, there can be many tracks, each with a fairly long line length, 12 note columns, and 8 effect columns if the track is a note track, with all that data. Multiply all that content by 512. If Renoise has to calculate things, keeping a “minimally reduced” range speeds up those calculations.
This is clearly seen in Lua tools (it might be even more efficient internally in C++). That 512 marks a maximum range for searching. If the range were 1024, that search could take twice as long in specific cases. If we think about it in depth, 512 is a good limit (that’s considering something large, since 64 or 128 is much more common in many songs). In this case, if you have 1000 patterns, there’s a sufficient range of lines to compose anything of any reasonable length. Why 1000? Because it’s enough.
Ultimately, it’s something like, I don’t go beyond a very large size so that what the sofware do within that range is fast enough. If exist double that value, there will be cases within it where something will work slower, for example, searching for a specific note in a certain place to be able to change it in a combined pitch transposition operation.
The pattern case is a particular one. But if we’re talking about resolution in certain effects parameter, increasing the range could be beneficial. In programming, you have to be quite methodical, or have a fairly structured way of thinking (“en español se dice el tener una cabeza cuadriculada”); compartmentalize into smaller pieces to make analysis/processing easier. This limitation has been considered from the beginning, and it’s probably inherited from something that already existed before and worked well or had already been tested.
In code it’s like taking a loaf of bread and cutting it into slices to make it more digestible…
2 Likes
Makes sense now! Hadn’t thought of it this way. It increases exponentially (duh! to myself).
Good metaphor 
Completely unrelated to thread subject, but in Portuguese (my language) ‘cabeza cuadriculada’ (cabeça quadrada) means someone stubborn haha.
I definitely understand your point about bounded systems and keeping operations predictable, especially from the API/tooling side. Which I’m slowly learning more about
I think where BeatSync feels a little different to me is that it’s fundamentally more of a timing/resolution parameter than a large traversal structure like patterns or note data. Increasing that range doesn’t seem like it will necessarily explode the visible editing/search space in the same way.
Also, the engine already appears capable of handling much larger BeatSync values than 512 internally. The XRNI itself will accept essentially any integer value. And @esaruoho tool was able to inject values up to 65535 successfully.
The real issue seems to be the mismatch between the runtime/parser side and XRNS serialization, since saving the project causes crashes once those unsupported states exist.
ATP, I wouldn’t even argue for “unlimited.” A bounded ceiling around the existing internal integer range (65535) already feels far beyond sufficient for any realistic BPM/LPB scenario, while still keeping things finite and predictable programmatically.