View Single Post
Old 06-28-2010, 01:03 PM   #57
DarthFader
Human being with feelings
 
Join Date: Feb 2009
Posts: 324
Default

Quote:
Originally Posted by pcartwright View Post
I also have to disagree with this one. Having specific tracks for just audio or just MIDI could compromise plugins that use audio to trigger MIDI events or vice versa.
Having a dedicated track type for MIDI would not eliminate the ability to do that.

You could still have the (original as it stands) combo midi audio tracks etc.

What we want is the OPTION to have A NEW track type that is dedicated to midi and especially hardware midi.

One that shows the patch name, where the volume and pan controls send midi, where you have transposition at a click on the TCP.


Constantly, it gets thrown out here, that if they give us apples, they have to take away the oranges.

That isn't true at all. We want apples AND oranges, not apples OR oranges.

We want to streamline the visualization and working with MIDI data.

The fact is, MIDI note data is just plain different than a track that is just an audio recording.

There are different things you want to see and do in each case; unifying them refuses to acknowledge the fact that they are in fact different, at least in terms of how the controls, etc, should be presented.

It's like if you had only a vehicle track and it could be a horse or a car. Well, horses and cars are just different. Same with Midi and audio. Refusing to acknowledge the obvious and having to click into subwindows to feed grass to the horse or stick a hose in the car instead of having those controls on the TCP (based on being able to select car or horse) is really nonsensical.

Sure, it "works" and it "can be done" but it is not productive or convenient.

DF

Last edited by DarthFader; 06-28-2010 at 01:12 PM.
DarthFader is offline