David Baay

I've always thought the way 'Threshold' controls typically work is counter-intuitive, and not usually helped by the way the functionality is described. A simple way to think about it is that the Threshold is simply an input gain control, and by lowering it, you're amplifying the signal until the peaks start to run into the Ceiling. So by setting the threshold to -10dB, you're essentially boosting the whole signal by 10dB right off the bat. Here's how the Adaptive Limiter's help file puts it: "Only the signal above the Threshold is limited; all signal below the Threshold has a constant gain change that is controlled by the difference between the Threshold and Ceiling." So if you just want to limit the peaks without boosting, leave the Threshold at 0, and lower the ceiling into the existing peaks. If you want a little boost (typically the goal of Limiting), start with a less aggressive threshold. The way I typically use a limiter for a final Master is to set the Ceiling it at -0.3dB (as suggested earlier to void overs with MP3 compression or problems with D/A converters in consumer devices that behave badly at the limit), and push the Threshold down until the reduction meter shows the peaks are getting knocked down by maybe 3-5dB, and not continuously. Depending on the source material, and your loudness goals, you can push it harder, of course, but I usually just want to be able to bring the level up as high as possible without noticeably losing dynamic range or having the peaks sound 'crunchy'. If I were sending a mix to a mastering engineer, I might take the same approach, but set the Ceiling at -6dB, and only lower the Threshold to where the very highest loudest peaks are getting knocked down a couple of dB.

Hey Chuck, FWIW, any time you run into sync problems like that, it can help to have 'Set Now Time with Full Restart' enabled in Track View Options. The trade-off is that moving the Now time during playback will sound a little glitchy (i.e. not 'gapless'). Basically, it's the equivalent of quickly stopping and restarting the transport when you move the Now time.

Yes, I understood that. Just tried it, and the issue is readily reproduced here as well. I'm guessing the Bakers will get on this pronto.

Try increasing your ASIO buffer size. By default, Cakewalk uses this buffer size for offline processing (i.e. non-realtime), and some synths don't render properly with very small buffer sizes. If it works to increase the real-time buffer, you can set a non-zero value for BounceBufSizeMsec=0 in AUD.INI, and Cakewalk will use that value for all offline processing. I keep mine at 20 (960 samples at 48kHz).

Interesting that Melodyne are able to reproduce it. I would have thought there would be many reports of this on the forum if it affects all installations. I use Melodyne mainly for MIDI extraction, and have probably never tried to record with pitch-correction enabled; I'll have to give it a try.

A similar thing has been known to happen with both audio and MIDI recording... new clips are laid down a measure late in the timeline when count-in is enabled. I've never experienced it myself so have always suspected it was related to interoperability of certain audio interface drivers with Cakewalk. If you're using WDM driver mode, maybe try switching to ASIO or vice versa. BTW, what sample rate are you running? If it's 88.2 or 96kHz, possibly some subroutine is not accounting for the doubled number of samples in a measure vs. more common 44.1 and 48...? Just a thought.

Are there any that you use in every project? Related to this, it also occurs to me that if you're using project templates that originated in some ancient version of SONAR, you might want to build some new ones from scratch starting with the Blank or Basic project template. The same might go for old track templates that you use frequently, especially anything complex like a drum template that includes the synth, multiple outputs, aux track with routing and plugin for parallel compression, etc. The fact that you've experienced this so consistently across many versions of Cakewalk/SONAR and (presumably) many PCs with different O/S and interfaces, while many others experience it rarely or not at all suggests you're consistently doing something procedurally or with project content that precipitates the problem.

I've generally only encountered this kind of thing with specific soft synths or FX plugins that don't 'play nice' with Fast Bounce. Sometimes it can be fixed by increasing the real-time ASIO buffer size which is used as the default 'chunk' size for offline rendering when BounceBufSizeMsec=0 in AUD.INI. Or you can set a non-zero BounceBufSizeMsec= value (I keep mine at 20). In other cases, the synth/FX plugin may have an offline render mode that has to be set in its UI. Another problem I've encountered in the past involved FX plugins that don't clear their own internal buffers on stop, and 'spit' some noise when playback is restarted. This would sometimes manifest in exports as well. I haven't run into that issue for a while, but one setting that might be relevant would be "Always Stream Audio Through FX' in audio Playback and Recording preferences. You might also look into enabling Plugin Upsampling (or disabling it if already enabled) for any plugins that you find are consistently causing a problem. Bottom line: If you have a project that does this consistently, save a copy of it and start removing things until to find the trigger - most likely a plugin.

Sounds like conversion to Groove Clip didn't happen for whatever reason. Does the clip have beveled/rounded corners? Check the Groove Clip section of the Clip tab in the Inspector with the clip selected to see if 'looping' is enabled, and make sure the 'Beats in Clip' value is correct (should be 4 for a single measure of 4/4).

FWIW, I almost never lock anything. I add descriptive filename suffixes to periodically saved copies of a project as it evolves so that original recordings and progressive edits can always be recovered from an earlier version.

Others who upgrade their machines frequently and/or have a long history with Cakewalk and do extensive customization of their configurations might have more involved processes, but here's the simplified version: - Install drivers for audio and MIDI interfaces. - Install any legacy SONAR plugins/content you might have access to through the old Cakewalk Command Center that isn't part of CbB. - Install CbB. - Install and authorize all 3rd-party plugins (this is typically the most time-consuming and painful part) - Copy your projects folder to the corresponding location on the new machine. - Make music. If you've done a lot of customization of the configuration on your old machine, you can consider copying some things over (e.g. aud.ini, cakewalk.ini, ttsseq.ini, master.ins), but for optimal performance and stability, it's probably best to go forward with a default setup, and reset preferences as you encounter them. I usually only transfer some very specific aud-ini settings, and migrate my master.ins (MIDI Instrument Definitions for hardware synths). I also bring over the Cakewalk Content folder because it contains decades of custom and archived content. I keep it in a non-default location so I also copy the relevant branch of the Windows registry to the new machine, but that probably wouldn't apply to you. There are also procedures for migrating plug-in layouts and presets; I don't generally do a lot of customization in that area so I don't bother. So long as you keep the old machine around, you can always refer back to it, and migrate additional content/customizations as needed when you find things are missing or not working as expected in the new environment.

I've always enabled LinkPFSendMute for more intuitive behavior since the performance space and control room are one and the same for me, as is probably the case for the majority of users. But since changing the default would foul up users who have come to depend on it being disabled, giving access to it from the UI would be helpful, if only to help make users aware that the option exists. It might also be helpful to explain the use case for having it disabled in the Ref. Guide.

Like me, I think Klaus thought you were talking about locking the PRV. Clip-locking is a property of clips, and clip properties are only accessible from the clips pane and the Inspector. So, no, you cannot change clip-locking status from the PRV.

I would think Bandlab Support should be able to help you get access restored if you know what the original e-mail address was.

When zoomed out, the Clips Pane will usually show pretty clearly where 'clumps' of MIDI data exist unless it's extremely sparse. MIDI clips will usually only have long stretches of no data if they were recorded in a single pass in real time; parts entered in the PRV will usually end up in separate clips when there's more than a measure of empty space between events. It might be worth taking the time to split and trim long clips to eliminate 'dead air' and facilitate arranging

No, this is not currently possible. You could limit what notes get passed to the synth using a Drum Map so that only notes in the scale make sound, but then you wouldn't be able to easily go outside the scale. You'd be able to place the notes in the PRV, but you wouldn't hear them until you modified the map.

You can get the desired effect in Cakewalk by routing the output of the MIDI track to a Drum Map that only passes notes that are within the scale. I do this when composing for a music box so that I won't use notes it can't play.

Enter an RPN Kind of event, and change the Data value to 0. When you save the change, it will end up reading as Pitch Bend Sensitivity. Cakewalk does this with other commonly used control events like CC64 which presents as '64-Pedal (sustain)' for ease of recognition.

'Concrete Limiter' and 'PC4K S-type Expander/Gate' modules were available as paid add-ons before the shut-down. I thought Cakewalk owned them, so not sure what the obstacle is to bringing them back.

Yes, 'Zero Controllers when Play Stops' (mentioned in the list) in MIDI preferences will do that with synths that use Modulation and/or Expression to control volume (the classic example is Garritan/Aria Player). If you don't want to disable the setting, adding Modulation (CC0) and Expression (CC11) events with nominal values at the start of the track for Cakewalk to ' search back' on will take care of it.

It's hard to see exactly what's going on with the screenshot cropped so tightly, but my first guess would be the track scale is maxed out. Double-click the scale between the tracks pane and the clips pane to zoom out fully.

Thanks. Hope it helps. There are some more obscure causes of 'no sound', but those are the biggies, and should help find the problem, even if it's not mentioned explicitly. I'm curious to hear what you find. P.S. I should probably add "No tracks/buses soloed". ;^)

Troubleshoot 'no sound' as usual, starting in the synth UI, and working downstream (Audio chain) or upstream (MIDI chain), depending on what you find: - Amp/Monitors are on, volume is up, and sound from some source other than CbB can be heard. - Hardware Out bus meter in CbB shows signal (drag divider in Console View left if hardware outs are not showing) - Master Bus meter in CbB shows signal. - Synth /Instrument track meter shows output. - Synth/Instrument track Volume is up. - Synth/Instrument track Gain is up. - Synth volume, modulation and expression levels are nominal, and not getting zeroed by 'Zero Controllers on Stop'. - Soft synth UI audio meter shows signal (may have a virtual keyboard or auditioning function you can use to test) - A patch is loaded in the soft synth and is compatible with the pitch range in which you’re playing and channel on which your keyboard is sending. - Soft synth UI shows MIDI input (if it has an indicator). - MIDI track Output is assigned to the synth in the rack. - MIDI track meter shows MIDI output activity. - MIDI track volume fader is up. - MIDI track's Input Echo button is lit, either by being enabled manually or automatically by Always Echo Current MIDI Track in preferences (the default). - MIDI track [output] Channel is unassigned (no forced output channel; events are passed on keyboard's channel without modification) or matching the synth. - MIDI clips/lanes are not muted. - MIDI track records MIDI when you play, whether you can hear the result or not. - MIDI track's Input is assigned to the port an channel (or Omni) on which your keyboard is sending. - The recorded notes are in a pitch range that works with the loaded synth patch, and velocities and durations are nominal ( a synth patch with a very slow attack may not respond audibly to a staccato note). - MIDI I/O activity monitor that CbB inserts in the Windows System Tray shows activity on both sides. - Keyboard is powered up and MIDI indicator on keyboard (if present) shows activity in response to performing. - Keyboard output channel matches MIDI track Input channel if not Omni.

Yes, I believe so, but according to this reference, RPN 101 (MSB) should come first: http://www.philrees.co.uk/nrpnq.htm It's been quite a while since I messed with RPNs. My first post to the old forum c. 2006 was about TTS-1 not responding to pitch bend. ;^)

Manitou Springs, CO, USA. The old forum showed location under avatar, which was handy. Pics, or it didn't happen...