I disagree. Workflows for large through composed projects often work out far better with MIDI tracks connected to rack instruments. Workflows for ‘pattern’ or ‘looping’ style compositions can certainly benefit from the convenience of Instrument Tracks, and their ability to export MIDIloops directly into the Media Bay library for easy preview, and dragging right into projects.
Neither track type is ‘more or less’ advanced than the other. They simply have different sets of pros and cons.
Instrument tracks only have the audio bus on the mixing console. The fader controls the actual audio bus, as opposed to sending CC events to the connected instrument. A primary advantage to Instrument tracks, is the ability to export ‘midi loops’ that can be previewed directly in Media Bay, as the plugin information is exported along with the loop.
So, if you like to store licks, phrases, and loops, of which you can later glue together into complete songs Instrument tracks just might be the way to go. They are great for ‘pop song writing’, ‘EDM’, and keeping up with ideas of which you can catalogue and library again and again.
MIDI tracks (which can be connected to Track OR Rack Instruments) give you independent MIDI faders, and Audio Bus faders on the mixer. The MIDI faders talk to your connected instruments, sending things like CC7 (volume), and CC10, (Pan). You can scale the mix in your plugins independently of the audio bus(es).
MIDI tracks provide MIDI Aux Sends, which allow you to send MIDI output to more than one instrument for layering, or extra processing…you don’t get these with Instrument Tracks.
There are also some minor advantages to working with straight up MIDI tracks over Instrument tracks when doing freezes, merges, slicing and dicing parts, applying logical editors, and more.
As for many instances being superior at thread management…that’s not always the case, and even if it is, sometimes memory management is more important, and sometimes a single instance of a plugin (it really depends on the plugin engine of course) can do it better than multiple instances.
See, sometimes ‘memory management’ is more important than multi-core processor threading. It all depends on what kind of sounds you’re working with. In the case of a big orchestral setup that relies on several velocity layers of large samples…you might want instant access to many gigs worth of samples at all times, while ultimately you might only be using a few sounds at any given moment in the time-line (and being largely sample based, might not call on many CPU resources anyway). In such cases, it’s often beneficial to map it all out in as few instances of a plugin as possible.
Start doubling voices across different families of instruments, hosting articulations on independent channels, keeping up with ‘quantized score tracks’ independently of humanized ‘play back tracks’, and on and on. Start teaching the score editor to interpret scores based on a consistent and uniform pallet of sounds. In these work-flow scenarios, it often makes far more sense to load a multi-timberal plugin in rack mode, then load up everything you need into that one plugin instance.
In some work-flows, it even makes sense to go ahead and put single timbre plugins in the ‘rack’, keep them there, waiting until you decide to make a MIDI track and connect to it. I.E. You might begin composing a phrase with just the first violin player, knowing that once it’s done you can just clone the track twice and connect it to your 2nd and 3rd chair players, run a couple of passes with some MIDI logical editors to give each player some humanized variations in velocity/expression data and timing. Then, clone it to the 4th chair, transpose it down a third, connect it to your waiting plugin, and so on.
For orchestral scores, over years, we build instruments to work together. I.E. 48 channels of 1st violin articulations and sustain variations, plus key-switches, arp engines for interpreting things like turns and glisses in the score editor, and more. It grows over time, and gets recycled in project after project. New MIDI Tracks, same old instrument sets (but with an ability to grow and change as needed).
Case in point…
A single instance of HALion 6 can host up to 64 channels over 4 different MIDI inputs. You might not have anymore than half a dozen of your HALion slots actually playing something at a time, but the ability to quickly throw a new articulation or sound variation on a fresh channel of his own to bounce to is priceless. With key-switches and program changes on a single track/channel, you can easily run into a frustrating situation of having to tweak dozens of parameters along with the key-switch each time you swap articulations, but if you give each articulation his own dedicated channel, you can often tweak it once right there in HALion and leave it be. I.E. Sustained first violins get a track of their own channel(s). Pizzicato, Martele, Detache, etc, each getting their own channels.
Eventually you might freeze and merge all those tracks down to one, and quantize it for the sake of printing a score, but until then, you can easily stack all sorts of variations to mute/unmute at will while searching for the perfect take…copy and paste around throughout the arrangement as needed, and much much more.
As your collective pallet of sounds grow, you can just save it all in one place, as a multi setup that can be loaded and used again and again in future projects.
It doesn’t take long until you have several instances in the rack. One for first violins. Another for seconds. More for your Violas, Cellos and Contras. Another for woodwinds. Another for Brass, then percussion, and on and on it goes. Eventually you have a massive ‘template project’ all ready to go anytime you begin a fresh Orchestral Arrangement.
So really…it’s all about what you need for a given situation. Some projects are even ripe for MIXING and MATCHING Instrument Mode, and Rack Mode plugins, and Instrument and MIDI tracks.
BOTH track and rack types are extremely useful. It all boils down what YOU need