Correct me if I’m wrong, but I think to be really sure what is going on on a track at a specific point in time, Renoise would have to render the whole song up to that point. So whenever you change something…
I’d expect it in combination with track freezing, but without it, no way. And believe me, I’m more about the visual gimmicks than music haha, nobody wants features like this one more than me 
what’s the point of this really?
to get some sort of visual about where samples ends,i for one would really like to see this feature,it would be a BIG + and would also help speed things up abit for the way i work in renoise
Actually one of the most obvious differences between trackers and horizontal sequencers is that in trackers you don’t visually see where a sample ends, while in sequencers you do.
In the other hand in some situations the visual length of samples in sequencers can be fake, for example when the pitch of the sample is fluctuating.
In contrary to my earlier post here, I’m not quite sure how much it would help me to know where a sample exactly ends when using trackers; with short sample it won’t help at all. Also when I’m using long samples I have to manage them carefully so I’d always know where the sample should nearly end.
Anyway, if such a feature would be ever implemented I’d like it this way:
Nice picture, Ashkan.
Actually, I think Renoise is not far away from knowing where a sample would end during playtime.
For example, if I click on a certain sample position in the sample editor, Renoise shows me the approximate sample offset. So I think Renoise can calculate how many rows in a pattern a sample would occupy being played at a constant speed. For different pitches, I imagine that it would have to consider (divide by?) the custom pitch value. And this way Renoise could also retriger long samples at the correct position. So you wouldn’t have to replay your song from the point where you triggered a long sample only to know how it would sound together with the other elements three patterns later.
But well…this is a user-view on the issue. I better go to sleep again 
It would work if the sample doesn’t have an envelope…
But again, it’d have to be treated as an ‘audio track’ the way other sequencers do. In Energy XT2 you can load up a huge wav file and wherever you start the song, the sample starts there, but it won’t work if that sound is triggered by midi.
Also, if you look at aero studio, they have something ‘sorta’ like this…there’s a blue bar inbetween the tracks you can see that shows how long the note plays…
Idk…so many decent ways to handle it…who knows…
Here’s a slightly different screenshot, with a waveform display instead of color-coding.
I’ve used the space left by the instrument number:
Note: this wouldn’t work with normal samples! Imagine that you loop a pattern or block, with a long sample being triggered in the middle. Then, Renoise would still play the sample when the cursor moves to the beginning of the pattern/block. So this is really only good for visualizing audio-tracks.
I’d rather see that renoise ‘handles’ long samples better…
so that samples that last longer than one pattern, don’t need
to be played from the start to be audible in the mix…
I don’t see the point of seeying where a sample ends because
if you’re well into your own track, you already KNOW this, that’s why
you put the sample in the track in the first place, right?
On second thought, I’d agree. Having a visible waveform, or any indication of length, could be very CPU-intensive because of the many ways you are able to manipulate samples (forward/backward, pitch, etc). Most sequencers simply don’t offer these features, so with those sequencers it’s obviously much more simple to display samples.
Also, we don’t show notes played with a VST instrument in a different way than a sample, now do we? 
+1 from me. Like others say - I’m sure Renoise is on it’s way towards some kind of indicator for sample lengths. I like Danoise’s idea, and would find it particularly useful for using lengthy speech samples with offsets. Audio tracks are clearly the way forward though.
I’ve got one word for you: Screw this, we need audio tracks.
Admittedly, that’s 2 words, however, you get my point.
audio tracks would be the ultimate way to do this
i could be track freez and freezed track could by shown like wave form until you unfreeze it
danoise, that screenshot looks HOT.
but I gotta say, this seems like it should be a pretty low priority to me - I’d rather have efforts focused on things like poly-patterns, modulatable envelopes, non-snapped automation curves, etc.
that said, allow me to indulge myself 
how about if the “tail” was just a block but it changed length dynamically - that is, it’s based on the current pitch. one tail per note column.
that would save extra rendering and it would look cool too! that way, if the pitch of the sample increased (through envelope or slide commands), the length of the tail would decrease and vice versa. seems like this would be simpler as Renoise just have to figure out where the sample would end based on the current pitch. it’s just simple multiplication, right?
I don’t think it’s that simple - imagine you throw in a Bxx command to reverse playback direction, or make the pitch glide from note to note. I’d like to see how Renoise would handle that in realtime, it would require massive pre-calculation!!
But it’s still usable with freeze-tracks, as serumas pointed out 
Audio tracks – that’s a +1 for me. But seeing how large samples get load fairly slowly, would Renoise be able to handle this alright?
As for having a little vertical waveform, that could probably be done (even with Bxx commands, etc) if Renoise created a “wave image” file for every triggered sample – I think this is how Cubase does it. But that would seem wasteful of resources. Cubase wouldn’t deal with all the note triggers and note effects that Renoise does, so needs fewer “wave images”.
I’m not sure whether I made it clear (sorry to sound condescending if I already did) but I meant the length changes in real-time, e.g. if there’s a vibrato the length would wiggle up and down slightly. if there’s a pitch slide down the length of the bar too would extend downward.
and AFAIK that actually makes the rendering simpler because it doesn’t have to pre-render anything. what the renderer would need to know is:
-length to end in context of current playback direction (lengthToEnd = totalLength - currentPosition)
-current (instantaneous) pitch.
so:
boxLength = lengthToEnd / currentPitch
and as long as it’s just colored boxes I don’t think it’d take up too much processing.
okay I don’t want to get too evangelical about this, I just thought I’d clear it up.
I don’t see how this is heavy on resources. Every daw out there practically already can display audio tracks that get mangle. It need not be accurate per-sample display…just approximate so peaks are visible. I dont see how b01 is any different than reversing audio in another daw…as well, scaling the wavform graphics has been done since acid was released in 1999 or so…it ran on 200mhz no problem so I dont see where this CPU concern nor display concern comes from. I agree we do need audio tracks and a good time stretch/pitch shift algorithm.
I think the complexity of determining sample length, before it’s actually being played, is best illustrated with an example…something like mat-weasels scratching demo (link to thread + download)
Imagine that the scratching samples was streamed audio (audiotrack) instead of short samples - and that we had some sort of visual indication of the length? That is, before we actually start to play? That’s where the pre-calculation would have to be done. And to display the length as a simple “bar”, as opposed to a waveform, will not solve anything, as the pre-calculation would still be needed (from a programmers perspective, the waveform would be the last, and relatively simple step of updating the display).
For all of these reason I think we’re better off using a length/waveform display for frozen tracks. Here it makes a lot more sense.
Heck, those waveforms even look like icicles to me (== frozen audio:-)
But it doesn’t display the “mangling”, just the sample!
generally i think better handling of long samples in renoise could be handy in theory, but would just as likely be an irritant, especially if it slows everything down and clutters up the interface. i usually export the audio tracks into audition when i want to do things like this, it just makes more sense. just my 2p anyway…