Ok, I know this won’t fly because it probably breaks the underlying architecture and backwards compatability, but what about having delay offsets positively and negatively centered on the note? Why does this matter?
It makes more sense from a musical standpoint. The pulse of the beat is at the core of any rhythm, but the delay offsets as they are now have an asymmetric relationship to that. This will tend to “nudge” the composition process in ways that are not musical.
For example, if I’m adding some variation, I’ll tend to push things back more because that’s the bias of the interface, wherease musically it makes more sense to push and pull some things. In order to get positive offsets, you have to do a calculation, which is already an impediment… on top of that, it looks ugly - the note isn’t really where the note “logically is”. Nudging before a pattern (to say, fatten up a hit) requires going to the previous pattern, also not ideal.
May seem like nit-picking when “in theory you can accomplish” the same things, but I think these details add up to a more (or less) musical experience and also can strongly affect the way people write music in good and bad ways.
Well, we should then make the delay column decimal and the variable type for it an unsigned Byte.
It simply doesn’t change one bit yet to how the delay is used, but you get -127 and +127 values.
Also the engine should be changed to interpret the first 127 values as a negative position and the other half as a positive value.
The nasty thing here indeed is it breaks compatibility with old songs. So it would require a compatibility mode in the player engine.
So yes, this nitpicking has a huge effect on how older vs newer stuff should be handled under the hood.
It is not theory where you can accomplish the same thing, but in practice. You can drag the note back and add a higher delay value to it. In musical aspect, it may not be an optimal solution but relatively seen it doesn’t differ one bit.
You can nudge stuff up or down as precise as you desire through the nudge function in the advanced edit which exists to make this proces easier for you on that area.
I did suggest this when the Delay column was still in Beta but I really don’t think you’re going to see a change to it now! Would possibly be possible to create a scripted Tool that pretty much does this, by adding a Delay of 80h to everything and slightly shifting all Automation, but without it being native I can imagine it being quite a headache to work with.
If you use the Search feature you will see it’s been discussed before,
Played around with the nudge function before. It’s great, but it’s not something that you want to be doing all the time when editing. I kindof feel that way about a lot of the advanced menu functionality actually - all great things, but going over to the menu to enter in values and run them kindof slows down the flow.
Not really clear on the hex vs. decimal issue is, I don’t see what the difference would be other than making the subtraction easier to do (I don’t mind hex for the compactness of the representation).
Here’s a potential solution (playing off your nudging suggestion). How about next to the default/keyboard input volume (which is a great addition, btw) there’s a default delay offset option. Set it to 40 and we’re 80% of the way there functionality wise. You have to do a bit of subtraction, but at least the note is in the same row. The only other thing is the metronome, but maybe if there’s ever a metronome options menu, a delay offset could be incorporated there as well. Those things combined would probably capture 95% of this functionality/workflow.
But I agree with this and was brought up when the idea of the default velocity was introduced. I personally don’t see the hard for having one for each of the Vol, Pan and Delay values.
If I understand correctly, is what you’re looking for the same as what’s described here?
It sounds like you’re going for the same thing, but the above thread proposes a much better solution than per-sample +/- delay, though probably harder to implement. The “snap-to-beat point” method would be tempo-independent; sample delay in milliseconds would not. It’s one of the last features I’ve really wanted for years that hasn’t yet been put into Renoise (I’ve gotten pretty much all the other stuff I want, hee).
It seems like a realistic wish now that we have sample autoseek. It’s kinda like a reverse autoseek. I’m thinking of making a thread with some good mockups so it’s really clear why it’s a superior idea. All the old mockups are 404’d.
Not exactly, I would say the snap-to-beat point functionality is actually subsumed by a good implementation of delay/timing offsets.
What’s described there is useful for things like shakers with long attacks and getting their hits to play in-time correctly, but nudging notes dominates that functionality- you don’t necessarily want to shift every hit in the exact same way (which is what the snap-to-beat point would accomplish). You may want hits to be early or late depending on both the properties of the sample (which is what the other suggested addressed) as well as the feel of the timing.
You can already do this with delays, but for the reasons I mentioned, the current impelementation is not a good model for the underlying musical concept - which should be symmetric about the beat. Generally speaking, I don’t want renoise to copy other sequencers, but if you look at flstudio or geist, the delay offset works in this symmetric fashion because that’s the mental model for the musical idea.
From what everyone has suggested, I think a path-of-least-resistance would simply be a default delay +metronome option to match the delay. That would capture 99% of the functionality without requiring a fundamental overhaul in the architecture. So maybe my initial characterization of the change as being crazy was wrong
The original images are gone from that thread, but if they were still there you could see that the feature was meant to be a visual thing. The “peak” point would be selected the same way sample slices and loop points are. So that’s one thing that would be different – if I’m not misunderstanding again. Which I could be. I should stop posting when I’m so tired.
This thread is about having each Line in a Pattern with a Delay value default of 80h, so that for a slight negative Delay you still see the note as being on the Line it is closet to, rather than sitting on the Line earlier with a high Delay value.
The other thread is about being able to play samples so they get to the hit point where the marker is set but may have actually started playing quite a while before that.
It’s crazy to fix design flaws with half-assed solutions. Think of Windows (before 7 that is). So what if it breaks the compatibility? One should then stick to latter version for old songs, or the devs should code converter and learn to plan their programming better in the future. If that fixes 99% of the functionality, 1% people are going to be pissed off. After hudred times everyone has been pissed off once. Think of that.
Altho latter can be achieved via the first if the functionality is provided.
No it can’t no more so that it can be done now with some careful work (IE viewing your waveform and manually working out how much early to trigger it each time.) Having the lines centre in a different place are not going to make any difference to the fact a sample starts playing from the beginning where it is entered in a track.
Why? If there is practical solution for negative or pseudo-negative delays, functioning the same, why wouldn’t it be possible to add a marker to sample and have the program calculate default negative delay for the sample, or instrument, to match the marked sample position to a line position a note is entered in when playing the song?
This suggestion provides a prerequisite for easily implementing the other, as you see.
I don’t see the two as being related really. One is in related to samples, one is in relation to pattern lines.
The only difference between the existing Delay mode and the proposed on comes in how it is displayed on the screen! IE all delay values would be different, anything with a delay of 80-FF would be shifted forwards a line and have a delay of < 0x80, all lower delay value would be kept on the same line and have 0x80 added to their delay value. This does bring in problems of how Renoise handles Note Offs as you may get note lengths that can be represented in one method and not the other, hence it makes more sense for a song to always be in one format or another, rather than the xml always be the same and only displayed differently. This then opens a whole can of worms for any Tools have to support two different modes and work flawlessly.
Whereas for the Hit Markers (or whatever you wish to call them) Renoise needs a Look Ahead mode for samples! It needs to know the Song Data has an entry point further ahead, even if it’s in a different pattern, and start playing the sample at the correct time before then, taking into account if a pattern is looping, tempo and pitch changes etc. We have Look Back for Autoseek on play start and some rudimentary Look Ahead for Automation so already some routines that do point in the direction though…
As you can hopefully see the two so not really share any prerequisites at all as far as I can see!
Oh, I see. It can’t be done with negative delays, because for example if someone uses like 800bpm with 64 lines per beat, it would be impossible to offset the sample with line delays, so it needs to be independent feature. Yup, you are correct.
