Rethinking Legacy Limits

[elcasiino]

Renoise is one of the most precise and technically capable DAWs available today. Its tracker-based architecture enables a level of surgical control that many modern DAWs still struggle to match, especially when paired with the growing ecosystem of advanced tools (e.g. Piano Roll Studio, phrase-based workflows, instrument generators, slicing tools, etc.).

That said, I’d like to raise a broader architectural question:

Do legacy limits still serve Renoise’s long-term potential?

Specifically:

• The beat-sync line limit

• Instrument / voice / sample-per-note limits

• Other fixed caps that originate from historical or legacy design decisions

These limits made sense when trackers were tightly bound to hardware and performance constraints. Today, however, they are no longer technical necessities—they are policy constraints. Modern systems can comfortably handle far higher ceilings without impacting users who prefer traditional workflows.

Importantly, removing or raising these limits would not force anyone to change how they work:

• Tracker-centric users could continue exactly as before

• UX and workflow would remain unchanged

• No features would be taken away

What would change is accessibility and scope:

• Renoise would become more inviting to producers working with long-form audio, vocals, orchestral, cinematic, and urban music

• Beat-synced sampling could reach a level of fidelity and realism unmatched by other samplers

• Advanced users could fully leverage Renoise’s deterministic, math-driven engine without artificial ceilings

Renoise already outperforms many contemporary DAWs in areas like precision, timing authority, and instrument control. Removing legacy caps would amplify those strengths, not dilute them.

Being a tracker should not mean being constrained by tracker-era limits. Renoise can remain true to its identity while still evolving into an even more capable, future-proof instrument and composition environment.

I believe lifting or significantly expanding these limits would:

• Not hinder existing users in any way

• Open Renoise to new creative domains

• Strengthen its position as a serious power DAW, not just a niche one

Thank you for considering this perspective, and for continuing to develop one of the most technically impressive music tools available.

[tkna]

There’s no need to pack every feature into a single tool.
If you want to do something other DAWs can do, you can at least use another DAW for that specific part.
(Though I sympathize with the difficulty of linking different DAWs together on Windows or macOS, especially now that ReWire is gone.)
I feel Renoise’s fundamental identity, uniqueness, and concept—its intense individuality—lies in being a high-powered tracker rather than a DAW, bound by the constraints of a tracker.
Its ability to import MOD, XM, and IT files and maintain compatibility with them is truly remarkable.
I believe this commitment to compatibility has established Renoise’s concept of stable specifications.

[elcasiino]

Sorry bud, but I have to disagree here. As someone who’s used multiple DAWs, and has been on their forums, this is the only one where people actively suggest using a different product when someone suggest something. That’s incredibly counterintuitive.

Removing limits and or increasing functionality is NOT the same as packing something with features. I’m not talking about things that can be done with Tools. As a matter of fact, Renoise having a scripting feature strengthens the concept of it being a modern DAW and not just the super tracker. Which don’t get me wrong, is super cool.

I’m simply talking about removing arbitrary limits that serve no purpose other than to maintain an identity.

There is no reason for there to be a 256 limit on the amount of instruments. There is no reasonable reason for a note to only be able to trigger 12 samples nor a limit of 12 note columns and a cap on FX columns. I’m simply saying remove these caps.

[tkna]

Sorry, I seem to have misunderstood.
You want to increase the upper limit of those constants, or eliminate them altogether and rely on hardware limitations, much like an infinite undo buffer in a text editor. I can understand that need.

[elcasiino]

Exactly.

I want to expand on BeatSync specifically, because it’s the clearest example of a system that already works perfectly and is only held back by an artificial ceiling.

This is not a request for a new feature.
This is a request to stop artificially capping a system that already works.

Renoise already calculates BeatSync automatically when a sample is loaded. It already knows:

• The exact sample length in frames
• The sample rate
• The song tempo
• The global LPB
• The exact frame-to-line relationship

That calculation already exists. Users can see it the moment a sample is loaded and BeatSync lines are proposed automatically. The math is done. The result is correct.

The only limitation is that the result is clamped to 512 lines.

If that clamp were removed (or meaningfully raised), several important things become possible immediately, without adding new DSP, UI, or analysis stages:

1. BeatSync could scale naturally with LPB
   Since LPB is already user-controlled, higher LPB values would directly translate into higher temporal resolution. This means cleaner, more precise stretching — not by guessing musical intent, but by increasing deterministic timing accuracy.

2. Slice playback could safely continue to the end of the sample
   Currently, allowing slices to play past the next slice marker becomes unusable with BeatSync because every slice is forced to complete within the capped line limit. With an uncapped BeatSync length, the engine could simply calculate from the slice start to the end of the sample — something it already knows how to do — and stay perfectly in sync.

3. Long-form material becomes viable without micro-slicing
   Vocals, pads, orchestral recordings, cinematic material, and soundtrack audio could be tempo-locked without destructive or excessive slicing. This does not remove precision — it increases it.

4. Fidelity improves instead of degrading
   Because BeatSync in Renoise is authoritative (it does not analyze content, warp transients, or reinterpret timing), increasing resolution via LPB produces cleaner results rather than artifacts. This is fundamentally different from marker-based or heuristic systems.

In fact, with an uncapped BeatSync limit and high LPB values, Renoise would offer some of the cleanest, most predictable tempo-locked playback available — arguably exceeding systems like Ableton or Serato, which rely on content-aware warping and corrective heuristics.

Renoise does not guess.
Renoise does not interpret.
Renoise enforces timing.

That strength is already present. The math already exists. The engine already does the work. The only thing preventing this level of fidelity is a hard-coded ceiling.

Importantly, removing this cap would not affect existing workflows at all. Users who never hit the limit would see no change. Tracker-oriented usage remains exactly the same. This simply allows the system to scale when users intentionally push it.

This is not about changing Renoise’s identity.
It’s about allowing one of its strongest systems to operate without unnecessary restriction.

BeatSync is already one of Renoise’s most powerful features.
It just needs room to breathe.

[tkna]

The hidden upper limit for Beatsync, set during sample loading, appears to be 8192 or higher.
At first glance, it doesn’t seem particularly difficult to implement a feature that allows setting the upper limit of the Beatsync value to at least 8192 even during manual operation.

[elcasiino]

I’m guessing the original sample is around 32 beats and you may have the auto calculate beat sync option on.

32 x 256 = 8,192. That may have something to do with it.

Not sure exactly how this glitch happened, but it shows that the math is already there. I would really like an explanation of this by a mod or something. It’s evident that the engine can definitely calculate higher lengths. The math is there.

[elcasiino]

Long read ahead guys but hear me out. I know I’m making sense here.

First, an observation that seems important:

The math and engine support for high-resolution BeatSync already exists.

We can see this clearly when:

• Samples briefly report BeatSync values far beyond 512

• High LPB settings (e.g. 256) expose internal calculations that exceed the visible clamp

• BeatSync remains stable and synchronized during those moments

This strongly suggests that the 512 BeatSync limit is not a technical limitation, but an artificial clamp applied at the UI / parameter level.

In other words: the system already works — it’s just being capped.

Why This Matters

BeatSync in Renoise is conceptually different (and stronger) than time-stretching in most DAWs:

• It does not analyze transients

• It does not guess tempo

• It simply enforces:
  “This sample must complete playback in exactly N musical time units.”

That is a mathematically authoritative model — and with higher resolution, it becomes extremely high-fidelity.

However, right now BeatSync fidelity is unintentionally tied to Global LPB, which serves a completely different purpose (editing/grid resolution). This coupling creates unnecessary tradeoffs:

• Higher LPB → better BeatSync fidelity, but harder editing

• Lower LPB → easier editing, but coarser BeatSync

These two concerns don’t actually need to be linked.

Proposal: Decouple BeatSync Fidelity from Global LPB

I’d like to suggest introducing an internal BeatSync resolution that is independent of Global LPB.

Some possible names (purely suggestions):

• BeatSync Resolution

• Time-Stretch Fidelity

• Internal LPB

• BeatSync Timebase

• Sample Sync Resolution

How it would work conceptually

• BeatSync calculations use a fixed, high internal resolution (e.g. 8192, 16384, or higher)

• Global LPB continues to control:

  • Pattern grid

  • Phrase resolution

  • Editing ergonomics

• Users who prefer tracker-style behavior could still opt for lower fidelity if desired

This could even live alongside existing timing options (e.g. near Ticks per Line) as a fidelity setting, not a workflow change.

Why This Is Backward-Compatible

Nothing would be removed.

• Users could still manually enter smaller BeatSync values to intentionally clamp playback

• Accelerated slice playback would still be possible

• Existing songs would sound identical unless the user opts in

This is about unlocking headroom, not forcing behavior.

Why This Would Be Sonically Significant

Renoise already:

• Calculates BeatSync automatically on sample load

• Knows the exact sample length in frames

• Knows tempo, LPB, and musical time precisely

With an uncapped or internally high-resolution BeatSync:

• Long samples could remain perfectly synced without speeding up

• Slice playback could continue to the end of a sample and still stay in time

• BeatSync would operate at a finer resolution than FFT-based stretchers

In practice, this could result in cleaner, more transparent time-stretching than what’s available in Ableton or Serato — using math Renoise already relies on.

Why This Fits Renoise’s Philosophy

This does not move Renoise away from being a tracker.

It moves Renoise away from tracker-era constraints that no longer reflect the engine’s capabilities.

No new features are required.

No UI overhaul is required.

No workflows are broken.

It’s simply a case of:

Stop artificially capping a system that already works.

I’d really appreciate hearing from a developer or moderator about:

• Why the 512 clamp exists given the higher internal values observed

• Whether exposing or raising this limit is feasible

• Whether a decoupled BeatSync fidelity setting would align with Renoise’s long-term direction

Thanks for taking the time to read —

[NPC1]

Patterns with different sizes in a song is already in?

happy Tracking

[elcasiino]

We know that friend. I’m talking about the hard limits set on pattern lengths, beatsync, instruments, etc.

It was a lot to read so I can understand the misread

[Epical]

One limit that in my opinion should be removed is the inability to send the signal back to the FX chain/track. I understand it was implemented to prevent accidental audio feedback. However it also prevents really interesting sound design… Maybe replace it with a warning pop up, or have an option in order to toggle the ability to do it?

[elcasiino]

I’m all for just jailbreaking and uncapping in general. In my opinion if you’re using a tracker you’re already savvy enough to not need training wheels. Or at the very least you have the capacity to learn something a lot more technical and surgical than what’s out there.