Delay Column; Change default to 80(hex)?

Ideas & suggestions
6

Hey chris, thought about it, my point is just wrong, since it’s simply a offset in your suggestion. I completely agree with you.

The only point now maybe would be that the numbers do not really reflect the offset anymore. I guess would be lead into some confusion.

I was also thinking about this two or three times at first, takes a while to “click”. :slight_smile: So sure, it will still mean some very off-notes will end up on a “previous line” even with this system. However, rarely a groove is that off. At least the notes will appear on the lines where they are closest to.

Hey chris, thought about it, my point is just wrong, since it’s simply a offset in your suggestion. I completely agree with you.

The only point now maybe would be that the numbers do not really reflect the offset anymore. I guess would be lead into some confusion.

I was actually gonna post some further thoughts regarding this, but I decided to wait a bit in case someone pointed it out which you did lol.

However, what I had in mind to avoid that confusion is simply a feature-name change to something like " Align Column" or " Nudge Column". If the feature is something people like I guess this will be the minor problem either way.

To keep the name “Delay Column” will probably be a bit misleading, unless it states “Pre-Delay” somewhere too. With that said, personally I think the “Delay Column” is not an ideal name for what it does and its purpose even with the current layout.

7

Does setting the “track delay control” to a negative value not accomplish the effect of changing the default delay for a track?

8

Does setting the “track delay control” to a negative value not accomplish the effect of changing the default delay for a track?

You mean the track ms delay in the mixer? I mentioned that in the original post, but it doesn’t give you the same type of control. It’s only a workaround as I see it, and others have said the same in other topics.

We’re talking about the humanize function which doesn’t affect the delay column “backwards”, meaning notes will never appear before the initial beat (only directly on the beat or forward).

9

Hey Chris,

Maybe I am confused here again, but what if simply the values 00-7f represent positive ones, while 80-ff Negatives with ff== -1? Why offsetting the Values?

EDIT:

SO I CONCLUDE, BEST WAY?

OLD NU
C-4 C-4
--- ---
C-4 00 C-4 00
C-4 FF ---
--- C-4 FF
--- ---
C-4 7F C-4 7F
C-4 8F ---
--- C-4 8F
--- ---
C-4 20 C-4 20
10

UPDAATE

11

+1

It seems natural for the note to be visually represented on the line being closest to where it is played. I once made a mockup where negative values were represented by red numbers and positive values by blue values (in this case, numbers above 7F would be blue and below would be red). Imho that would make it being more intuitively perceived.

12

This feature would be great. It would be massive workflow boost for manual note delay. Unsure if it’s already been mentioned here, but the obvious difference between note delay and mixer ms delay is that the former retains the offset relative the beat when changing tempo. I think a negative value indicator (1xx would suffice) would also prevent the weird effects of changing a default, which if I understand correctly would place all previously programmed offsets 128 ticks (half line) slower. I dig the idea of splitting the value, because I certainly don’t need as much resolution as we get now, but it would be problemtic for XRNSs programmed with the current scheme. As it stands, this may be the single most frustrating aspect of my sequencing workflow right now. +1

13

At first I was thinking this could be optional with a tick in the preferences, the pattern lines only being a rendition of how you want things represented. But then comes some problems to mind, regarding lua (line objects) and “live” usage leading to the conclusion that it has to be a new global standard.

And what happens if you play a pattern from start? Would any negative notes be ignored? I think they have to, or the implications will be that other usage scenarios will break.

14

I think a negative delay, despite being a feature that seems somewhat natural/functional, does run contrary to deep tracker logic. Lines don’t look backward, only forward. It’s an aspect of the simplicity and elegance of tracker design. This being said, I totally agree that it would be nice to at least have a note’s placement on the pattern more accurately reflect its position in “rhythm space”, only I don’t think the default pattern view is the place for it. So, nobody freak out on me here, but you may have noticed that I’ve recently been proposing some piano roll or “roll view” designs in this thread:https://forum.renoise.com/t/brainstorming-piano-roll/12547

The reason I point to those designs is that the roll view could allow for delay-nudging of notes up and down, providing a more accurate visualization of their trigger times. Back in the default view, Renoise is setting the note placement and delay values for you. There you would see the tracker-brain version of the programmed rhythm, as it has always been. It would make for no changes in core/expected functionality.

In short, I think an alternate presentation view (still vertical, always vertical), one focused on visualizing melody and rhythm, could come with a surprising number of natural-fit benefits.

15

I like your ideas cmakris, and agree to some extent.

On topic. What about just having the default delay value a setting, just like the default velocity value box already available today? That would make some of us happy without disturbing those who won’t use it, no?

Can’t wrap my head around if it would somewhat be incompatible with the Renoise groove implementation, but otherwise I see no reason why not. Sure, it would not be 100% smooth when importing midi clips et c, but good enough.

5953 rns1.png

16

I very much agree on the need for negative delay and this proposal is elegant from user point of view. Hopefully the pattern editor will get a serious update with 3.1…

Current delay column is a nasty piece of work for manual editing - it’s slow to retime events earlier in time as it’s always a two-step process (move one line up, try different delays instead of just trying different “nudge” values). Delay column works for MIDI recording but the output is messy.

17

I vote for negative delay, too, but staying 0 as 0, 7f as 7f, 80 as maximum negative and ff as minimum negative. So only notes with delay > 7f would jump one bar below. Of course the player would need to look ahead one line… Or something.

18

Hey Chris,

Maybe I am confused here again, but what if simply the values 00-7f represent positive ones, while 80-ff Negatives with ff== -1? Why offsetting the Values?

EDIT:

SO I CONCLUDE, BEST WAY?

OLD NU
C-4 C-4
--- ---
C-4 00 C-4 00
C-4 FF ---
--- C-4 FF
--- ---
C-4 7F C-4 7F
C-4 8F ---
--- C-4 8F
--- ---
C-4 20 C-4 20

Hi, sorry for the late reply. I’ve been traveling outside Scandinavia for once. :stuck_out_tongue:

Not sure if that would make any sense, lower values are expected to arrive before higher ones… Not?

19

+1

It seems natural for the note to be visually represented on the line being closest to where it is played. I once made a mockup where negative values were represented by red numbers and positive values by blue values (in this case, numbers above 7F would be blue and below would be red). Imho that would make it being more intuitively perceived.

Good point. But if color-coded it should be visually intuitive; One color for default and 60-7F and 81-90 are slightly different in color, while “very off” red - yes.

At first I was thinking this could be optional with a tick in the preferences, the pattern lines only being a rendition of how you want things represented. But then comes some problems to mind, regarding lua (line objects) and “live” usage leading to the conclusion that it has to be a new global standard.

And what happens if you play a pattern from start? Would any negative notes be ignored? I think they have to, or the implications will be that other usage scenarios will break.

I already covered this in the original post; the Renoise internal interpretation of how notes are layed out could still read it as it is now, while this suggestion is more of a aesthetical/visual approach. I believe some notes not being played during playback of only a pattern is a trade-off which many of us could live with.

The other approach is, like I also mentioned, to have it similar like the ms in the mixer; some kind of “re-calculation” when negative values are present and then also these notes will be taken into account. But… Maybe the previous one is easier to implement and may be more logical though.

Either way, yes, I would welcome this feature as an option although I don’t understand how someone could find the current layout intuitive in any way.

I like your ideas cmakris, and agree to some extent.

On topic. What about just having the default delay value a setting, just like the default velocity value box already available today? That would make some of us happy without disturbing those who won’t use it, no?

Can’t wrap my head around if it would somewhat be incompatible with the Renoise groove implementation, but otherwise I see no reason why not. Sure, it would not be 100% smooth when importing midi clips et c, but good enough.

attachicon.gifrns1.png

Well, why not. It’s more of a feature addition than a change alongside this suggestion though. Maybe these stuff, btw, would make more sense if they were under the pattern editor - along with the other track-column based stuff.

20

I think a negative delay, despite being a feature that seems somewhat natural/functional, does run contrary to deep tracker logic. Lines don’t look backward, only forward. It’s an aspect of the simplicity and elegance of tracker design. This being said, I totally agree that it would be nice to at least have a note’s placement on the pattern more accurately reflect its position in “rhythm space”, only I don’t think the default pattern view is the place for it. So, nobody freak out on me here, but you may have noticed that I’ve recently been proposing some piano roll or “roll view” designs in this thread:https://forum.renoise.com/t/brainstorming-piano-roll/12547

The reason I point to those designs is that the roll view could allow for delay-nudging of notes up and down, providing a more accurate visualization of their trigger times. Back in the default view, Renoise is setting the note placement and delay values for you. There you would see the tracker-brain version of the programmed rhythm, as it has always been. It would make for no changes in core/expected functionality.

In short, I think an alternate presentation view (still vertical, always vertical), one focused on visualizing melody and rhythm, could come with a surprising number of natural-fit benefits.

My suggestion is more of an idea to make the delay column make more sense, meaning only an improvement in the looks of an feature which is already implemented.

Your suggestion of a piano roll-hybrid on the other hand seems to bea completely other chapter, and - while I’m not against that (it looks interesting) - I have to ask in what way does my suggestion intrude to your vision? Maybe I just misunderstood your intention of linking to the piano-roll topic, but this “piano roll” looks rather like an complement to what there is now and doesn’t necessarily have so much to do with the delay-column.

Anyway, as a try to embrace your idea more into this topic and without making this topic too messy, I also have to ask in what way you set the delay-values in that additional editor? As I see it, It seems like you just drag the note-length with the mouse and it automatically snaps to the ticks? Maybe holding down CTRL could access the possibility to change the note-lengths more freely, while the hex-numbers of the delay-column would change in real-time as you drag? That would be cool.

21

Exactly, the values in the delay column would change in real time as you drag. As would the note’s trigger placement. So, if you held CTRL (or something) you could move a note (or more) up/down by step, rather than by line, giving you a very fine control of the note’s position + delay. I was beginning to think, also, that the melody/roll view could be an extension of the default pattern view for each track, instead of an alternate view, so that you could work in both at the same time, access data in both, see how changes in one affects the other, etc. (melody/roll view would be minimized by default to keep tensions down)

1 Like
22

I really vote for negative delay, whatever the implementation is ! And hope that, when recording in real time, the closest line will be chosen.

1 Like
23

Exactly, the values in the delay column would change in real time as you drag. As would the note’s trigger placement. So, if you held CTRL (or something) you could move a note (or more) up/down by step, rather than by line, giving you a very fine control of the note’s position + delay. I was beginning to think, also, that the melody/roll view could be an extension of the default pattern view for each track, instead of an alternate view, so that you could work in both at the same time, access data in both, see how changes in one affects the other, etc. (melody/roll view would be minimized by default to keep tensions down)

THIS! (and the “sample selection jam” are the best new renoise ideas right now)

24

Bump

1 Like
25

I was just going to make this exact suggestion, but Discourse helpfully informed me of the existing post (nice).

But now it warns me against bumping a topic that was made over 2 years ago… oh well, you can’t please everybody ^^

1 Like