Delay Column; Change default to 80(hex)?

Ideas & suggestions
1

As we all know humanizing note-timing is not really usable since the notes will never receive a negative value and appear before the “initial lines”.

In the current layout you have to do the slightly off-timing manually to get the desired result, unless you want to fiddle with the ms stuff in the mixer view (which doesn’t give you the same control of the whole thing anyway).

So, the idea I have is to simply change the default value of the delay-column from 00 to 80, which will leave room for negative values instead of moving the actual note from its ”initial groove”. It’s not a intiutive way to work, or have I missed something here?

With this idea in mind, the composition containing humanizing will start looking more sense as notes now are on the lines where they are closest to (”the intended lines”) which shows the groove visually. In turn this will be more comfortable musically, for further editing purposes etc.

Also the Pattern Matrix will look more “correct” and be smoother to work with. Presumed the slightly off-beat timing starts before the beat, in the current setup you have to copy a whole block [from the pattern before] while the rest of the track in the block may as well be just empty.

There’s just one thing that may confuse and that’s Play Current Pattern; the humanized notes are on the first line on the actual pattern being played, but from the Renoise pow those may be in the previous pattern and therefor not being audible. But I’m sure many of us could live with that.

However, with that said, yet the ms adjustments in the mixer is able to ”rethink” automatically with the pre delay in account so perhaps even that could be fixed with this approach too?

I believe this could be backward-compatible as well, since this suggestion is more of an aesthetic adjustment; The line-placements of the notes and the numbers may have changed upon loading an older project, but not the actual timing of how Renoise interpretate the stuff.

I may have overlooked something, but am I on to something here?

(Similar stuff/thoughts have been brought up on the Forum before in some older topics etc, but I guess I could start a new one.)

Edit, 2015-09-20: I inserted some pictures, which would you prefer to work with? :slight_smile:

Current My suggestion

2lke0iw.png 212tkc8.png

nqzgxw.png 2zxy33n.png

2

Hey, today I also thought about this, only adding a 1xx for negative, but your idea seem to be better. It would loose precision while conversion though.

3

Ive never realized that “humanization” is wrong! Thank you.

The question is: Does the swing slider in Redux (and 3.1) do negative delay?

4

Hey, today I also thought about this, only adding a 1xx for negative, but your idea seem to be better. It would loose precision while conversion though.

Thanks.

What do you mean by conversion? I just posted a picture in the original post, which I believe will demonstrate the idea better.

Ive never realized that “humanization” is wrong! Thank you.

The question is: Does the swing slider in Redux (and 3.1) do negative delay?

Thank you.

I have no clue, haven’t got the time to use that one yet.

5

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.

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.