Hi,
I would love it if I could have more than 512 rows in the pattern/phrase editor.
Thank you!
Why not make them unlimited?
Personally I think the ability to zoom in to get better resolution (when it’s needed) is a bit more intuitive. And the ability to zoom out to get better overview ofc. So, yeah, maybe this is the same as having more rows in practical means. Please correct me if I’m wrong.
To have 10k rows is course not needed for every instrument/track. So alternatively, when there are less complex stuff like a kickdrum just going on about the same during longer segments of a song, there could be a “glue-blocks-feature”. So when there’s time to copy&paste you don’t have to select so many blocks.
Well well, maybe this is just me…
1 Like
Hi,
Still here. Still happily using Renoise. Still wondering why this limit exists.
My workflow increasingly leverages nested programming approaches, especially with VSTs. The current ability to nest tracked patters inside VST instrument instances is great but, in the interest of being able to vary otherwise repetitive phrases, it would be great to be able to have longer phrases and patterns from a scalability standpoint.
The current 9-bit cap seems arbitrary and needlessly base-2 conformist.
Thanks!
i agree with chris, that option to zoom for better resolution sounds awesome and was thinking about a lot! would be so useful!
I think there is a false equivalence, either/or mindset at work here.
I think that having the ability to zoom to deeper scale would be interesting but, I think it also requires more architectural changes to the way that patterns currently work.
I can do the mental gymnastics to resolve current resolution issues by using the delay column with it’s 256 steps of precision between pattern lines, however, if I have sketched out an idea using the current default resolution and then want to extend it beyond the 512 rows, I have to rewrite the whole thing.
So from a workflow standpoint, it would be nice to have a higher limit. I suspect that the current limitations are defined by a struct somewhere in the code and it could hopefully be expanded with less peripheral tweaks necessary than having to reengineer the pattern editor to allow for variable resolution steps. I think that’s a lovely idea, but it’s a separate issue.
1 Like