It is still technically base 16, just instead of writing 100, it is G0, 110 is H0, 120 is I0 and so on. The ones remains cycling through 0-f for compatibility reason. O and I can be used because it is the job from the fix width font:
1I0O
This is not hard to do since you just need the first digit to overflow just like the SunVox bug I have shown, no base change required.
using a 17th symbol make it technically not base16 anymore. 
Was doing some research and came upon the idea of Base36 (00–ZZ)
Which is interesting because it would expands resolution/capacity massively (1296 values vs 256 in hex) without a significant UI change as far as I can imagine. It would be super overkill, but that’s the whole point. Similar to the BeatSync idea:
Preserve the workflow philosophy,
increase the underlying fidelity/capability.
I can’t think of anything other than the instrument slots that would even come close to hitting this limit.
Definitely not sample velocity because even with hexadecimal we already have 256 levels vs 128(standard midi) but it’s capped at 80(7-bit)
Unless:
Velocity/sample indexing itself became higher resolution.
At that point, the sampler starts becoming less “velocity = volume” and more “velocity = expressive sample selection space.”
Things like:
ultra dense velocity layers
articulation switching
round robins
probabilistic sample selection
morphing between sample states
Kontakt-style expressive instruments
all become possible if the indexing expands beyond traditional 7-bit limits, which technically things like velocity already could do but it’s just capped at 80
And what’s interesting to me is this could theoretically happen while still preserving Renoise without moving toward giant scripting systems or DAW-style GUI complexity.
Just an idea
hmmm… but it doesn’t matter anymore since the point is to fit more numbers into a two columns slot while it still have a sense of familiarity. I am not sure why it has to be in hexadecimal and why we can’t just use a mix base number just to get around the two slot limitation.
If you don’t like this solution, what else you would prefer?
Some people will suggest that adding additional columns, but other people will argue that two extra columns are annoying to look at because they don’t ever use more than 256 instruments. After that, people will think of the collapsible column when the instrument count is less than 256, then people will argue that the logic is complicated which is not suitable for Renoise due to the legacy code base.
Let’s see if you have some wise ideas regardless to your original question:
but after that, It doesn’t really matter for my ends since I am not the one who develop Renoise and I do have some other coding projects to work 
Plugins ofc wouldn’t be able to interact with Renoise at that level.
But Renoise instruments exist inside the pattern architecture itself.
Which is why increasing symbolic/indexing fidelity becomes interesting.
Right now Sxx already gives us hexadecimal addressing across 256 positions inside a sample.
Imagine that expanded into Base-36 territory: finer sample addressing, higher resolution sample-state selection, and deeper tracker-controlled performance behavior.
Suddenly the sampler starts feeling less like “just a sample player” and more like a programmable instrument environment. Like Super XNRI 
And the crazy thing is, it seems like the foundations are there. Which is why I keep coming back to the same idea:
The engine already feels more capable than some of the exposed limits imply. Of course I don’t know for sure because I didn’t program the damn thing, but who knows maybe something will make sense to the developers and one day be implemented.
+1
The symbolic compactness matters more than strict hexadecimal purity.
cf. Rethinking Legacy Limits - #20 by ylmrx , the usual solve 1 edge-case, create 2 other problems
(tl;dr 16-arity is pretty important)
if you’re given 1500 slot, you’ll max that out in 2 weeks, and back to square one.
Backward compatibility would definitely be one of the biggest considerations.
But theoretically I don’t see why older projects couldn’t simply remain interpreted under the original hexadecimal system, or optionally converted when opened in a newer Renoise version.
The actual value relationships would still exist — it would mostly just be a different symbolic representation/indexing range.
So to me it feels more like a compatibility/UI design problem than a mathematical limitation.
That’s the only issue I can think of that would arise, but I’m sure there are others
I like these things; they make you rethink how work.
From what I see, the first problem with this is scalability (precisely one of the problems you aim to solve when rewriting code in new projects).
Scalability doesn’t just imply “compatibility,” but also simplicity in the code. When you complicate things by duplicating databases (to achieve compatibility), you break the essence of scalability (that something should be easily possible in the future). Future, project, see beyond, speculate, etc. It will depend on what is to be implemented later and what does not yet exist.
Scalable in this case means that you can maintain the base16 encoding and have it embedded within the base36 encoding. But that’s not the case.
Compatibility would only be achieved from 0 to F (16 values).
This creates a structural code problem (Renoise relies almost entirely on base16; incidentally, Renoise uses ranges exceeding 256 elsewhere, if I remember correctly).
Another problem is format compatibility, beyond xrns itself.
Another issue is in Lua. There’s no direct conversion (standard syntax). You have to write your own two functions that convert values in both directions to work with base36. In C++ and Lua, you can refer to base16 directly (for example, 0xFF), just like with the numeric base 0 to 9. The same applies to strings, where there are code functions that return the correct values (for example, string.format("%X", n), n=number). However, with base36, there’s no such thing; you have to create it yourself.
As it stands now, Lua and the Renoise API could create complex window tools working in base36, but this wouldn’t be very useful. It wouldn’t make sense if Renoise’s limitation is base16 and you’re constantly referencing values in that base.
It’s as if everything is focused on something outdated that was considered sufficient at the time. Now, changing it would involve modifying too many things to make the whole thing coherent. You either use base16 for everything or base36 for everything, but not both at the same time. Perhaps it’s best not to. I’m speaking from a programming perspective.
At present, if someone had to create a new Renoise from scratch, base36 might be a good starting point, given the powerful hardware we have now. But this would only be advantageous in large projects, I suppose. In most cases, base16 seems sufficient. However, at some point, things will have to evolve. If that were the case, I think I would keep the base16 and break the 2-digit limit (in any case). I wouldn’t use base36. But this would actually complicate understanding even further. Hexadecimal notation remains a learning barrier for many. I don’t even want to imagine what would happen with base36.
That’s why it’s so important to study things beforehand so that they can be scaled. But that scalability will conflict with compatibility with older formats (not just xrns). Many programs use base16. It is something “universal” or familiar.
Didn’t study thread close enough 
and not ideal for the masses, but doesn’t the phrase scripting option offer a workaround to get past legacy limitations: if in the future besides note event stuff we could control more things with it? I think automation is on the roadmap, plus the github speaks of sample offset control (think SXX like sample manipulation) among other things like glide.
I imagine if implemented, through a phrase script you wouldn’t be limited to the hex positions in a sample, but could express playback start of a sample as a %, have a much finer resolution(?). Also, for years there have been threads on looppoint automation, other then current tool workarounds, this would also be nice to have natively through phrase scripting imo.
Definitely not. Was it ever? 
Y esta declaración definitivamente debería ser respetada a lo más
Perhaps a reinterpretation from the ground up without the constraints that were placed there do to the state of technology at the time. A big ask but:
Cien por cien 
What do you propose the constraints on beatsync being limited to 512 lines or even being coupled with the LPB? (See earlier post in thread for details)
Not to intentionally bump this thread, but this has to be one of coolest “glitches”
Just seeing that value of 8192 in the beatsync index box has me wondering why this happened.
Although I I previously stated my hypothesis, I would really like to know:
• Why this has happened?
• Is the engine actually capable of sustaining something like this?
Thanks again @tkna for stress testing this as well bro
You’re welcome.
I tried a simple experiment using Vibe Coding, but it seems the API doesn’t allow values greater than 512.
For now, maybe it would be enough if they just removed that restriction.
@taktik What do you think?
Where’s your album guys? Your just thinking thoughts for the sake of thinking thoughts!
Here is a recording of yesterday’s live performance.
https://paste.tkna.work/Liberty_and_equality_guaranteed_by_God_20260519-live-jisaku.opus
Some of you may find it a bit rough around the edges, but through my work, I am always exploring the possibilities of various forms of expression.
I’ve already posted music in the Share Your Music thread. Type Beat Producer here 
, not someone focused on self-released jungle albums or long-form artist projects. Different workflows, different goals.
But this discussion is about BeatSync behavior and engine limitations, not discographies.
Raising the limit honestly SEEMS like the safest and most realistic approach at this point, especially now that we’ve seen the engine internally jump beyond 512 under certain conditions.
Decoupling BeatSync fidelity from LPB would definitely be interesting, but I could also see that introducing major backwards compatibility issues since BeatSync timing is currently tied directly to the global LPB interpretation. Older projects could potentially load/play differently if that relationship changed.
Increasing the ceiling seems much less invasive architecturally while still massively improving long-form synced sample usability.
@tkna i need you to tell me what exactly happens that it suddenly goes to 8192. i have tried to look at the video but i cant figure out where it went.
The key is to set the BPM to 20 and the LPB to 256.
If you load a longer sample after that, it should probably work.
no, the key is to inject 8192 beatsync inside the xrni xml.
then it loads as 8192.
