+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.
Maybe I’m missing something, but I still don’t see the big problem here 
Yes this means you can make overlapping/colliding notes.
You can already do that now btw:
00 C-4 FF 0D05 01 E-4 -- ----
One more simple “real world” usage of negative delay:
Some simple hihats you wanna humanize:
without negative delay the result look like this:
00 C-4 03
01 C-4 E9
02 --- --
03 --- --
04 C-4 02
05 C-4 F4
06 --- --
07 C-4 FE
08 --- --
09 C-4 F6
10 --- --
11 --- --
12 C-4 03
Hard to tell what kind of hihat rhythm that is…
On the other hand it’s crystal clear when you see this with negative delays:
00 C-4 03
01 --- --
02 C-4 -07
03 --- --
04 C-4 02
05 --- --
06 C-4 -0B
07 --- --
08 C-4 -02
09 --- --
10 C-4 -09
11 --- --
12 C-4 03
I’m not sure what you meant about the 50% thing? Why can’t you negative delay more then 50%?
The only thing I can see we need for this is a setting for live recording where you determine the threshold for when notes should be recorded with negative delay or positive delay.
When you record chords etc you also get the notes spread on different lines, while you musically meant them to be shown as a notes side by side on the same line. Again negative delay would be great.
I also always wanted that start offset as someone suggested in the sample editor. Sometimes you wanna start a sample many lines before where you enter the note. Often resulting in that it should start in the end of previous pattern.
This is a constant problem with the pattern system. You change a pattern, and suddenly you have shaved off all the samples that have a slower attack starting in the previous pattern. Negative triggering of samples would help a lot in these cases.
(((Even a new pattern command delaying a note several lines before (negative and positive) could be useful.
For instance 0Dxy could be used for this:
D00 to D0F delay ticks.
D10 to D1F delay up to 15 lines positive.
D20 ti D2F delay up to 15 lines negative.
You need more lines, then duplicate fx, or we could split the entire D10-DFF range into larger positive/negative quantities, but before we do that we really do realize we need to redesign all the pattern commands before making more voodoo pattern command stuff…)))
If it for some reason confuses you , then don’t use negative delays in the first place…
IMO it just makes more musical sense to have the note stored in the “correct” pattern with negative delay (sample trigger), then to store it in the previous pattern that you might change later on. No more notes suddenly disappearing, or hacking in notes to patterns they really do not belong to.
We already can calculate/buffer sample seek, and automation etc. I’m sure we could do something with negative sample triggering as well…
For the recording it won’t matter much indeed, i was aiming towards NNA treatment as a confusional matter, how would NNA have to deal with overlaps?
It would logically swap the notes during the process but visually that is very confusing.
Considering delay values going back a lot of lines this is even more confusing.
The only reason i would somehow consider the use of a function like that is when i don’t want to create an extra notecolumn to have a specific note being initiated somewhere on the same line as another.
But that would make me lazy and after a while it would make songs hard to interpret if you have to edit these again (even if you know what you are doing).
So you can make your stuff messy with these kind of solutions, that does not necessarily mean everybody will do that, but if one doesn’t know what one is doing in Renoise in the first place, one shouldn’t touch that stuff at all 
It is already very easy to come across situations where this will happen and having the Delay of a line offset back by half a line does not make it any more or less to happen under any circumstances!
If you are talking more about converting current projects the only way I could see to really do it would be to use Note Cut command, but again that is still not different to current if you want a note of less than a line in length (unless it is only less than a line as it is played delayed and Note Off is on the next line.)
I totally second that.
It would make MIDI recording much more efficient.
Given the difficulties of displaying the values in the delay column I think the least bad solution is to give Renoise a new column with the name “Advance”. The position of the note would be calculated with delayvalue-advancevalue. Note cutoffs et c should be handled just the way they would be if the notes were entered in the same way they are being played.
If a new column is too obtrusive, an alternative is to have some kind of toggle as a pattern effect command to make the delaycolumn behave as a negative. Personally I think an advance feature is so elementary and important that it justifies a new column.
Also more food for confusion though, another column with positive values.
The best solution would simply be adding a minus sign for any value till 7f. This however would mean that the delay column won’t go further than from 00 to 7F and 00 to -7F.
This is technically very illogical to program a placing algorithm for, because above 7F the note should be placed on the next row with a minus value while on playing level: the note should be played as if it had a delay-value above 7F and was placed on the former line. This is really crap to maintain and debug, not even speaking about how all the other routines regarding delay effects etc. should be adapted to house this behavior.
I personally, don’t mind the current manner of used delay and for me this kind of suggestion is a luxury problem.
Another thing is:For me personally a delay can never be negative because the word “delay” doesn’t mean “back into time” at all.
I guess this sums your opinion. Some people find this elementary and some don’t. The mission for the former group is to suggest a solution that is transparent enough not to be confusing or obtrusive, and for the devs to understand the importance of the feature of course 
Another suggestion in line with this reasoning:
- Make the data variable signed, meaning it can be +127 to -128.
- Make a keyboard shortcut for the user to toggle the delay mode between - and + on a particular line.
- Rename the column from “delay” to “delay/advance” - Dly/Adv.
- Give advance values/mode a different color than delay values/mode.
Tools or native shortcuts can be made to make the user interaction intuitive - and it’s invisible to people not needing it.