hi CT,
thanks for shooting me an email - you're right, i don't check this forum very often these days, and i've been crazy busy finishing up a score so i'm just now coming up for air after several months of 16 hour days - ugh!
regarding your questions, i definitely don't know it all, and i'm constantly learning by tweaking when i get a chance. plus, what might work for my system might not work for yours, but i'll try to help where i can. "your mileage may vary" is never truer than when you're dealing with system optimization haha!
3) When you say "disable" any VEP Event Input track, do you mean just "take it out of play"? What about Unassigning the Event Input plug entirely? Wouldn't this be more beneficial (though more of a hassle) ?
just taking it out of play won't release the system resources as far as i can tell, because DP has to still be poised & ready for you to "un-mute" it. i meant that you would actually click the little blue dot on the far left of the track name in the tracks window (the "ENA" column) which disables the track completely (you don't need to change their assignment to "none" or anything like that - the blue dot is enough). a word of warning though: i learned the hard way that doing this with a VE Pro Event Input plugin aux channel will undo your MIDI track assignments which don't come back when you re-enable it, so i've stopped doing this (rough lesson to learn - had to reassign SO MANY MIDI tracks in my template haha!). but what you can do as a quick and easy way to release some resources is to disable any unused "returns" from your slaves and also hide all tracks you're not using from your mixing board. it's crazy how much better DP runs with a lean & mean mixing board. for example, i rarely disable my strings, brass, winds, or percussion returns from my slave, but i'll often keep my "STRX" (for odd VI strings like charango, ukulele, dulcimer, etc.) and "TUTTI" (for big patches like cineorch or symphobia that include several orchestral sections) channels disabled and hidden unless i actually need them.
Furthermore, does the existence of an uninstantiated plugin on a track use CPU at all, (i.e. is it better to delete unused plugins altogether and re-load them when needed, albeit again, more inconvenient) ?
i'm not totally sure, but i think that the more tracks you have, whether you're using them presently or not, the heavier the burden on DP's "snapiness". disabling them like i mentioned above, or unassigning their audio outputs will take care of most of this, but i think all those tracks add up a little bit at a time. kind of like having a bunch of kontakts loaded up with patches and purged - they still take up a certain amount of CPU and RAM per instance even when you're not using them because they need to be ready to be used, and the host automatically reserves a little bit of resources for them.
i've found that MIDI channels don't drag as much on DP as audio/aux/instrument channels do though. i have probably 400-500 MIDI channels in my DP template, but usually only around 8-10 aux channels are ever being used (most are ve pro returns). i have a folder of audio tracks pre-routed for recording stems, and a folder of pre-routed subgroups ready to be enabled and shown in the mixing board. but most of the time they don't get used and i think having them ready to go outweighs the drag they have (not much) on the system while sitting dormant.
4) I think some of my problems stem from my many aux channels, busses and stereo audio channels. Does anyone know what might be a 'safe number' of these before DP starts getting 'tired'
this is a very system-specific thing, but yes, the number of aux channels, busses, and audio channels (that are enabled and routed) absolutely has a big effect on DP. it's a bummer we can't just go subgroup and aux channel crazy yet with tons of parallel compression and separate returns for each instrument from ve pro (maybe some can with monster machines), but i find i can get by just fine with a lot less returns from ve pro than i thought i could when i first started using a slave. i used to have returns for LASS vlns, violas, celli, basses, then adagio strings, wet brass, dry brass, wet winds, dry winds, etc. etc. now it's just one return for each orchestral section. other than adding MIR Pro on my slave (which let me get rid of all the wet and dry returns and also let me offload all of my reverb processing), the key is laying down your VI volume balances with disciplined use of CC7, CC11, CC1, keyswitches, and then whatever CCs you need for mic levels in multi-mic libraries (spitfire, adagio, cinesamples). every MIDI track i use ends up with automation written before the first beat of the cue so that it plays back that way every time. i spent a ton of time creating a touchOSC template for all of my keyswitches and CCs for each library i have since they're all so different and impossible to keep track of once you have a bunch. that makes automation a lot quicker when i'm writing and i can stay "in the moment" a lot easier (no manuals or "cheat sheets" required to quickly write your automation and move onto the actual music making). so yes, cut down on your channels as much as possible while still maintaining the routing flexibility you need in order to render off the stems you need quickly and with enough separation for whoever's mixing.
5) I use SSD drives on my Mac Minis for streaming sounds, and they are stellar. Does anyone use SSDs on their Mac Pros as their WORK drive (i.e. on which you save your DP sessions) ? Would this speed up DP at all? I was under the impression that SSDs perform best (and most stable) in their "read" functions as opposed to "write"…
i use have 2 SSDs in my master mac pro (6 in my PC slave) - one houses my quicktime movies (which i cut down in size and data rate considerably, and which i also strip the audio from in order to make it run smoothly), and one houses my DP files. it probably helps you more the more audio you record along with your VIs, but i'm sure it has to help at least a little bit even if you're just using VIs. i haven't yet switched to an SSD for my boot drive (currently using a WD caviar black with a 64MB cache), but i think that's my next step. i don't think we have to worry as much these days about only using SSDs for data we need to read from (but not write to much) - i know lots and lots of people who use them for their boot drives just fine. i believe some of those issues were a lot more pronounced with the first generation of SSDs, but any advice from those with more experience (especially with "trim control" - do you need it? how to enable it? etc.) would be welcome! i feel like running the DP app from an SSD would have to help things at least a little - that's what i'm hoping!
hope that helps. good luck and hit me with any other questions you have. i'll try to check back here more often : )
matt
