A quick feedback - ever since the sub tick timing (which was the feature I’d been waiting for), I’ve been wrapping my brain around the advanced timing. It’s a bit of a pain to use in some ways and had a thought that I would personally find useful.
When it comes to looser or more natural timing, it means that notes may be entered slightly early or slightly late. Whenver it’s a slightly early note, it forces the note onto the previous line of the pattern. Often the first note of a bar at the beggining of a pattern is actually being triggered from the last note of the previous pattern. It makes it “look” wrong because of the first note starting on the last line of the previous pattern, and it’s a pain in the butt to work with.
I was wondering if it would be possible to use a negative delay value on notes so that I don’t need to see the note data one line previous in the pattern editor. It’s visually misleading because it’s not “really” when that note is being played.
I realize this may be solved with the zoom feature, but thought a negative delay value would/could be a good option?
This would make it easier when working with early notes as the first note in a pattern. Am also wondering if there will be something more user friendly than hex with regards to delay values once the zoom comes in?
Both this sounded like a complaint- it’s not, I love the advanced timing, I know the interface needs to be improved and is being worked on, just a thought for now.
Yet another idea I thought of about 4 days ago. Does everyone have a direct link to my brain or something? In any case, it must be an awesome idea, since I thought of it too
Your reason for wanting it however is not quite the same as mine. I would like it because then one could delay a note for (say) a third of a line, but have the next note in (say) the 2nd third of that line. This way you can squeeze two notes close to each other - something quite impossible usually.
Twinbee - I believe IT Alien is right, you could just add a new column. (Although yes it would be clean to do it in one).
It Alian - you do a lot of classical, with I’m assuming loose timing on the instruments. Would you not find it convenient to be able to put your notes on the proper row (for example the first row, without having to scroll back to the end of the previous pattern?)?
I’m suprised more people don’t find this frustrating. Maybe they tend to make the first note in a pattern right on without any delay. Or maybe they just don’t find it frustrating like I do?
the concept of negative delay values is indeed fascinating, but I think that it would introduce the need for a read-ahead in the engine, which may cause more latency. Of course, if such read-ahead is already implemented, it would change nothing.
regarding classical: it’s very rare that I use single column tracks, that’s why I don’t feel the need for such a feature; your assertion that a classical composer should feel this need contrasts with the fact that more complex music is much more likely to be made using multiple columns. In particular, though, the case of the first row is the only one in which I indeed desired such kind of feature, but it would not be worth the increased latency.
Renoise could also insert the “actual note” earlier? How the song internally looks and how it is represented on the screen just needs to be decoupled. This is kinda similar to the discussion of being being able to set the sample point start well into the sample.
Then what do you do about negative delay values at the beginning of a line? Ignore them? You have to compensate somehow, so either you push everything forward by the max negative delay or you start running into weird issues.
I mean, I guess it could be done, but it seems a bit messy and unnecessary. I don’t really understand why it’s useful. A delay of -40 on one line is C0 on the last. It seems to me that if you have trouble with small scale addition and subtraction, tracking is probably not for you.
Then again, maybe I’m just being small minded. I’m all for features that make people’s lives easier, but a built-in calculator seems like it would be a neater solution than this.
@Phate:
The problem is not just aesthetic. When you start to shuffle patterns around in the pattern arranger, then you suddenly miss notes because they are put in the end of previous pattern. Even if they should belong to the next pattern. This is kinda irritating.
This problem is also discussed a bit in the large arranger thread. This is because clips will also have this problem with pattern boundaries.
I don’t think that I am quite catching your meaning. When exactly are you shuffling patterns around enough for this to be problem? I don’t really understand why notes from a previous pattern should be in another pattern.
I’ma go check out the thread you mentioned and see if I can’t figure out what you mean.
It’s not complicated. It’s just that many samples/instruments have a slow attack for instance (could be anything from a few milliseconds to several seconds). Then you often wanna trigger these notes slightly ahead of the beat. So the notes on the beginning of the pattern have to be placed on the end of the previous pattern to get the timing right. If you then replace either of the patterns you will have extra notes you do not want, or you will be missing some notes.
In other words. Some notes can belong to another pattern musically. But you have to place them in the ‘wrong’ pattern to get the timing right.
Ahh. That makes sense. Wouldn’t it be more intuitive to be able to do track-specific forward and backward delay automated by a single parameter per track, where backward delay literally just pushes all the other tracks forward in time relative to that track? That way Renoise would run with no added latency by default, but you would have the option of delaying the tracks you wanted.
I know there are DAWs that allow for this, and it would eliminate the need for placing notes in a previous pattern at all. In fact, I’d probably use it a whole lot.
Actually, damn. I suppose that you could just not delay the tracks at all unless there are negative values, but it seems like having one parameter to delay everything in that track would be a neater solution.
Maybe a global variable to control the maximum backwards delay?
Just some thoughts. Sorry for the unhelpful comments earlier, I didn’t quite understand what you all were getting at.
For small adjustments you can already do this in renoise (up to ±100ms). This is however a ‘PDC’ feature which means that the actual audiostream is compensated. For anything larger then this you will get so much latency that that you should instead offset the notes rather then the audiostream. And this is where the negative delay or some other solution could be useful.
Even if you will not hear the notes with negative delay on first line when you play the pattern (because they will be triggered on the previous pattern), they will at least ‘belong’ to the correct pattern.
Then there are other solutions like precashe/freeze/streaming that could help us out in this situation. But then we are more into clips and how that could be integrated into the current pattern system as well.
That’s rather cool. Actually, you would never ever have negative values on the first pattern line if you were using negative delay for that reason, so there shouldn’t be any perceivable latency issues caused by pattern delay used this way. Renoise would and should just ignore any notes set to play before the start of the song.
A consideration to take into account is that there would have to be an adjustable limit as to how far back you could set a note, since Renoise would have to process larger chunks of pattern data per line, and parsing the whole song’s worth of pattern data after the current line would be ridiculously inefficient.
Nope. No need for that. Instead: When you put a sample with a negative delay of one second at line 0 of pattern 0, that just means that line 0 of pattern 0 is at 0:01, instead of always 0:00 like it is now.
That’s what It-Alien might have meant when I said that adds latency. I replied “no, not necessarily”, but you apparently didn’t get that. I wasn’t very clear to be honest, so let’s try again…
When you enter a note at 0:10 with a negative delay of 2 seconds, Renoise would “write it down internally” as being at 0:08 - but the note would get display like you entered, at 0:10 with the negative delay of 2 seconds.
The same would apply to the ability to set the sample start into the sample: There’d be NO latency, not a SINGLE CPU cycle more would be required - because these (trivial) calculations are made when you EDIT the pattern, and then they are written - they don’t have to be recalculated everytime you play the song, they just get read, just like the notes get read now.
For me it is more for asthetic reasons - but they are very legitimate asthetic reasons.
My bar of music is not actually starting on the previous sheet of music - however because of the way the delay column works it looks that way – if the note is entered with an early delay. I wouldn’t expect tons of early delay - just the same amount of “negative” delay as currently exists for “positive” delay.
Also, If you think of these 3 lines here:
row note delay
64 C5 ff
00 …
01 …
That note is actually much “closer” to row 00 (where in this case it was really meant to be played) but still appears on row 64. Thus, I think it is a useful request if it wouldn’t require a lot of under the hood tinkering. I think that once there is a zoom feature, a slider both forward and backward with negative and positive values would make sense, perhaps with snapping to musically useful values. Anyway, now I’m getting the thread confusing by talking about two thing at once so I’ll leave it there!
As Renoise is XML, please propose a way to “write this down internally, yet display normally” using the available open format and have it not be a total cluster fuck, or taking twice as long to process, and twice the amount of space to store?
Just because you think it out loud and say it with feeling, doesn’t make it true.
The elegance of the pattern editor is that each line is a trigger. That’s how the XML is represented. It doesn’t make any sense to go against this concept.
If I look at Garageband and I want to shift the notes, well that’s exactly what I do. I move notes. There’s no negative values in there. There’s just notes, represented as little lines that I can move around, shifted back. That’s the interface provided, and that’s the interface I use.
Renoise’s pattern editor’s limitations are in the interface, not in the data representation. Ruining the pattern data (and subsequently the underlying and self-explanatory XML that 3rd parties manipulate) to be overly complicated in order introduce negative values is a bad idea IMHO.
The more realistic solution is to introduce another interface that allows you to “nudge” stuff, i.e. the “Arranger”.
Of course, it could very well be true, and maybe even easy, but this is one of these things were you should put a bit more effort into proving your point because, well, you can. On another note, I started working on your “Chop Up Long Samples” script idea the other night then thought to myself “Why doesn’t Johan do it?” and have stopped until I see some initiative from the original poster, king of the armchair.
You could do it that way, but I imagine that it would do very bad things to the XRNS format. Then again, I would need to read up on the specification first.
Do you know that this can be done without reworking the structure of the song format?
