I’ve been looking at the XML for the last 30 minutes. The first 29 I had the wrong approach (represent two instances of the same data) but the last minute I got the little lightbulb. Behold the glory of a man trolling himself into answering his own problems!
Could I get an explanation of how this is supposed to work? I’m assuming that it isn’t supposed to hold the negative delay value, since if Renoise is reading the pattern data line by line, it would have to go back in time to play the note at the time specified by the parameter.
I know nothing about the Renoise XML format, and I don’t have the time to look into it right this moment, so bear with me.
Well, all of this is conjecture, of course. I don’t know how Renoise works internally. I’m more concerned with PHP scripts that manipulate the actual data. I didn’t want some ugly ass “double version of everything, conflicting XML nodes on top of each other” but the idea here is as follows:
Renoise pattern XML represents the pattern data, just like Open Office XML represents a document.
could represent actual time (SMPTE, MTC, offset in milliseconds, whatever)
I have no idea if this is feasible from Renoise POV, but from the XML pov it’s not horrible.
PS: If you want to see some Renoise XML, just press CTRL-C in Renoise and CTRL-V in a text editor.
Wouldn’t negative delay values would simply be expressed as, well, negative delay values in the XML:
<delay>-02</delay>
Thats also how we could enter them into Renoises patterm editor.
I often also stumbled upon this when fiddling around with a notes delay. That you have to copy & paste a note and add a positive delay again to lay it back feels just wrong & uncomfortable.
Of course negative delays are redundant, but they are still comfortable, so what.
Indeed. This is the most cumbersome part of the pattern editor I think. Try record some midi live and you see a mess of things.
So redundant yes, but far more userfriendly.
Less to type when you do quick adjustments. And more important it makes more visual/musically sense.
And the best part, it is fully optional. So I can’t see why we should not try this out.
Of course the alternative painkillers for this are optional unquantified views like the Aodix pattern editor, or a Pianoroll.
For larger negative delay of notes (to among other things make the pattern boundaries crossing more flexible) there could be a new command as well to set the note x Lines back.
Then perhaps this negative delayed note should also be visible where it actually will be triggered (if there is nothing else on that line you could see the note dimmed or something…).
an interesting option when recording live could be a negative value treshold: if threshold is for example C0, if a note gets triggered with a note delay D0, it will shifted to the next row with a negative delay value of 20.
The engine can handle this without a total rewrite? How would the following work.
C-5 00 .. .. FF
C-5 01 .. .. -10
C-5 02 .. .. -FF
Where F0, -10 and -FF are delays respectively. Which note gets triggered? How many rows does can Renoise look ahead and still maintain it’s “next note cuts the previous” paradigm, so to speak?
The idea with is that it allows future enhancements to the pattern editor. Right now all the calculations are done based on note position (well, maybe not, but that’s how it’s represented in the XML) shifting those to Timecode and representing it via actual time may be something for the long term?
Since I created the thread I thought I would clarify what I was thinking:
If a note has a long delay, it’s actually closer to the next line in the pattern editor.
Rw | Note | Dly
00 | c5 | 00
01 | … | …
02 | c5 | ff <-- This note is actually much closer to line 03. Better to place on 03 with a negative dely.
03 | … | …
To me it makes more musical sense and is easier to work with. Going back in time by 2 or 3 seconds, I’m not against it, but may make it harder because several other notes could appear “inbetween”? For me this option is more about making sense musically when looking at the pattern editor.
Picture a note with no delay as being the center point on a horizontal slider. Slide it to the left and it’s a negative delay. Slide it to the right and it’s a positive delay. Slide all the way to the left and it’s as close as you can get to the previous pattern row except with one tick of delay (or whatever you call it). Slide it all the way to the right and it’s similar to the maximum current delay on a line as currently exists in the pattern editor.
The reason I’m saying “picture a slider” is not that I’m expecting an actual slider - it was how I was thinking about the problem when I came up with the idea for negative delay.
Yes, yes and yes! It’s really difficult to work with short notes (with a duration less than one line) in Renoise. Especially if the notes are triggered somewhere between lines.
Say I trigger a note a note with delay 80 and want it to stop quickly, e.g. at delay 90, with an off command. There’s no way to do that. With negative delays, that would be possible.