Rack Instrument and Instrument Track discussion

Cubase
1

Thread split from Deleting a VST instrument in a rack is needlessly hard and arcane. - Cubase - Steinberg Forums

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.

I.E.
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.

I.E.
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 :wink:

1 Like
2

As I said multiple times above: There are probably still some cases where it is beneficial to use the instrument rack. My point is simply that it is increasingly rare these days to find such a case. Nothing you said contradicts that. A novice, for whom the feature the OP mentioned would be important, would not be using the instrument rack when getting started with virtual instruments in Cubase. Instrument tracks are obviously simpler to use than the instrument rack. That’s why instrument tracks exist :slight_smile:.

3

Fair enough, but in my little corner of the world (mostly academic, with some commercial video and game scoring on the side), Instrument Tracks are far more rare. 99% of the projects I come across consist of multi-timberal instruments in rack mode, with MIDI tracks connected to them (and many more MIDI tracks not connected to any instrument/plugin at all during mock-up stages…there for scoring purposes).

They typically don’t load 121 independent instances of plugins like HALion, Iconica, Kontakt, VEP, ARIA, etc. Instead, they port a common instrument setup across multiple apps (Finale, Sibelius, Dorico) across a dozen or fewer multi-timberal plugins, and build on that mass pallet of accumulated sounds.

Perhaps I’m wrong, fair enough, but I just don’t think it’s very rare for Cubase users to take advantage of multi-timberal plugins and sample libraries as they were designed, and intended to be leveraged. It’s true that more new plugins come out every year that are well suited to a more Instrument track focused work-flow, but the leading industry standards are still very much designed to be treated as muli-timberal giants.

4

Please do not misunderstand. The main point of yours I was debating was the notion that using the rack, and rack mode plugins is rare. I could be wrong, I just don’t believe it is rare at all. The rack, and rack mode instruments seem to be very common to me, but of course, my data is anecdotal, and based on the kinds of work and projects I come in contact with.

The part about thread efficiency and memory management came up later, and I do NOT entirely disagree with you on these points, instead it would seem you disagree with me, and that is fine.

I’m just saying it is NOT always the case. In my experience, splitting things up among many instances does NOT necessarily improve threading/core distribution, but it does often increase the project load time, and it does make it rather difficult to configure sound-sets that are easily portable across many platforms and apps.

Again, it depends on the plugin in question, and it also depends on how you configure the mixer. It depends on if you are also running VST effects on the bus. It depends on if you are routing things through group tracks. And more…

Most of the heavy-weight sample library hosts for Orchestra libraries typically don’t need much CPU unless their samples are packed or deeply encrypted using some method or CPU feature/instruction-set that your particular model of CPU doesn’t support (and thus has to work harder to emulate the CPU feature in software). Most of them don’t require much if any third party VST effects on the mixer, as they have their own built in, and we like it that way for consistency, because we use the sounds in multiple hosts. It’s quite different from using a lot of multi-layered fat synths that DO need a lot of CPU.

Again, while I might have over 120 sounds ready for on demand use…it’s pretty rare I need more than quarter of them actually PLAYING at a time. I need them all loaded and available but most of them aren’t playing at once. I.E. when a violin player hops channels…to go from arco to pizz…to martele…to sauteli…to detache…etc…

Also, leading multi-timberal sample Library hosts tend to be quite good at thread management up to the point it hits the DAW BUS. Leading sample library players allow you configure independent audio buses for each slot (I.E. A single instance of HALion can have up to 48 independent stereo buses on the mixer), which from the DAW’s perspective, gives you the EXACT same threading basis as 48 independent instances (Personally, I rarely need more than 6 to 8 outputs…and then only if I’m dressing things up with special reverbs and compressors for a mastering session).

Engines like HALion, Kontakt, Vienna, and ARIA, don’t really care if you do it in one instance, or many. The core engine is still the same (I wouldn’t be surprised if all the versions of HALion/Groove Agent/Iconica aren’t using the exact same engine…higher versions just add more content, and register a differnet GUI to access more of it)…adding new instances just registers a new copy of the GUI and a stack for the relative parameters, asks the OS for any additional memory it needs, and you require slightly more overhead in terms of memory and more inital load time for the additional GUI registrations. In multi-timberal mode, you can still have as many independent audio buses as you require. Where it makes a difference, is how easy it is to make huge configurations that can be reused in ANY DAW or Scoring program. In my little world, we often have clients that ask us to work in Finale, or Sibelius, Dorico, Cubase, Logic, Pro Tools, or any number of main hosts…so we like soundsets that we can use in all of them, to maintain a familiar and reliable sound pallet. Locked and loaded multi-channel/multi-timberal plugins make portability across different hosts MUCH easier to manage.

No…it’s not ‘just as easy’ to work with Instrument Tracks for many of my needs. When cloning tracks/merging/etc…I don’t want fresh instances of the instrument every time, throwing more audio busses on the mixing console (that I’ll end up deleting anyway). Chances are, I just want to process the new track and connect it something else (voice doubling to a new family of instruments), or even over-write or merge it back to the original track. I even have hundreds of macros/logical editors built to do such things in a click (I.E. clone a selection to a new track, quantize it to a custom groove track, replace the section in the original track, delete the new track). I don’t want to automate the audio busses when I do the MIDI mix-down…I want to control the instrument’s internal mixing matrix, using CC events. On and on this goes…Instrument tracks are not conductive to my workflow in such cases.

There are minor differences…some things Instrument tracks are better, some things MIDI tracks are FAR more flexible/easy/faster. In a through composed MIDI composition…I personally find MIDI tracks far more flexible, and far more attuned to the POWER TOOLS of the MIDI Editors. Yes, you can still connect to instruments loaded on an Instrument track all you like…but there are STILL some differences when it comes down to automating the bus…how the entire MIXING work-flow turns out.

5

You seem eager to disagree with me, then go to great lengths to support my points. Let’s leave it there :slight_smile:.

6

OK, but rack mode multi-timberal setups are not RARE. They are actually dominate in my circles of associates and clients.

In most cases, 48 independent instances of HALion is NOT any more efficient, or better at thread management than a single instance. ESPECIALLY in orchestral setups. The rare exception ‘might’ be if you were trying to play all 48 channels all at the same time through a single stereo bus, but even then, I don’t think it would be much difference.

121 instances of plugins in Instrument tracks would be a compositional and mixing nightmare for orchestral work-flows. Down right crippling when trying to use the advanced features of the MIDI and Project editors.

Glad I’ve supported your points :slight_smile:

7

Obviously the use of the instrument rack could both be rare among Cubase novices, and at the same time, be common among you and your friends. No disagreement there.

As a rule, instruments should be used monotimbrally, but there are exceptions to that rule. No disagreement there.

The beaten horse is dead and buried :slight_smile:.

8

OK, horse is dead. We agree…

I think we just had a different inital interpretation of what monotibrally means. Same rule book, just different pages.

I’m speaking of bouncing lots of different sounds over a common audio bus. Technically, the bus doesn’t have much of a load at any given moment. That single ‘violin player’ is still only playing one or two notes at a time through a given audio bus, he’s just bouncing it over many channels to get different sounds with each note. He has access to many ‘timbers’ at any given moment…and thus the power of channel bouncing using as many or few MIDI tracks as one likes to the rack mode hosting a multi-channel instrument.

The reason I panicked enough to type so much over all this horse beating is…I’m having nightmares here, imagining more than 100 virtual instrument buses sprawled across my mixing console when I really only need 2 to 6. More than a dozen of them corresponding to a single virtual violin player, which is what happens if I open up new virtual instrument tracks using my nifty ‘Cubase track presets’ for launching each articulation required of him. I’d never tell my students that as a rule, they should have dozens of plugin instances scattered over a dozen independent audio buses to cover a single virtual violin player’s part.

So someone might say, “Just put your articulation changes on key-switches, or program changes.” Possible, but…way more time/work/effort/money for me to do that and get the desired results, as snap back defaults (I.E. ADSR on the main proc-amp) after the ‘switch’, and the processes required to fix them in real time (if possible) in many of the instruments of today often stink. Easier for me, and more flexible, to just host a lone articulation that’s tweaked for the tempo/style/mix-space/effect-send-levels of the piece on a channel of his own in a good multi-timberal plugin.

9

Maybe the horse is dead, but I wouldn’t like at all to see the instrument rack disappear. So, I have to support Brian, on this case, as I always use the instrument rack for my multitimbral/mutiouts VSTi (Emulator X3, BFD2, Halion Sonic SE…). I have seen already a lot of features disappearing for no real reason, through the years, excepting probably to make room for other new brand ones supposed to be more ‘modern’ (RCE comes to mind, as well as Loopmash, etc.). So, I’m being very suspicious when I see a thread such as this one, in which it is more or less suggested that a feature is no longer useful, because it is supposed to be more ‘modern’ to do differently : in this case, using different instances of a given multitimbral VSTi. I’m absolutly not sure that it is more efficient, especially considering the memory usage, and I have seen a lot of VSTis that don’t work reliably with several instances, especially samples based ones : Emulator X3 is the first that comes to mind.

So, why do I absolutly want to keep the rack ? Simply because I want also to be able to process each audio output pairs of the involved VSTi separately : I think that no one will ever use the same set of inserts and/or sends for a Rhodes like sound and a flute. AFAIK, instrument tracks don’t allow this, unless creating as much of them as outputs used, from which I don’t see in which way it is more efficient, in this case. With the rack, it’s immediate : there are as much audio outputs immediatly created in a Cubase project as outputs busses defined in the involved VSTi, inserts/sends are available for each of them, this, with the render in place feature.

I absolutly want to see this preserved, as the Instrument rack (or its previous equivalents) has always been the Cubase way to manage efficiently any multitimbral VSTi available.

10

Thanks Cubic,

I don’t think they’ll take the rack mode option out anytime soon. If it does eventually go away in Cubase, it’ll probably stick around in Nuendo for some time thereafter. If they do decide to pull it in Cubase, then there had better be MANY improvements and additions to the Project/MIDI Logical Editors and Instrument Tracks (including an option to bring up a MIDI Mixer Fader)…or a lot of us will be rather ticked off.

Cubase is a leading composer/writer DAW because it has really good MIDI editors, capable Logical Editors, and VST/i instrument hosting flexibility. If they start breaking this…I’ll be tempted to just pull out the old ATARI ST or Falcon and hook it up to a Bidule host for things MIDI/VSTi, and use a much leaner DAW than Cubase for the audio side.

I advocate for keeping and further developing both track types…both are great, just depends on what ya need :slight_smile:

If I understand your statement above…

I believe multiple busses can be supported via Instrument Tracks in a similar way as hosting them in rack mode, if the plugin is written to support multiple outputs.

You can still connect to the instance with MIDI tracks if desired (and eventually freeze and move the part by just stacking it on the one instrument track with output set to ANY…from there the track will even unfold into ‘lanes’ that will organize the parts so they aren’t all stacked up in an overlapping bundle). For some instruments and song writing styles, it makes perfect sense, and is a great workflow. Sadly, the Logical editors don’t work as well/easily with multiple parts stacked on a single track.

One thing I do use Instrument tracks for pretty frequently are Groove Agent setups. For this particular plugin it makes sense, and Instrument type tracks work rather well for me.

Occasionally I want to split off individual kit pieces to their own bus so I can apply VST or external effects to them. Most of the time GA has more than enough to do the job internally, but of course there are times when it’s nice to give something in the kit his own bus.

11

There was a fair bit of confusion about this point in the original thread, so I’ll mention a couple of things on the subject of instrument tracks vs. the instrument rack.

  1. Everything you used to do with instrument rack can now be done with instrument tracks.

From the discussion in the original thread it is apparent many people are not aware of the changes Steinberg has made to instrument tracks in recent releases. They have steadily been making improvements in instrument tracks, and one can now do everything Cubic mentioned with instrument tracks instead of the instrument rack. It’s easier to use instrument tracks to do simple things, but you can now use them the same way you’ve always used the instrument rack if you need to do more complex things.

  1. Steinberg can never remove the instrument rack.

Regardless of whether you use instrument tracks or do things the old way with the instrument rack, Steinberg must leave the instrument rack in place in order to allow users to load old projects which used the instrument rack. There is no need to worry that they will someday remove it. Even if they wanted to, they can’t.


By the way, the title of this thread is misleading, since the topic of this discussion migrated from “the instrument rack vs. instrument tracks” to another topic: “using instruments monotimbrally vs multitimbrally”. I mention this because I think Cubic might have been replying to the title of the thread rather than the subject actually being discussed.

12

I’m with Brian all the way.
Rack instruments, yeah…

13

I try Instrument Tracks with each release. I love them, and use them pretty often for a long list of reasons. Yet, I still cannot find the following…

  • How do I get MIDI Mixing faders for each MIDI channel on the mixing console?


  • Where are the MIDI Sends?


  • Where are my custom device panels (tab is there, but they no longer work, nor produce the device automation tracks)?


  • How do I isolate Instrument Track lanes/parts with the MIDI Logical Editor?

…

For what it’s worth, I’d use instrument tracks more often if there were Duplicate As MIDI Track, Duplicate as Instrument Track, and Lane Duplication options. I rarely want a fresh plugin instance of an instrument, with a new audio bus, when I duplicate a track (or section thereof). Instead, I usually want to run logic on it, then move, or connect the results to some other instrument variation/voice/articulation.

AND

If there were Create MIDI Tracks from Lanes and Create Instrument Tracks from Lanes options. It’d be nice if they have an option in Cubase Master Settings to connect back to the same instrument track’s plugin instance, but I’d still be OK with it if their outputs weren’t connected to anything at all.

AND

If the MIDI Logical Editor also had a “Part Name or Lane” filter.

AND

If the Lanes had a way to set independent Channels.

AND

If grooves/quantization/humanization and such could be applied to specific lanes/parts.

AND

If lanes could be independently Frozen/Merged/Etc.

AND

If tracks got a quick and easy MIDI channel input transformer in an easy to access place on the track inspector (As opposed to needing to go several clicks deep to configure global or local transformers, or apply them to an insert slot); thus, making it easy to control which lane recording will go into without fiddling about on the controller itself when playing something in.

…

Most of my wish-list would be reinventing the wheel however, since working with separate MIDI tracks in Folders, and taking advantage of Rack Mode plugins works quite well.

What I’d rather have at this stage is:

An option in Logical Editors to arbitrarily create some types of events.

More/better curve types in the Key-Editor (for working with CC lanes or Note Expression Windows), and for drawing in the Automation lanes.

Ability to launch specific track and/or mixer presets with key-commands, or via remote. We can open a preset browser that waits for us to choose, but is there a way to go one step further and pick a preset by name, or from a registered list?

Improved XML score import/export. In particular, an option to import terraced dynamics as Cubase interpretive score symbols that respond to the expression maps. As with terraced dynamics, it’d be nice if we could locate mis-labled symbols and have them convert to the proper expressive counterparts that work with the expression maps. It is super annoying to have to go through the whole piece, delete them, and replace them with the interpretive variants, and the Logical editors can’t get at those event types to automate the process of transforming them, or to insert a relevant CC.

Some minor tweaks to the drum mapping system, so it’s easier to connect to more than one instrument/plugin from the same map. I can do it, but it requires an XML hack with a text editor.

Improved interpretation of line/slur score events. I.E. the ability to automatically send a MIDI event at the end of the line. Example: When slur starts, send legato CC68,127 when it ends send, CC68,0.

A Logical Editor specifically for the score editor. Having this could save so much time…really. Even if all it does in early stages is offer search and replace for a limited range score events, it’d be a great start.

Some kind of marker/container system in the automation lanes, so Logical Editors can do more with them. And more things Logical Editors can do to data living on automation lanes.

More event type access, and filter types in the Logical Editors.

More more options on what can be done to events in the Logical Editors.

More event type access, and filter types in the Logical Editors.

Did I say more filter types in the Logical Editors?

14

If you need a midi track(s) for an instrument, then create it. It’s as simple as that. The advantage to creating the instrument via instrument tracks is you don’t have to create the midi track if you don’t need it. If you do need it, then create it. There’s no downside. That’s the important context that has been lost by extracting this discussion from the original thread.

15

I agree, and I’m not trying to pick a fight with you here. I am merely pointing out that…

You can’t do everything equally as well with both track types.

I am only pointing it out to help others understand that there is no RULE. I’m going on with reasons and causes for choosing one setup or the other for given situations. Which does your personal situation require?

Each have work-flow pros and cons, and BOTH types need more attention and development. A new button for discoverability to novice users takes a back seat to improved documentation for things as they already are, bug-fixes, and additions or tweaks to existing power-features in my personal opinion. Hey, I had to poke and peek, and read manuals to learn how to use it, it was no big deal.

So now, I can find bugs or work-flow gaps in each release in less time than it takes the ‘novice users’ to figure out how to unload an instrument in a rack. Priorities…

There aren’t really any ‘rules’ that we should be throwing our Multi-timberal setups away in favor of some new-age workflow that frankly is just more nested layers of the same-old/same-old.

You can’t do ‘everything’ with Instrument tacks that you can do with MIDI tracks, and vice verse. Or perhaps I should say, you can get the same sonic results with either type, but the work-flow and steps involved can be vastly different.

All of this came about over a request to add a button to the Instrument Rack, for ‘discoverability sake’. Then we talked about documentation issues. Priority levels for making such changes, etc.

Then it grew into discussions on syntax and consistency across an applications design. Semantics. Behavorist vs Cognitive vs Constructivst Learning Psychology, etc.

Then the idea came up that certain options and workflows are rare, and not as important.

So here we are, in a split-off thread.

We’ve been asking for things in my wish-list above for over a decade. Still waiting.

We’ve read the manuals cover to cover, found work-arounds, even hired interns to spend hours a day manually fixing things that we SHOULD be able to do with 7 line scripts.

So…a new button in the rack to ‘delete instruments’ with a click would be nice, yes; however, many of us are still stuck with several hours of tedious manual labor after importing a score. I bet we get a WHOLE NEW GUI before we ever get the little tweaks and bug-fixes that could really save us major amounts of on-project labor/time/money.

16

Right…nobody said you can.

I think there’s a misunderstanding here. You seem to be debating midi tracks vs. instrument tracks. I don’t know where that topic came from. I was discussing adding instruments to a project by one of two means:

Either

  1. Adding an instrument track to the project window
    or
  2. Adding an instrument to the instrument rack

In other words, as it says in the thread title: instrument rack vs. instrument track.

Obviously you can add a midi track, if necessary, to the instrument regardless of which of these two methods you used to create the instrument, but that’s irrelevant to the topic in the original thread. Nobody claimed an instrument track was equivalent to a midi track plus an instrument track, so I’m not sure how you got off on that tangent, but the bottom line is you’ve been arguing with yourself :slight_smile:.

17

And you keep egging it on my friend :wink:

I’m not ‘arguing’. I’m attempting to collaborate over a topic.

I’m aware I can connect MIDI tracks to plugins hosted in Instrument tracks. Previous posts of my own pointed that out already. Again, we’re getting into differences in work-flow, and where a user is likely to head first to add instruments. I’m also well aware of dozens of bugs, work-flow problems, and actual sonic issues if you pick the wrong method at the wrong time. Does it matter where you go first? If so, why?

There are still differences in using the Rack (F11, or using the new right margin in Version 10), and adding things through the track inspector, or right clicking in the project and doing “Add Instrument Track”, then clicking a preferred plugin. Or, even using track presets, or importing tracks with settings applied, and on and on. There are workflow and power-user advantages and disadvantages to either approach.

Sigh…I can start all over again and make another 10 posts about the Rack itself…and the many sub-features it provides access, irrespective of the tracks types communicating with them. That rack also lets us do all sorts of customization to individual VST controls, and then some.

YES, I understand that you were initially stating these things in regard to a novice just diving into Cubase. The context isn’t lost on me, but the possible influences of discussions like these on future Cubase, as well as third party plugin development isn’t lost on me either. Nor is the whole issue of learning psychology, product documentation, and what’s in store for future generations of DAW users.

It is NOT RARE to use the instrument rack. We use it so much, that Version 10 gave us a big fat right frame for it.
It is NOT RARE to put things in ‘rack mode’ rather than load them as an addend to ‘instrument tracks’.

Any RULE that implies we should have 121 instances of HALion, ARIA, Kontakt, VEP, etc…working ‘monotiberally’…when 3 instances in rack-mode with hosted sounds directed to specific buses we prefer will do, just doesn’t make sense to me.

The fact still remains, every time you make a fresh Instrument Track, it sets up a fresh new plugin instance to contend with, with a new audio bus, which either has to be managed independently, or routed into ‘group tracks’ (and routing them into group tracks blows the ‘better thread management rule’ out the window, since the group assigned to ‘merge bus streams’ becomes the new point where the DAW has any control at all over thread-management). If you want to control said instance(s) internal mixing matrix, you’ll require another half a dozen steps to get that kind of mix-down. It still impacts how Cubase arranges things on the mixing console by deafult. It impacts the approach one takes to automating controls in the plugin. It changes the range and power of using high level visual editors, or deeper low level advanced editors.

Users need a good cognitive grasp of the OPTIONS. There are many ways to eventually build that cognitive basis. I have no problem with GUI tweaks that can help accomplish this. I do have a little bit of a problem with GUI concepts that, perhaps intentionally, discourage it.

Yes, how you scale things and hit the proc-amp software of most plugins (that first CC7 and CC10, or alternatively, the corresponding VST automation entry for particular instrument slot’s amplitude/panning that these old MIDI events would drive) does matter in multi-timberal plugins. Plugins ship with default settings all over the place, and they impact the scale of expressive data. Novices still need to read MIDI and VST primers. They still need good manuals. They still need good cognitive grounding to understand OPTIONS. They can learn them as they go…as we all did. We’ve got bigger fish to fry than nit-picking GUI cosmetics.

I’m not here to ‘argue’, but rather to help anyone who browses this thread that doesn’t already know…

There are OPTIONS, each with pros and cons. There is no RULE.

18

P.S. GlenO,

I understand the desire to encourage users to automate via VST directly as opposed to old school driving things with MIDI events.

I understand plugin developers wanting the DAW to do more, so plugins are simpler and leaner.

I understand where Instrument Track philosophy is headed (better resolution of control, and then some).

Problem is…it’s not quite ready yet. Things for the newer Instrument Track type are still difficult to get at in many cases. Plugins haven’t yet caught up on the design and work-flow philosophy. The instrument track type isn’t mature enough yet. The logical editors can’t get at most of it yet. Multi-platform/app sharing issues. Yadda yadda, and the list goes on.

Eventually, maybe we’ll get there…but until then, a lot of really old plugins/concepts/work flows are still king. Users with professional DAW and Sequencing aspirations…new or old…in my opinion…need to understand this. Hence, why I like to ‘argue’.

19

The major downfall of Instrument Tracks is that you can’t duplicate the tracks in the Arranger track list without instantiating a copy of the plugin on the source Instrument Track.

I like to work by playing in a part, muting that track, and then duplicating the original track (using the macro that duplicates the track without duplicating its contents) so that I can try out alternate versions of the part. I can’t do this with Instrument Tracks.

Yes, I know that I could use Track Versions instead of duplicating tracks to try out different versions of a track. But it’s just much clearer to have all my alternate parts/tracks onscreen at once so I can easily see which tracks to mute and unmute while I am trying things out.