When I trigger a gainer on an FX channel by LFO from the send track adjustments of the send track’s track delay have no effect on the gainer. So I assume the delay only affects the audio signal then, but not the timing of DSPs and Meta Devices within the DSP chain. A bug to me.
Cheers,
-BA
Understand that this would be nice, but meta device timing is bound to the automation timing (parameter changes), so we’d also have to shift all automation (pattern FX, graphical automaiton & stuff) with the track delay. This is not really what one would expect IMHO.
I think that’s exactly what one would expect, because when I set a track delay I want the audio signal and everything else related to it to be delayed, too. Usually you sync these things to each other. What ATM happens is, we put the audio signal out of the “normal” sync, but leave the Meta Devices in their origin sync. Not logical in any way.
For example when I try to affect short samples like a shaker or closed hihat ATM the sample is already over when the Meta Device kicks in or vice versa. To me that’s definitely a bug. While I can imagine it’s not going to be easy to get this under control.
Oh, and btw. … I don’t think it would be necessary to modify anything for the pattern FX, automation and everything else. I’d think everything should be left like it is ATM, except the timing itself. I’d think dynamic track delay would be a propper solution, just while replaying the track and without doing any changes on the origin timing for display and stuff.
In some way i think you are indeed right, it is hard to sync automation and effect parameters if the incoming audio signal it is based on is shifted partially which is not programmable or correctable in automation or devices because you cannot always shift automation as much precise as the delay of the track is shifted.
I have also thought about being able to manually shift the delay in an instrument (For midi and VST plugin) as a manual delay compensation option if the PDC does not work because the Delay is not broadcasted by the plugin. On top of it, manual delay compensation inside effect devices itself and shift the instrument in sequence with the track, that might resolve the problem better, but it would somehow make track time shifting a bit obsolete.
I don’t think that’s the case. For compensation of latencies you might be right. But I use the (negative) track delay for example as a groove element, to set things like claps, snares and stuff out of sync and achieve a kinda drive or feeling this way. For house tracks for example you usually kick in the claps some milliseconds before the bassdrum, which makes it sound a kinda slappy.
I came across this problem, when I was trying to create a shaker sound with a noise generator and some filters and LFOs. Everything worked like expected, just the (negative) track delay didn’t. What I was going to do was to put some milliseconds of the shaker’s attack phase into the negative track delay, so the shaker would reach its maximum volume nearly right on the synced tick. But… as we meanwhile know this doesn’t work because the LFO stays with its origin and fixed sync. So now the attack phase still keeps starting with the tick from the beginning and therefore sounds like kickin’ in too late. And adjusting the track delay has absolutely no effect on it. I doubt anyone would expect this, using the track delay. Actually it’s not a track delay at all, but just a DSP-chain independent “signal in”-delay (without too much serious use).
You know that you can reset the LFO from a different offset through the pattern effect commands and at a more precise interval than for instance the automation points so with the LFO you might be able to do a little correction. With automation this is harder because you can’t configure that tick-precise.
Yeah, I know I can set an offset. But I don’t want to cut the attack, because this would change the whole characteristics of the instrument. I just want to move it. And I don’t want to be precisely, because being unprecisely for some milliseconds is what makes a groove sound naturally.
When a door is built too low and people can’t get through it, it’s not the most logical solution to leave the door like it is and cut peoples legs before they try to go through it, right!? 
So you admit yourself your request comes from mis-using a function and when used for it’s intended purpose it works perfectly.
As Renoise currently works through Tracks, from left to right, line by line adding sub-line devisions would require a complete redesign. Currently you can only route Meta-Devices to Tracks further to the right as they are processed (very slightly) afterwards. If a track to the right had a couple of ticks negative delay for Automation etc etc then it would no longer want to be processed in order, breaking the current routing capabilities of Renoise.
Sure something like this would be nice but until we get sub-line automation capabilities of Renoise I can not see how it can really happen. Unfortunately you are using a feature in a way it is not intended to be used, so how you feel this should be under Bugs, rather than Requests, I am really not sure.
As has been pointed out LFOs can work at sub-line resolution so, with some extra work, you should be able to use them as a work around. May take a little trial and error but I can’t see why it wouldn’t be possible to achieve anything you want/have described.
Erm, wut? “Mis-use”? 
I want to use a track delay as track delay, not as a “only some parts of the track”-delay and that’s a mis-use? 
I start wondering what is the use of a track delay if not to delay the whole track? And what is the intended purpose then and the reason why it’s called “track delay”?
The most logical thing is, when I delay some part of a chain, everything else routed behind it has to be delayed in the same way, too. That’s a most logical matter of how a chain works.
You know, I came across this while working on a huge Renoise tutorial for a well known demoscene disk mag. Actually this tutorial would have been about some music style, realized with Renoise only. Meanwhile it’s more a collection of work arounds that take 2/3 of the tutorial. Do you want me to tell in the tutorial “The track delay doesn’t work as a track delay and expecting it to work as a such would be a mis-use. May take a little trial and error but I can’t see why it wouldn’t be possible”? I don’t think so…
I guess you get the idea I already tried to find some acceptable solution. Otherwise I’d think you read me for the first time. There is no acceptable solution. And it’s still a bug.
Before this tread goes berserk: I can’t foresee the implication of a delayed automation here with the metas, this is damn complex. So let me test a bit with this to see if that’s what we want or not. OK?
Nah, nothing about to go berserk here. 
Don’t get me wrong, Taktik. There’s no need to change this “within a day” and I’m able to imagine how hard it’s going to be to make it work the expected way. So, there’s no need to hurry and to know you’re working on it would be more than satisfying. Maybe this could even be a chance for a huge next step in Renoise’s evolution. I remember I read on Arguru’s website back then he was working on the first tracker not using ticks anymore. Well, just an additional thought.
Well yes. As its description is thus:
"Show/hide custom track delays. Entering a negative value will play the track before others, while a positive value will play it after. This is only available for Sequencer Tracks. This can be useful to compensate small latency problems with MIDI and plugin based tracks. "
The purpose is to be able to bring the audio back in line with the automation when there is a difference between them. Otherwise a lag caused by MIDI or incorrectly reported PDC would not get corrected by changing this value, as both would move in tandem. Thus you are using it in a way it wasn’t designed for, IE Mis-Used.
Stupid me. We already do shift automation with the track delay. Sorry, I tend to forget all those details.
Bit_Arts:
Could you post an example of where things go out of sync, so that I could have a deeper look at this? Automation shifting should not be the problem - if things work like drafted.
We only use ticks as backwards compatible “time slices” for pattern FX. They are not our main timing resolution. Samples are, so evolution already happened some years ago. Without this we would not have note delays or PDC.
OK seems I may have mis-understood how they were meant to work.
Taktik, in the little bit I quoted above it states specifically “This is only available for Sequencer Tracks.” Is that only the Show/Hide function, outdated material or a mistake? As BitArts states “the send track adjustments of the send track’s track delay have no effect on the gainer.” implying he is working with Send Tracks.
Also how do you adjust audio to bring in back in line with automation then?
Afraid my laptop has died this morning so can’t open up Renoise and look at things, like I normally would before commenting, so apologies for any confusion or crossed wires.
Now, that’s great news! I love this kind of forgetfulness.
Even more convincing “news”.
Yes, Sir. While the problem is actually, they DON’T go out of sync when I want them to. Check PM for the example, pls. Just don’t want to post it here yet, because it’s going to be part of the upcoming tutorial.
I did a little test with the track delays …8 tracks …first track starts with a negative delay of -100 ms , second -60ms …etc last track 100 ms …
All tracks have the same sample assigned , so the result is a rapid trigger effect …while the playback is correct , when rendering all the tracks to selection ( together),renoise managed to skip the first line with the tracks that have a negative value assigned ,
edit , mute track 8 and 9 ( they don’t have a delay value assigned )
http://www.box.net/shared/zostc1i86i
Took a more detailed look into this. Summa summarum we can’t apply the track delay of a meta device to its target. If we would do so, timings of cross track modulation would go out of sync everywhere. Aka, what you want here as a special case would break the timing in other cases - add shuffle things where you don’t want them to be shuffled.
What you should do instead is delaying the !target track! - the one that generates the sound and not the track which modulates its parameters.
In your example this is not possible, cause the dest track is a send, and sends don’t have track delays. I’m not sure anymore why exactly we disallowed this. I think in order to keep the already totally confusing topic a bit easier to handle for us internally in Renoise.
But you can also use a regular track to do what you want to do in the example you had send to me. Let me know if I can share your example here to make clear how exactly.
OR alternatively use note or tick delays (see http://www.renoise.com/board/index.php?showtopic=28542 - which already is fixed for the next update).
I have usually solved that with the delay device and cut off the dry signal.
But how much delay you desire is ofcourse the only limiting factor here.