msmcleod

It depends on what you mean by performance. It will take longer to open 3 input ports than 1 input port. If you have "Always open all devices" checked, this is done once, otherwise it's done on demand when you arm a track. Once the ports are open however, there is no difference in performance.

Yes - this is to get them set up for writing to when recording. A reasonably sized file / buffer for each audio input port is needed to ensure glitch-free recording. The earlier this is done, the better really - waiting until you actually hit record would be problematic if you wanted to manually punch in for example.

I wonder if the blank areas are simply notes that haven't got a corresponding entry in the drum map? Might be worth sliding open the PRV, and seeing if there's any extra notes unaccounted for.

I'm not aware of any limit as such. I use 32 ins / 34 outs without issue (RME Digiface USB using USB 2.0), however the more input ports you have open, the slower some operations will be such as arming tracks on the fly. You can mitigate this to an extent by enabling "Always open all devices", which will open them all on project start up, but that's doing is moving the wait to the start. This is the best option however (IMO) if you always use a lot of inputs. Really, the best thing to do is only have the inputs checked in preferences that you actually need. Quite often I leave mine at around 8 inputs, and only enable the rest if I'm actually using them. TLDR : Opening each audio port for recording takes a up to a second or so (depending on the interface/driver), so think about which time is least of an issue for you, and set the options accordingly. I've never found the number of outputs to be an issue or cause any additional delays. FYI - I've recorded 32 simultaneous tracks on a 2GHz "silent" PC (it's around the size of an old audio cassette case), through USB using the RME without any dropouts or glitches. It was a USB 3.0 port, but the AFAIK device is only using USB 2.0 speed.

FYI - Markers are always added to the active arranger track, and will overwrite anything that is there already. If you've already got arranger sections marked out, create a new arranger track first.

Just be aware guys, this is a holiday weekend in the US, so there will likely be a delay in getting through all the applications / NDA's.

I hated comping when it came out, but if I'm honest, it was because I really didn't understand it - I'd been using Sonar/CbB like it was CWPA 9 for years. Once I watched a few tutorials it became much clearer what was going on, and now I use it all the time for guitar solos, drums, and sometimes vocals - I stick it on loop and record several takes. For anything else, undo, rewind, re-record just like I did in the tape days. I find for most things this is far quicker than painstakingly editing stuff.

If you bypass the effects rack, then all of the effects will be bypassed - no getting around that. Two other options, if you want to keep the effects in the same track/bus: 1. Move some of the effects into an FX Chain, that way you can bypass the whole chain while leaving fx outside the chain as they are. The downside is you'll need to open the FX chain, then double click on each effect to access it. 2. Use assignable controls/groups: make the first assignable control the bypass of each effect, and add them to the same group. Bypassing one effect will bypass them all. The downside here is: (1) it's laborious to set up; (2) you need a separate group for each track.

The PRV has it's own filter button. AFAIK this is essentially a separate feature to the Track Manager, although it should respect the existing hidden status. It's not really about keeping the PRV in sync - it's a different beast to the Track View / Console View, as it's already filtering out audio tracks / aux tracks / buses - what it should be doing is applying its filter on top of the currently visible tracks. What isn't clear is what takes precedence... it seems to be taking it's cue from the Tracks View, which makes sense. But if the track is hidden in the Console View, but not hidden in the Tracks View should the track still be visible in the PRV? You may of course be just seeing a bug in the PRV filter in CbB. The Track Manager button required a bunch of reworking of the code behind the scenes - some of it got backported to CbB as it did fix some bugs, but it didn't get everything because the feature itself isn't there.

Only with heavy compression, as an "after the fact" parallel compression technique - worked pretty well to be honest.

FYI - the new Sonar has a new Track Manager button on both the Track View and Console View, which: 1. Allows quick access to your per-project Track Manager presets - i.e. they're listed in a drop-down menu 2. Can toggle the hidden state of all tracks 3. Gives a clear indicator as to whether any tracks are hidden 4. Allows you to quickly toggle the TV/CV sync state without having to open the track manager We can take a look at the PRV anomalies - it sounds like there's some weird conflict going on between PRV filters and the track hidden state. A more enhanced version of the Track Manager is likely on the cards at some point in the future - we started initial discussions, but has not been fully designed or scheduled yet.

It's not clear exactly what you want to use the nanopad for? I've got one, and I've used it for a couple of uses: as a drum trigger (which to be honest, wasn't that good compared to my old Alesis SR-16 - the pads just weren't as responsive), and also for triggering cells in the matrix view. Perhaps if you elaborate on what you intend to use it for, we can point you in the right direction?

Variants of the AI code can be found on git-hub (i.e. it's free), and I'm pretty sure a bunch of commercial implementations are based on this, only differing in the training data they've used. I've not seen the BandLab code however, so I can't speak for that. There are some extremely useful applications of this technology, depending on how you've trained it. For example: - Being able to split up drums when you've only recorded with 2 or 3 mics - Removing/reducing bleed from other drums... in fact removing/reducing bleed from any recording. - Being able to tweak the balance of instruments - Splitting chords into separate notes I've not personally seen any examples that are specifically trained in drums so far, but it's certainly do-able using the technology. I'd be surprised if it doesn't already exist though. The only downside is the artefacts that are pretty much always present in the results to some extent. For remixing, this is normally not an issue as when the stems are re-combined, they blend almost seamlessly. Tracks in isolation however might need some treatment. When I've played around with this, I've found the best results are when you combine the separated stems with the original, using a separated stem to boost/reinforce the original part. Keeping the separated stem at a fairly low level is enough to give that part a volume boost over the original without any artefacts becoming obvious.

This is how I normally do it.

Everything you've asked for can be done already in the screenset control bar module.

BandLab does indeed have the Splitter tool, which will split a stereo mix into separate bass, drums, vocals etc. I believe Cakewalk Next will have this feature too. I'm not sure if the new Sonar will have this feature on day one of release, but I AFAIK it's in the pipeline.

As far as I can tell, the PRV will hide the track if it's hidden the Track View - at least that's what I'm seeing.

Bounce to Clip, Bounce to Track and Audio Export all use the same code behind the scenes. They're all creating clean audio files. Of course with the bounce commands, you still have the old clip objects in memory and the old clips' audio on disk to support Undo, so until you either clear the undo history (or reload the project), they'll still be taking up resources.

It depends. If it's an audio clip, and it's doing real-time stretching, then yes. It'll also likely not sound as good, as the real-time stretching algorithms prefer speed over quality. For MIDI clips or audio clips that aren't being stretched, the difference will be negligible. It also depends what you mean by resources... if you mean CPU, then the above is true. If you mean disk-space / memory, then bouncing it will actually increase disk-space or memory usage.

Simply put, this shouldn't happen. The rules are: - The envelope shapes are stored in start time order - The time base for each shape can be either in musical time or in sample time, but the time base must be the same for a single envelope stream. - The end of one shape cannot be after the beginning of the next one. Somehow one or more of these rules is being broken... finding out why / where is the tricky part. It would be useful to know if there are tempo changes in your project, and you have a sample-time based envelope. There is logic to update all sample-times within a project when the tempo map is altered (which is why editing the tempo track envelope is slower than other envelopes). I don't think there is anything fundamentally wrong with the logic here, but it's a possibility. It's more likely a bug in the envelope editor code itself.

It's worth mentioning that the new Sonar will have a completely new set of icons, and will be in a completely different format (i.e. they're vector based) So if you're planning on moving to Sonar once it's out, I wouldn't spend too much time getting the icons from CbB. It may be easier to just do a screen capture and cut out the icons you need.

@pulsewalk - yes, this looks like an envelope bug. We've seen this from time to time, but unfortunately it's almost impossible to reproduce. If you can get an envelope in a project in the state before this happens, with a reliable recipe for editing it to get it into that state afterwards, then please let us know. The only thing you can do is edit the envelope to put it back to a sensible state.

The most common reason for this is that the encoder can't write to the file, either because it's on a read-only drive, or something else has got it open.

At the moment, Articulations aren't applied to real-time MIDI input. This is something we can look at for the new Sonar, but even if we did, it would only apply to Transforms (i.e. the "Transform Existing MIDI Events" section), and not Triggers (the "Generate New MIDI Events" section). It would apply to any "active" articulations at the Now Time. This shouldn't be a huge issue, as clicking the articulation will fire off any triggers in any case. It's likely this would have to be an "opt-in" for each track via Track Properties.

C:\Program Files\Cakewalk\Cakewalk Core\TungstenTheme.fth is essentially a resource dll. It contains all of the graphics used by CbB.