Polyphony limit on long release times?

[Stelpa]

A while back, I spoke with one of the devs (can’t remember who exactly) about the arbitrary limit of 12(?) running instances of a single instrument at any given time. Once 12 simultaneous instances of the instrument play simultaneously, the next note-on will cancel the oldest-running instance abruptly. This limit existed on 2.8.0, and I assume it’s existed on other versions as well. The dev I spoke to told me this limit would be gone in the next version; 2.8.2 came and went without a fix, so I assumed that it was being worked on for 3.0, but alas, it is still there, annoying as ever.

I assume this limit was put in place to keep people from accidentally crashing Renoise by creating hundreds of instances of an instrument simultaneously with a nearly-infinite release time, inevitably breaking their CPU threshold. That being said, this limit is incredibly frustrating to work with when making any sort of ambient or drone music, if any instrument with a long release time needs a specific emphasis (e.g. playing a melody on an instrument with a very long release time, or playing large chords with 13 or more notes).

The only workaround I’ve found for this limit is using several duplicates of the same instrument, and playing with those instruments when the limit for the one preceding it has been reached, but as you could imagine this is hardly suitable to a comfortable workflow, and is rather impossible to manage when playing things ‘live’, unless you’re constantly keeping track of how many notes are currently playing at the moment, and are always ready to switch to the next duplicate.

I feel that, while the limit is necessary to prevent inexperienced users from overtaxing their systems, the current limit is much too low (12 simultaneous notes maximum? Really?). A good compromise, I feel, would be to add an option in the preferences menu for “polyphony limit per instrument”, with a maximum value of “inf/unlimited”. Or perhaps this limit could be set on each instrument/sample individually, in the same way that interpolation or transposition is chosen. Regardless of what’s done to resolve this issue, the current state of things is, in my opinion, needlessly restrictive to the user.

Thanks.

[danoise]

Hi Stelpa! I’m not a core developer, but this is how I understand that Renoise works internally:

The limit of 12 voices is enforced per note column, of which we have up to 12 per track - this should give each track a limit of 12*12 = 144 voices per track.
Depending on the way things are triggered (having the “chord” mode enabled in 2.8, instrument “solo” option in 3.0) will dramatically affect the number of simultaneous voices you can trigger when playing live.

There are additional things to consider when using phrases, which can also have 12 “internal” note columns (pushing the number of voices even higher). But I’m afraid you’ll have to wait for one of the core devs to give you the full details on that…however, I completely agree that we should be able to control these things somehow

[Stelpa]

@danoise

Hi Stelpa! I’m not a core developer, but this is how I understand that Renoise works internally:

The limit of 12 voices is enforced per note column, of which we have up to 12 per track - this should give each track a limit of 12*12 = 144 voices per track.
Depending on the way things are triggered (having the “chord” mode enabled in 2.8, instrument “solo” option in 3.0) will dramatically affect the number of simultaneous voices you can trigger when playing live.

There are additional things to consider when using phrases, which can also have 12 “internal” note columns (pushing the number of voices even higher). But I’m afraid you’ll have to wait for one of the core devs to give you the full details on that…however, I completely agree that we should be able to control these things somehow

Ah, I’d completely forgotten about the fact that the limit is column-based, not instrument based! I remember now that the dev I talked to made that point clear; that does indeed make things quite a bit nicer to deal with, but I still feel the limit is a bit restrictive, and it makes neat organization quite difficult if you have some instruments going all over different columns to compensate for the voice limit; it almost adds a whole new stress to the process of songwriting, the stress of voice management. I feel like things like this shouldn’t be restricted by an arbitrary software limitation, when the hardware could certainly handle it.

Thank you for reminding me about how things are happening under the hood though, as it does make devising workarounds slightly easier, though still somewhat counter-intuitive.

[gentleclockdivider]

hey stelpa , your avatar is brian eno …from the ’ taking tiger mountain’ lp …right ?
LOvely album

[Stelpa]

@gentleclockdivider

hey stelpa , your avatar is brian eno …from the ’ taking tiger mountain’ lp …right ?
LOvely album

Yes and yes!

One of my favorite albums, actually! Neat that people recognize it

[Stelpa]

Bump, still waiting for word from core dev…

[vvoois (vV)]

@Stelpa

I assume this limit was put in place to keep people from accidentally crashing Renoise by creating hundreds of instances of an instrument simultaneously with a nearly-infinite release time, inevitably breaking their CPU threshold.

Next to what Danoise already explained, the risk of experiencing this is even higher in Renoise 3.0 as each sample may also going through specific modulation and effect chains inside the instrument.
If you have a powerful enough pc i don’t think the cpu consumption will be that terrible if you use sample based instruments only. It might form a problem if you want to add a few heavy-load VST plugins.

Suppose the limit would be user customizable, it will be harder to share xrns songs as when you raise the bar to a very high level, it might be that other renoise users would not experience your level of sample processing.
Such option would at least need to be written along with the song but will not guarantee the song will play flawless on every machine.

[Stelpa]

@vV

Next to what Danoise already explained, the risk of experiencing this is even higher in Renoise 3.0 as each sample may also going through specific modulation and effect chains inside the instrument.
If you have a powerful enough pc i don’t think the cpu consumption will be that terrible if you use sample based instruments only. It might form a problem if you want to add a few heavy-load VST plugins.

Suppose the limit would be user customizable, it will be harder to share xrns songs as when you raise the bar to a very high level, it might be that other renoise users would not experience your level of sample processing.
Such option would at least need to be written along with the song but will not guarantee the song will play flawless on every machine.

Perhaps it could be a user-specified option tied to the xrns, in the same way as groove/lpb, rather than something you choose in the settings?

And there’s never a guarantee any song will “play flawlessly on every machine”, that was never the intention (I know this very well, as a Linux user with a low-end laptop, speaking of ‘heavy load vst plugins’). I certainly don’t see that as a reason not to give the user more choice, especially since the preset limit is so restrictive to some users.

EDIT: I should also add that, since you brought up Renoise 3.0’s new in-instrument effects/modulation, this also applies in favor of more control over polyphony as well; more users will be using instruments with longer/more complex envelopes and longer releases now that they have so much more control over them, so it will be even more frustrating when they cap at an arbitrary limit that can’t be changed, only annoyingly worked around.

[Stelpa]

One final bump, curious to hear thoughts from a core dev. If no response, I’ll leave the thread be, though I’d still count control over per-column polyphony limit as one of my highest-priority feature requests for sure.

[vvoois (vV)]

@Stelpa

EDIT: I should also add that, since you brought up Renoise 3.0’s new in-instrument effects/modulation, this also applies in favor of more control over polyphony as well; more users will be using instruments with longer/more complex envelopes and longer releases now that they have so much more control over them, so it will be even more frustrating when they cap at an arbitrary limit that can’t be changed, only annoyingly worked around.

Limits exist not only for computational reasons but also for managable reasons. Being able to allow a polyphonic note limit will also be a workaround because someone would still have to manually change the figure. Song based it will have to be (which makes it also a bit uncomfortable to have an oversight for.).

I suspect a good compromise would be that 144 voices are divided across note-columns that are visible. Meaning if you only use 3 notecolumns, you have 48 voices, if you use 4, you have 36. (24 for 6 notecoluns).
At max i suspect 6 columns in use would be a generic used maximum amount of columns, would 24 voices per column be enough?
This way, no extra options have to be added, it is a per track, per song solution. The only minor side-note is that people have to get adapted to the idea of counting notecolumns to figure out what limit they have if they go beyond the 6 column mark (or if they need more than 24 voices). This thing also affects playing instruments in specific tracks, when testing e.g. multi layered key assignments (you notice in one case only 12 samples lit up when pressing a key, yet when you move the cursor to another single track you see 76 lit up if you have 76 assigned to the same keyzone)

[Stelpa]

@vV

Limits exist not only for computational reasons but also for managable reasons. Being able to allow a polyphonic note limit will also be a workaround because someone would still have to manually change the figure. Song based it will have to be (which makes it also a bit uncomfortable to have an oversight for.).

I suspect a good compromise would be that 144 voices are divided across note-columns that are visible. Meaning if you only use 3 notecolumns, you have 48 voices, if you use 4, you have 36. (24 for 6 notecoluns).
At max i suspect 6 columns in use would be a generic used maximum amount of columns, would 24 voices per column be enough?
This way, no extra options have to be added, it is a per track, per song solution. The only minor side-note is that people have to get adapted to the idea of counting notecolumns to figure out what limit they have if they go beyond the 6 column mark (or if they need more than 24 voices). This thing also affects playing instruments in specific tracks, when testing e.g. multi layered key assignments (you notice in one case only 12 samples lit up when pressing a key, yet when you move the cursor to another single track you see 76 lit up if you have 76 assigned to the same keyzone)

Great idea! I like this suggestion lot, and I’d be much more comfortable with this compromise than how it is currently. Hopefully the devs will give this thought some consideration, as it will make things much simpler for people like me who utilize large chords and harmonies, without the change negatively affecting the experience of other users.

24 voices per column with even distribution isn’t perfect, but it’d certainly be better than it is now; if allowing users to set a custom limit or raising the built-in polyphony limit aren’t options, then this would be the next best thing.

[Hazardous_33]

@vV

Limits exist not only for computational reasons but also for managable reasons. Being able to allow a polyphonic note limit will also be a workaround because someone would still have to manually change the figure. Song based it will have to be (which makes it also a bit uncomfortable to have an oversight for.).

I suspect a good compromise would be that 144 voices are divided across note-columns that are visible. Meaning if you only use 3 notecolumns, you have 48 voices, if you use 4, you have 36. (24 for 6 notecoluns).
At max i suspect 6 columns in use would be a generic used maximum amount of columns, would 24 voices per column be enough?
This way, no extra options have to be added, it is a per track, per song solution. The only minor side-note is that people have to get adapted to the idea of counting notecolumns to figure out what limit they have if they go beyond the 6 column mark (or if they need more than 24 voices). This thing also affects playing instruments in specific tracks, when testing e.g. multi layered key assignments (you notice in one case only 12 samples lit up when pressing a key, yet when you move the cursor to another single track you see 76 lit up if you have 76 assigned to the same keyzone)

I do not like this idea. I also use Renoise as a form of tabulature to represent not only what notes are to be played, but how to play them on an actual instrument. For example, if I have a piano or keyboard instrument, I will create a track with ten note columns - one for each finger. If I have a drum kit instrument, I prefer to create a track with four columns - two for hands, two for feet (although if using a VST instrument I will route the outputs of different drums in the kit to separate tracks for mixing). If I have a guitar or bass track, I’ll have a note column for each string. This makes it easy for me to read the music from the tracker and practice parts for live performance (and is why I’ve requested the ability to print tracker note data).

Maximum polyphony should have absolutely nothing to do with how many note columns are present. I don’t want the tails of notes being cut off in a drum kit just because I prefer to keep the note data in a smaller number of columns.

Other samplers have been able to cope with large levels of polyphony for a couple of decades, and do not chew up huge amounts of CPU in the process. Something is wrong if this is a limitation Renoise can’t get past - most DAWs and samplers manage to do much better without bizarre workarounds.

[danoise]

@Hazardous!

I don’t want the tails of notes being cut off in a drum kit just because I prefer to keep the note data in a smaller number of columns.

You seem to be misunderstanding the purpose of NNA actions then.
For example, imagine that we have 4 samples triggering in the same note-column with a long release?
If you set the sound to NNA/Note-off, then you will have 4 voices playing simultaneously, each one fading out as the next one is triggered.
If you set the sound to NNA/Cut, yes, then you will have only 1 voice playing. But this is useful too.

The thing I don’t get about vV proposal is, what to do with 144 voices in a single note-column?
Does anyone need that many overlapping voices?

[vvoois (vV)]

@danoise

The thing I don’t get about vV proposal is, what to do with 144 voices in a single note-column?
Does anyone need that many overlapping voices?

I’m sure someone will whip up such an instrument with 24 simultaneous triggered layers per note with 5 minutes of decay. Well, then 144 voices is still not enough

[Stelpa]

@Hazardous!

Other samplers have been able to cope with large levels of polyphony for a couple of decades, and do not chew up huge amounts of CPU in the process. Something is wrong if this is a limitation Renoise can’t get past - most DAWs and samplers manage to do much better without bizarre workarounds.

Very true! Though keep in mind that renoise does do more to samples than other trackers, due to the effect chains and envelopes possible. But yeah, the limit is way too small, as it is now, even with that in mind…

@Hazardous!

Does anyone need that many overlapping voices?

I do! And, if you’re composing orchestral/symphonic works with drones, or works for a large variety of instruments simultaneously, this limit can be reached rather quickly, especially if you enjoy doubling/tripling/quadrupling/etc notes in chords, or using very long releases. It’s really not that high of a limit, to be honest; if it were something like 1440, then it would be a bit more unrealistic to complain about, but the current limit is actually pretty restrictive if you’re making music like that mentioned above.

Renoise imposes very few limits on the user, which is one of the reasons I like it… Therefore, the fact that this limit is so set-in-stone and arbitrary irks me quite a bit. I feel like even something like a checkbox to disable it could solve the issue without requiring nasty workarounds that only overcomplicate (perhaps with an included warning of potential cpu usage increase).

[Etheross]

Bumping because I ran into this problem while making synths for a keyboard.