The Pattern Editor works, and has worked for 10 years. Mutating it to support WAVs is ugly and most likely difficult to code. Also, it ruins what is essentially a text editor, butchering our legacy and proven tracker workflow.
Pattern Matrix represents the “structure” of a song, it’s relatively new and much more malleable. The Matrix has room to grow, room to improve.
Future can be Tracker tracks, WAV tracks, and new type of tracks… example, video? Who knows. The Matrix is the logical place for this.
Anansi’s proposal is elegant, iterative, and realistic.
EDIT: The keyword here is “iterative.” This means that maybe in the future audio tracks could, of course, be in the Pattern Editor, but this is a much more realistic approach that doesn’t fudge what we already have.
@Conner_Bw: [s]I’m not sure I understand the problem.
Is it that non-pattern data would be introduced into an area which is reserved for visualising “raw” tracker data, introducing an ugly and incompatible mixing of data types?
I would imagine that a wavetrack is actually a sort of view on tracker data held in that track - one of many (e.g. piano roll, wave, track, lyrics, Lua commands, automations etc) one could switch among.[/s]
EDIT: I love Autoseek. I think it solves a lot of issues. I think the simplest in-track waveform view would be a visualisation of only Autoseek-enabled samples.
A transparent overlay on top of a normal tracker-data view. Straight-up wave-visualisation, showing sample playback boundaries. That’s it.
I am pretty sure that some enterprising Lua scripters will be enthusiastic to supplement the view with their own editing tools like ‘split sample here’, ‘insert 09xx from Autoseek’, ‘crop audio to/clear sample-audio from selection’ etc. which would be useful in a normal track-view, and elegant to use when the waveform is shown.
I apologise if I appear naive to the issues this wave-view would introduce - the devil is often in the details, as I am discovering in a web UX-improvement project I am currently involved in…
From my point of view, it’s easier to extend the Pattern Matrix than the Pattern Editor.
The pattern editor goes deep (Tracker History, XML Representation, Lua API), where as the Pattern Matrix not as much.
Adding a transparent overlay in the Pattern Matrix = huge amount of work, testing, bug fixes…
Doing stuff like this to the Pattern Editor, to me, is like adding a toilet in the middle of your living room. It’s doable, but the plumbing is more difficult, you probably have to tear down walls and rip through floors, and maybe access to the toilet is not really the priority…
The compromise proposed by Anansi gives a clear and do-able specification that we the users can benefit from rather quickly.
EDIT: That is, a new kind of track, separate grid… When I say specification I mean what is quoted below, which covers all possible issues surprisingly well. Not a visual extension to Autoseek; which I agree is cool, but something else altogether.
my point was that the tracker part is a place where u actually make beats and melodies, where u make small pieces of a tune. than u use pattern matrix to make an arrangement. u build a full tune there. audio tracks are a place for already made pieces - things played with live instruments, vocals and so on. it seams logical to put those things in a place where u arrange those previously prepared pieces and this place is a pattern matrix. another thing is that tracker view is pattern oriented and audio tracks are not so putting them there is just a visualization of an autoseek feature - there are more important thing to implement than some visual candies like a waveform view in a tracker part - now, it is clear and simple and it should remain like this - KISS!
i’ve just thought about one “problem” - a pattern break command - it has to be visualized in a pattern matrix - pattern block height has to be pattern break dependent so audiotracks remain in sync
if the audio clip is already done and synched up with the music then why do you need a visual representation? all you need to do then is trigger the already done sample in the pattern editor as we do now. it’s pretty easy to synch up the notes to a sample that already fits
the inverse is more important imo, i.e., you have a recording/sample and you want to touch it up to get the perfect phrasing. if you can display it along side the notes in the pe then this would be much easier and you would need that higher “resolution”.
helped a friend out today. we did some quick recordings of guitar, bass, vocals and accordion with reaper. we just laid down a stupid drum beat and hit rec and just did a number of takes for each instrument. you can then pretty much see what parts of those takes which are good ones rhythmically by comparing at the waveforms/midi tracks. then it’s all about cutting, pasting, muting and pushing the stuff around to create something fun on the spot.
edit: i think that audiotracks should be separate (as someone pointed out earlier) from the tracks in the pe that we have now. different tools and right-click menus needed for those tracks and all that jazz.
m( - should have had read the first post / whole thread before replying - now my post is
senseless … sry everyone … i’ll leave it here anyway just in case there’s anything new
that hasn’t been said yet … -.- … : /
TL;DR:
Already said it all.
Opposing my missing ability to make any sense in English language I’ll try to present you
how i imagine the way audio tracks should be implemented in Renoise. As you hopefully can
see i made a mockup based on the original image posted by Pinwizkid:
What is shown isn’t just a pure visual representation of a wave file, but also the introduction
of ‘audio clips’, a feature necessary to make audio tracks useful in a productive way (at least for me).
To come up with this very original and new idea i took a good look at the only sequencer i have
ever used besides Renoise: logic 9 and asked myself why i prefer logic over Renoise when it comes to
working with my guitar.
The reason was obvious: it’s sheer easiness of manipulating sound files.
and by that i do not mean manipulating any data included in the files themselves,
but their position in the song and their length.
It’s the simple possibility to cut them, stretch them and move them, but therefore,
to make it comfortable and reasonable, other features are also needed. (I’ll discuss these later).
The first thing i thought of when imagining the way an average Renoise user would use audio-clips /
audio-tracks was that he / she would want to position the clips freely on the timeline / pattern.
the needed foundation for this was created when higher resolution and LPB were introduced.
but probably the user would also desire the clips to start in sync with the beat. so therefore a
snap to grid ( or like i would call it ‘snap to line’ ) feature would also be needed.
At the same time different resolutions for this snap feature would come in handy, as I
refuse to image every Renoise-user using LPBs of 32 or higher just to use audio clips conveniently
( I’d proclaim the icrements of 0 Lines, 1/8 Line, 1/4 Line, 1/2 Line, 1 Line, 2 Lines and 4 Lines )
The next thing was that the user probably would like to change the clip’s length,
starting point (relative to the wave-file) and ending point for which snapping would also come in handy.
aAnother thing i always enjoyed when using logic was it’s build-in ability to timestretch samples / clips /
audio-files. I know this feature isn’t urgent, but still I wanted to mention it while talking about
audio-tracks, because in-pattern-manipulation of samples relative to the rest of the track is something i
am desperately longing for since i started using Renoise.
(btw. thx and kudos Suva - i love your Timestretching plugin)
Now the next idea was that I’d also want to cut clips. And the resulting tool that came to my mind was
so groundbreaking and cutting edge - i couldn’t believe it was something already known from pretty much
every sequencer out there: the scissor tool. I do not think a description is needed but i still see one condition
emerging from introducing this feature: pattern zoom.
from experience you probably know that cutting (and positioning) a sample without
the ability to zoom in can cause you a very hard time and as you sometimes want to do this
dependent on the track embedding your sample / clip pattern zoom would be the feature you’d trade your soul for.
now that i am tired here are some features less important
( you can / can not see in my mockup ) :
clip fade-in / fade-out:
just comes in handy sometimes
clip-overlapping:
self-explaining, isn’t it?
open in external editor:
I like it a lot in logic but in Renoise it’s not that important for we have the fabulous sample-editor
bounce with fx:
one always needs to save some CPUcycles
pitch-shifting:
it’s fun
text-tool:
just for the sake of renaming your clips
crossfading between clips:
comes in handy
advanced edit:
this one should automatically change to an appropriate menu
@simoon - all u have written is true… those are more or less generic audio tracks editing capabilities found in most of the daw… but tell me why do u insist on putting those audio tracks into the tracker part?
all those things can be done in patern matrix when the below conditions are true:
Hm … the ideas around are nice and the discussion seems to make more questions as answers.
I like the editing in the way that “trackers” offer me. For me it must not be the main “focus” and if the evolution brings other great creative editing concepts i will not say “stop” to keep renoise untouched. Yes … renoise starts as a “tracker” and over the years it grows to a really good application. Today i like the idea to combine all the great concepts in one great software and i think it is not clever to cut suggestions out because it cross the starting main focus “tracker”.
I think I’ll have to respectfully disagree with you. Matrix does not offer enough Zoom for start. If there was an option to Sync Matrix Size to that of the Pattern Editor (so lines married up) along with check boxes to display only the Tracks you wanted, in both Matrix and Editor then it might just about suffice. But being in the Pattern Editor is far more the place for it. It is audio itself. It is where you adjust and time it. It wants to be seen in relation to other audio generating tracks, whether smaller samples, VST or MIDI.
Although also having a Matrix view for an overview would be nice.
Plus how many times have us Users been told not to speculate on difficulty of coding and concentrate only in Ideas?!? That is not something you should be taking into account, not even Alpha Testers, unless it is something one of the Devs have actually said previously (and I’ve not seen it on this board but maybe IRC or private mails and if so fair enough, apologies.)
with the current autoseek for me the option to choose between a RAM or Stream from disk will be sufficient.
maybe the same for recording samples in Renoise.
When I’m taking guitar of vocal tracks for my band I really have to be careful I don’t run out of memory.
I’m with you on this one kazakore. The pattern matrix just doesn’t offer the resolution to see if your audio track is in sync. If it’s in the pattern editor then you can immediately see it side by side with other tracks / notes and adjust as necessary. It’s not just eye candy, it’s essential to making an audio track practical.
First of all, a big hello to everyone since I’m new here Good to see that I’m not the only one wishing for the audio track feature.
I read through the whole thread and everything I was thinking about has pretty much been said already, but I still thought about sharing my two cents. First of all, the audio tracks shoult definitely be in the pattern editor. The matrix idea could work somehow when you use samples that are several patterns long, but if you wanted to use, say, four clips in a single pattern (from multiple takes of a solo for example) it would get pretty tricky. Using track DSP’s for a track in matrix would just mix the concepts of the two windows up. In my eyes the editor is for composing while the matrix is solely for arranging the patterns.
I don’t quite see why one should be able to edit the actual audio on the track apart from non-destructive cutting, copying and moving of the clip. All the DAW’s I’ve ever seen have had a dedicated audio editing view apart from the multitrack view, so I don’t see why Renoise should do things differently in that one. Here’s a quick visualization of what I had in mind:
Basically the audio track would be scaleable only horizontally, but you could see the sample editor at the same time with the pattern one and zoom it as much as you like. You could also scale and cut the audio clip in the editor, allowing precise editing without needing a possibility to zoom in the pattern view. The pattern lines and line numbers in the background would make it easier to count the beats and figure out which part of the pattern you are viewing. Envelopes could be drawn on the sample editor as well.
What an audio track, as we’re talking about here (love the autoseek tho), needs is more or less what simoon said in his post. Coming from Cubase (and having worked in all of the “big” sequencers) this is what is needed in the pattern editor to make this thing useful…
Snap/Free Move. Cut/Paste/Copy. Drag (snap or free) Timetretch. Fade In/Out. Drag & Move. Overlap.
Then in-depth editing, more advanced timestretch and other things go into the regular editor window(s). But all the above will have to go in the PE imo, otherwise it’s not really worth the effort.
With that said, audio tracks is not a do-or-die feature for me, it would be a nice one tho.
Edit:
As for using the pattern matrix, it would have to go through some hefty upgrades (although I don’t really see the usefulness of adding the audio tracks there, other than visual aid) to work. As it is now it’s main good feature, for my workflow at least, is the copy/paste of entire patterns and as a visual aid. The muting… not really useful as you still have to dig into the pattern editor to “pre mute/pre un-mute” things (something like a “draggable” mute in there would be awesome tho). But as for audio tracks I don’t see it. At least not in any really useful way.
