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…