Fr/Idea: Negative Values To Delay Column

Often when making drum patterns or some orchestral stuff I like to put notes slightly off, or in case the transient is not in the beginning of sound (like in case of some staccato strings) I want to trigger it just slightly before everything else on the same tick. It’s very unintuitive to trigger the sound in previous tick and then add almost full tick of delay to it.

Negative values in delay column would make the delay column much better. Doesn’t even have to add delay to the whole song. Only case where delay is needed is when you start playing a pattern and first tick has negative delay and I guess it wouldn’t be too hard to handle special case like this with one tick of delay in the beginning.

Would also make delay column humanizing much more sensible!

1 Like

Yes. This would be a very useful feature.
I’m not sure it can make it into 2.7 though…

It was also discussed here.

You can create a neg delay on the trackdelay in the mixer. Give it a neg value and then humanize with pattern fx

Yep, I’ve tried this couple of times, but it has several problems:

  1. you can’t set track delay in subticks, only in milliseconds
  2. default note delay is still 0

This approach could actually solve these problems, if one could set track delay to be 127 subticks (= 1/2 ticks) and default note delay value of track to 127. The result would be that every note inserted with computer keyboard or played with quantize on would have 127 subticks of delay and values 0-126 could be used as negative delay and 128-255 positive.

I always use timing by ear, so I don’t need to know exacly whats going on…

Did think about this and think bring it up for discussion when Delay was first introduced but doubt we’d be likely to see the whole Delay column changed now and think that would likely actually confuse more people than it would help…

+1 for this feature.

+1

Here is a suggestion that might be relevant to this, on many occations. At least when using samples. Note Align (Sample Hit Point)

There is no negative delay… ever driven forward in a car with -50mph?

What has that got to do with anything whatsoever!? You have negative Track Delays. The idea of negative delay is in no way alien!

That you can set a negative track delay is because Renoise can be told to shift the audio streams of each tracks differently before outputting. You are actually not asking renoise to play that particular track earlier, but you are asking Renoise to play all the other tracks later.
The same processing method does not go for individual note processing of that track.

Okay just let me add my 2 cents,
AFAICS there are 2 problems that has to be overcome to solve this puzzle:
The whole pattern processing structure is based upon event passing, so what comes first is treated first. A note that is being read that suddenly has to be sounded 10msecs back, that can not happen the way Renoise processes track contents now. Renoise can’t do time travelling.
So in order to be capable of allowing negative note-delays, Renoise has to buffer each line for processing and then figure out in the next line if it has to cut the note of the current line earlier and start the note of the next line somewhere further in this current line.

The second problem is the 256 value limitation and the Hexadecimal translation of the delay column. If you want negative note delays, how would these 256 values be divided? -128 to +128? You can’t do overlaps, each note must have a 256 point space on the line → Try to convince Renoise to allow it to initiate a note to play at position 200 on the current line while on the next line you tell Renoise to start the note -60 positions back that would be position 196 on the same current line. And why should we explain to the novice user that the 00-7F range is used to shift a note-delay from 0 to 128 and that the 80-FF range is used to shift a note from 0 to -128?
And how should this stuff be recorded into the pattern when recording with note-delays?

Some questions are for the developer to solve but some solutions doesn’t make things easier for the user either.

The only way I could see to do it would have been to have 80h as the default, rather than 00, with less than 80 being negative, more than 80 being positive delays. This still is processed line by line, there is no real negative delay, just your default position has changed from zero to the mid point of the line.

I think it’s probably too late to incorporate something like this now anyway, would of had to be done when Delay column was first introduced, and I can see the mid point being default being confusing to some of the less technically minded too. Unfortunately for people who want it, having a script to make 80h the new default will make lots of other things act strange, such as LFO triggers not being on the beat, scripts not working correctly and probably much more. I don’t really see how to bring it into the already existing stream (unless you could somehow tell the column it was behaving negative, and remember what you see on the screen in just a representation of the data, Renoise could still treat it as being played on the line below with a positive delay.

In fact, having an option to have current 0-FF delay, or 0-80-FF delay in Preferences, with the only differences being what you see on screen with the XML remaining the same, may be possible but possibly a pain to code and adding unnecessary CPU cycles as every single note will have to be transcoded from one display method to another (maybe not much difference though…)

This idea of “Renoise can not handle negative delays” is also destructive to the very good idea of sample cue points, where you set a point where you sample will have played to where you enter the note but it will actually start at an earlier point, as has been suggested again within last couple of days in this thread Note Align (Sample Hit Point) at the end of the day it’s all about how data is shown on the screen, having a sample played 3 lines at 77delay segments earlier than you see the note can not take Renoise more processing to adjust the visual representation than enabling Autoseek on a sample does!

What one can do with a script is the following:

  • create an algorithm that shifts delayvalues back and forwards (for the note AND its corresponding note-off value!)
    If delay turns negative, then look to the previous line (either in current pattern or in previous pattern of sequence),
  • is a note present in the current column?
    -add column and shift note one row up to the extra column, including the note off value.
    -Cut note in previous column at starting delay point of next note.
    -If no note is present, shift note up one row (including the noteoff)
    -subtract the delay value from FF and add delay value (FF- shifted value) to the delay column behind the note (and corresponding note-off value)
    If delay turns positive over FF, then look to the next line (either in current pattern or in next pattern of sequence),
    - is a note present in the current column?
    -add column and shift note one row down to the extra column, including the note-off value
    -If no note is present, shift note up down row (including the noteoff)
    -add the delay value to the delay column behind the note (and corresponding note-off value)

I have no idea what to do with notes that were originally on the row where the new note shifted too. (should a note-cut be applied somewhere?)
Or perhaps it should be destructive? (overwrite previous or next notes in colum)

Bind key-shortcuts to these algorithms and you have a note fine-shifter.

There is also the problem of notes on line1 that would need a negative delay. And any scripts that insert data would then need the adjusting script running on top of those parts afterwards…

personally I’m not too bothered about it, was putting it forwards as ideas and showing not a totally impossible task in the main.

I don’t feel like elaborating, but I pretty much agree with vV.

I don’t think this is a good idea. In my opinion it just makes everything more inconvinient and convoluted…

I don’t see the problem here.
Musically it makes every sense in the world to have this.

without with neg delay  
  
00 --- -- --- --  
01 C-4 FA --- --  
02 --- -- C-4 -06  
03 --- -- --- --  
04 --- -- --- --  
05 C-4 EF --- --  
06 --- -- C-4 -11  
07 --- -- --- --  
08 C-4 04 C-4 04  
  

You can see the actual rhythm involved in the latter…

As how to do this technically should really not be our concern.
It’s doable.
As for the GUI there could just actually just be “-” representing the negative delay.
Other options are different color for negative delays to save space, where pressing “-” could switch the delay to negative values (changing the color).

i guess offset would be a better term for it.

Hmm didn’t think of implementin it in that way particularly. I don’t think think the feature is that crucial but implementing it that way could work.

You forget something:

  
  
00 --- --  
01 C-4 D0  
02 C-4 -40  
03 --- --  
04 --- --  
05 C-4 E0  
06 C-4 -20  
07 --- --  
08 C-4 04  
  

The above situation contains overlaps.
Being able to enter negative figures still does not mean that you can overlap.
So this would most likely only fix the problem for users not understanding positive hexadecimal ranges used for negative delay, but it still renders values above 7F useless in the track delay column.
Plus you can only delay negatively to 50%, if you need to delay more, you need to put the note back on the previous line anyway and if there is a note, you would have to put it in a secondary column anyway.
The solution most likely wouldn’t go as far as you would like it.