Q: Why use different track types?

Official support for: energy-xt.com
RELATED
PRODUCTS

Post

spacefox wrote:Especially with clip based fx coming in XT2, why not switch to clip-based rather than track based approach.
how do you record a VST instrument before you create a clip? if the routing is in the clip...
It seems so obvious once you've used a program like Samplitude or Tracktion that doesn't bother with the artifical assignment of "track types". "clip types" does that job and more!
Clip types are cool. It wouldnt work very well with the drum track/clips in xt2 though as it has lots of track settings for each sample in track, like trigger key and sample params. So if I have a midi clip and a drum clip on the same track, and I play my midi keyboard live what shuld it play? the samples or the midi device...

xt2 does automation overlay already, but not midi and audio. But isnt it hard to edit track where audio clips sits on top of midi clips? Imo, it would be nice if midi and audio was contained in the same clip and then you could toggle stack or overlay mode in the song view...but thats not something Im working on

8)

cheers
jorgen
Half developer half human
XT Software
http://www.energy-xt.com

Post

Charlie wrote:I agree a lot with what Greg has said about clips but I wonder how much of this debate is about workflow and presentation. For me it would certainly be logical if I could put my midi, audio, envelopes, etc wherever I wanted.

Sometimes I like to think of my midi clips (or parts!) as audio clips and would like to treat them that way.


Some ideas that I have about clips.

- Include routing information within the clip instead of the track. As an example, I could have a one bar midiclip which is set to output to one VST then without using a new track the next instance of the clip could be set to output to a different VST or even many VSTs. (Also, automate the inputs and outputs of a clip.?)

- Encapsulated Midi Clip - A self contained midi clip with its own sounds or VSTis. It could be used for midi or audio output. (An advanced type of freeze maybe?)

Luna works the way you suggested, where each MIDI clip is routed to a VSTi ("player" in Luna Speak) and each audio clip to a mixer bus (Luna Free will have only one bus).
This way all MIDI clips are treated just like audo clips and track are used solely for arrangement - not for output.
- Dropping a midi part onto an audio track gives you the option to freeze it as a wav.
Too easy to do that by mistake, and freeze is a resource intensive process, so I think it's not as good an idea as it first seems.
CubaseStudio4 µTonic/Rapture Nitro/GS-201/Ohmicide/TBK 1&3

Post

jorgen wrote:
spacefox wrote:Especially with clip based fx coming in XT2, why not switch to clip-based rather than track based approach.
how do you record a VST instrument before you create a clip? if the routing is in the clip...
In Tracktion and Reaper the routing isn't in the clip - you arm the track with either a MIDI or audio input, and record.

In Luna the routing is within the clip, so you set recording mode to either MIDI, audio or both.
Clip types are cool. It wouldnt work very well with the drum track/clips in xt2 though as it has lots of track settings for each sample in track, like trigger key and sample params. So if I have a midi clip and a drum clip on the same track, and I play my midi keyboard live what shuld it play? the samples or the midi device...
I get your point. This way tracks are a way to group settings of similar objects which could, like in XT - the land of endless possibilities, make things simpler.
CubaseStudio4 µTonic/Rapture Nitro/GS-201/Ohmicide/TBK 1&3

Post

Lunch Money wrote: Huh? You arm it with a MIDI device, which can be just as quick and just as template-able as your subsequent post a bit further down from the one I quote here.

There's no clip there already, but it's armed with MIDI device, you press record and it starts creating a MIDI clip.

There's no clip there already, but it's armed with Audio device, you press record and it starts creating an Audio clip.

Simultaneously, if you're 'recording' automation, an automation part is also created, using whatever visual method you prefer.
Ok... but how is arming a track with a specific device any easier than choosing a track type?
Heck, if you have the track armed with an audio AND a midi device, why not just allow both to be recorded in the same track? Once they're clips, they can always be moved around.
So you want to be able to record different things on the same track so you can manually move them to separate tracks so you can actually do something with them?
Using plug-ins that accept MIDI and Audio information couldn't be easier than in a host that has any "clip type" within its track.
That sounds logical, but can you give an example?

---
Or in a more basic way of looking at it: in your operating system, you don't need to make a "pictures" folder, even if the folder happens to contain only pictures. Why make a track (the "container"/folder) HAVE to accept only one type of input or clip? It doesn't make sense and has no benefits.
No, but for some obvious reason I still do have folders called "Pictures", "Music" and "Samples"... and they contain only certain type of data. I do have holder-folders, that include project folders, but inside them the different datatypes are divided in subfolders -html, img, style, material, etc.
The benefits of universal track types:

1. Overlaying clips of different types. Put your MIDI over your Audio in order to align notes, etc., with visual cues.
Yes, this would be cool. But could also be solved by creating a ghost image of an audio clip for visual reference. Or "extract groove" like in Cubase.
2. Easy use of plug-ins that accept both MIDI and Audio data to perform their function (ie. GVST's GSnap in MIDI mode, or BetabugsAudio's Getablitch Jr.)
and sidechaining plugs in general? I would not want the trigger signal and destination to be on the same track.
3. No need to assing type and THEN arm the track. Arming the track simultaneously permits creation of the appropriate kind of clip. On a related note, why not allow multiple-arm to the same track? I wouldn't use it, but it'd sure be flexible and some people might end up using it.
Erm... currently you only need to create a track. MIDI tracks are "armed" on creation, and I suppose audio tracks could have a setting "enable recording on creation", but I very much prefer the current way of "muting" recording on the new tracks.
4. No need to make the 'templates' that you mention in the same way. Why set up a project with 4 MIDI and 4 Audio, when you can just have "8 Tracks" and fill them with whatever you want?
Creating tracks is really dead easy and very, very fast. Just r-click and choose type. I don't see a real benefit of that.
It seems so obvious once you've used a program like Samplitude or Tracktion that doesn't bother with the artifical assignment of "track types". "clip types" does that job and more!

Greg
Thanks Greg, but not for everyone. I used Tracktion for a long time, and I never mixed different types of data. And the clip types certainly did NOT do the job in Tracktion.

Audio is not MIDI, ok? Other is source data, other is rendered/compiled end result, or material brought into the system. They are created by different methods, processed by different tools and have different needs and uses.

This is very much like creating graphics in a vector program. You have vector shapes, that are raw data and allows free processing. Then you have bitmaps, which can only be shaped in certain ways. Confusing them can get you in trouble.

Ok this gave me an idea for those people who like to think their midi as audio - how about a visual render of the MIDI data? Like vectors, the MIDI could rendered into waveform on-screen. If it can be rendered real-time as audio, surely a simple bitmap representation wouldn't be a problem. Probably not very useful, though :D

Post

.jon wrote:
4. No need to make the 'templates' that you mention in the same way. Why set up a project with 4 MIDI and 4 Audio, when you can just have "8 Tracks" and fill them with whatever you want?
Creating tracks is really dead easy and very, very fast. Just r-click and choose type. I don't see a real benefit of that.
It's already faster than that - select the type of track you want to create and just double click on an empty space in the track pane or press Ctrl+Ins to add it.

Post

Yes if you have already tracks of the same type... but the r-click, add, select type is IMHO already fast enough.

I find the Tracktion arrow style just as easy and fast, my point perhaps being that track creation is not very meaningful in terms of the whole workflow.

Post

robenestobenz wrote:
.jon wrote:
4. No need to make the 'templates' that you mention in the same way. Why set up a project with 4 MIDI and 4 Audio, when you can just have "8 Tracks" and fill them with whatever you want?
Creating tracks is really dead easy and very, very fast. Just r-click and choose type. I don't see a real benefit of that.
It's already faster than that - select the type of track you want to create and just double click on an empty space in the track pane or press Ctrl+Ins to add it.
now thats the shit!!!!!!!!!

thanx robenestobenz :D


Subz

Post

djsubject wrote:
robenestobenz wrote:
.jon wrote:
4. No need to make the 'templates' that you mention in the same way. Why set up a project with 4 MIDI and 4 Audio, when you can just have "8 Tracks" and fill them with whatever you want?
Creating tracks is really dead easy and very, very fast. Just r-click and choose type. I don't see a real benefit of that.
It's already faster than that - select the type of track you want to create and just double click on an empty space in the track pane or press Ctrl+Ins to add it.
now thats the shit!!!!!!!!!

thanx robenestobenz :D


Subz
XT's just full of good surprises, eh?

Post

.jon wrote:Audio is not MIDI, ok? Other is source data, other is rendered/compiled end result, or material brought into the system. They are created by different methods, processed by different tools and have different needs and uses.

This is very much like creating graphics in a vector program. You have vector shapes, that are raw data and allows free processing. Then you have bitmaps, which can only be shaped in certain ways. Confusing them can get you in trouble.
Another analogy might be a layout program such as QuarkXpress. It treats both vectors and bitmaps as images. It is only when you need to edit them that the differences become clear. Then you use the appropriate tools to edit them.

Post

Exactly, Charlie!
Image

Post

fwiw I've never gotten the big fuss over being able to put midi and audio on the same track in T2. I found that every time I did something with MIDI overlaying audio, I was creating an extra track and routing to the existing track, as trying to edit 2 things on top of each other was just annoying.

Automation in T2 doesn't really compare, not in an eXT > T2 sort of way, but an apples and oranges way. Each system has its pros/cons, but for me, the annoyance of having an envelope overlaid on other material I was trying to work with is really not worth the effort.

An observation: everybody is using VSTs that use audio and MIDI simultaneously as an example, but the only advantage that a 'universal' track offers for these applications is overlaying one data source on another (midi on audio or vice/versa) which, while it looks nice, I've found is terrible to work with.

Post

I find it exceedingly helpful, as per my OTHER example, which was using the visual cues from the waveform to align and program MIDI to replace or supplement the audio.

I do it all the time with "finger drumming" (which I find easier even than drumming on a controller keyboard) in order to nudge or place drum hits.

The other advantage, also mentioned, is simply that you don't have to assign a "track type". Maybe you never need the "both kinds in the same track" function, but it's also the "either kind in the same kind of track" function, which is self-evidently more elegant and streamlined.

Why "tell" your track what kind to be? Why not just press "record" no matter what device is armed?

Greg
Image

Post

Lunch Money wrote:The other advantage, also mentioned, is simply that you don't have to assign a "track type". Maybe you never need the "both kinds in the same track" function, but it's also the "either kind in the same kind of track" function, which is self-evidently more elegant and streamlined.

Why "tell" your track what kind to be? Why not just press "record" no matter what device is armed?
Erm... it's not even evidently elegant, it's clumsy and unorganised.

Post

I don't have multiple MIDI devices, but if I'm understanding this correctly, eXT records from all MIDI input devices to a single, armed track. Is that right?
Image

Post

It is possible to have NO TRACK at all, only clips which contain all the necessary information and can have sub-clips for FX or automation...
See HyperEngine AV : http://www.arboretum.com/products/hyper ... _main.html

No MIDI, Mac only, but audio, text and video.
Clips can be put inside containers like folders and sub folders. Outputs settings are clip based.

The product is now open source and I really hope that somebody will continue it or take it as a model to give us a software that is no more based on a hardware imitations...

If track based mixing is useful for very linear workflows, like loop based music, clip based is ideal for some other type of compositions where we need to do a lot of arrangements, cuts, mixes, groups etc.

I have hoped too that XT2 could be more object based, but I understand the logic to remain track based.

Post Reply

Return to “energyXT”