David Baay

Does the instrument UI have a modulation control? If so, does it move in response to the controllers? Do you have a 'forced' output channel assigned in the track header? If not, you'll need to make sure the controllers are on the same channel as the notes. I have no experience with EastWest instruments so don't know if anything special is required to configure controller response.

If you were already at that high MIDI Prepare Using buffer setting, you might actually want to try backing it down to the default of 50ms, and going up gradually from there. Another possibility would be that tempo and note position are interacting in a way that causes buffering to fail. I have not seen this since buffering was revised, and usually only with one particular note in a whole project, but it might be worth tweaking the position of a dropped note by a tick or two and seeing if it makes a difference or tweaking the nearest tempo value before a missed note (or for the the whole project if it's a fixed tempo.). I may not have the samples you are using, but I have Sampletank 4, and could give your a project spin on my system to see if it's platform-specific, and poke around for other possible causes if the problem reproduces. Bakers will probably need to do the same to understand what's going on. P.S. In thinking about this, I was reminded of an issue I encountered when I first got Sampletank that some instruments were not playing notes above a certain velocity because the channel-mapping of velocity layers in some patch definitions was screwed up. IIRC, IK responded to my post about it, and were going to fix them. Might have been specific to Syntronik patches though. The plain text patch files could be edited to fix the problem (putting all layers on channel 1), but there were too many so I only fixed the one I was using at the time.

That's where Edit > Select by Filter comes in. - Select the clip. - Edit > Select by Filter. - Click the Select None button, then re-enable the Notes checkbox. - Enter Min and Max Duration values. and OK. - If you then look in the PRV, you'll see that only notes with matching long durations are selected. - Enter an appropriate percentage in the Event Inspector, hit Enter, and watch those notes shorten.

Ah, OK. I misunderstood "White 2A in some fx, everything are simple eq", and my search hit on IK's LP EQ. In any case. I would guess the issue is related to a specific plugin(s) whether FX or Instruments. Just having a lot of MIDI tracks should not drive up the buffering requirement. Any MIDI FX in the project?

Select the clip, then Edit > Find/Change. Or Edit > Select by Filter (uses the same dialog as Find), and then enter a percentage in the Duration field of the Event Inspector module in the Control Bar. Find/Change will only let you change to a fixed duration.

I don't think any of the Smart Tool functions are disabled by default in a new installation. But I checked, and none of the optional Smart tool functions needs to be enabled to get the level-adjust cursor, but you do have to hover over the top of the shadow somewhere to the right of the actual controller that you want to change. The Move function will let you both move and adjust the level by grabbing the top of the controller.

As scook suggested, Bounce to Clip(s) is the standard way to combine (or re-combine) MIDI clips. Alt+left-click with the Smart tool will spit a clip. Handy when you need it, and fairly hard to do accidently, but it could happen. With lanes showing, you could also inadvertently split a section of a clip by clicking and dragging in the lower half of the clip with the Comp tool function of the Smart tool, but that would always create two split points, not just one.

White 2A is a Linear Phase EQ which means it will be using a lookahead buffer. Clicking the 'power' button on the FX in the bin to disable it should be enough to check whether it has any bearing. just make sure you get all of them. The effect is not additive, but leaving even on active will drive the delay compensation which is what causes trouble with MIDI buffering.

MIDI buffering was revised a couple years ago, and those extremely high buffer settings are not generally needed. i think the default now is 50ms. But it'd still sensitive to plugins that have very large 'look-ahead' buffers. If you're aware of any 'mastering' type plugins in your project that have big internal buffers, you might try disabling them. Some have 'quality' or 'precision' settings like Cakewalk's Multiband Compressor that can be lowered to reduce the buffer size.

+1 Pretty sure I've entered a feature request for this in the past - probably before this forum existed.

Ah, yes, the jittery Now Time Cursor is indeed a well-known 'feature' of Cakewalk. I've reported it myself. But that's nothing like "when i do any action it takes a minutes to response". Incidentally, regarding the video's next point, it's working as designed that a 'confidence recording' shadow is only displayed for the current take when looping. I can see how you might want it to show everything when layering takes in sound-on-sound mode, but that's not really the purpose. Its main purpose is to give you confidence that your current input is being recorded. Personally I don't ever pay much attention to the content; so long as that 'shadow' is being drawn, and the meter is moving, I'm happy. What's needed in this case is a feature request not a bug fix.

Using a good multi-sampled drum synth, and getting natural velocity variation that takes advantage of it is arguably more important than micro-timing tweaks in making sequenced drums sound natural. That, and having elements of the pattern that evolve from measure to measure with significant pattern and kit piece changes for different sections and fills going and out of them. Plenty of drummers can and do play right on top of the beat with metronomic precision most of the time. It's their nuanced 'touch' with the resulting tonal and rhythmic effects, and constantly changing up some elements of the pattern, that make a drum part groove. Personally, I'm horribly lazy when it comes to creating distinctively different patterns for the different sections or playing proper fills, but I do better with 'touch nuance' and 'evolution' by playing in parts in real time from a keyboard as bitflipper suggested, playing parts all the way through from end to end (or at least 16- to 32-measure chunks), and avoiding too much copy-pasting. I break these rules all the time, of course, but that's the ideal. ;^) I have also dabbled in using Jamstix, and have had good results mixing Jamstix patterns into my home-brewed parts. When doing that I'll thin out competing hits, but I don't really worry too much about whether a real drummer would be able to play it; real drummers might care, but your average listener only really cares if it sounds good. Using a pattern that was meant for a different time signature can also get really interesting... but I digress. ;^)

Still curious what kinds of operations we're talking about. As it stands there isn't enough information here for the Bakers to act on.

Record a guide track of MIDI notes played in sync with beats of the audio track, select the clip and choose Process > Fit Improvisation: https://www.cakewalk.com/Documentation?product=Cakewalk&language=4&help=EditingMIDI.40.html

Not really, but a lot of project-specific content and configuration settings could have a bearing. The first thing to try would be to bypass all FX ('E' on your PC keyboard.) If that doesn't help, I would suggest creating a barebones audio project with a good number of tracks and no FX or synth plugins, enable Autostretch on all the clips, change the tempo 20% in either direction, and see how it plays. If it plays smoothly, you'll have to dig further into the glitching project. If there are problems in the simple project you'll need to share all audio preference settings, and let us know something about the hardware and interface you're running. But even a pretty low-spec machine should be able to handle the simple case.

Yes, this is an old and fairly well-known issue when simultaneously recording both sides of stereo pair to separate mono tracks. To my mind, the function is mostly unnecessary, and should just be left disabled as it is by default.

"Any action"? Can you give some specific examples? And when you say "it takes a minutes to response", I assume you mean some significant fraction of second that is just enough to be bothersome...? I find that Cakewalk's responsiveness generally exceeds my ability to drive a mouse and keyboard, but I wasn't born with them in my hands like some of these youngsters.

I have often thought that the Bakers should go through all the old CALs, and convert them to native functions with corrected logic where necessary. Seems like low-hanging fruit.

Since your screenshot has the notes scrolled out of view, I assume you mean you're dragging the velocity bars directly, rather than using the velocity tool on the note's hotspot as John described, but both methods should work about the same. In my experience, if you have a lot of notes selected and/or drag really quickly, the drawing response can be a little slow. I would say there's room for improvement here, but it may be linked to the audition feature that replays the notes repeatedly as you drag so that you can hear the result in real time. And it may be worse on slow hardware or with some audio drivers if it's related to the auditioning feature.

scook has you covered on how to do it right next time. For fixing it after the fact you're going to have to fool Cakewalk into referencing the DI audio files to the edited clips in a copy of the Amp track. This might sound whacky, but it should work, and it's the only way: - Right-click each take clip in the DI track and choose Associated Audio Files to confirm which file (especially Rec numbers) is referenced by each clip (make some notes if needed). - Save As a copy of the project with a new name to a new folder with Copy All Audio enabled, and close the project. - Go into the audio folder of the new project, and delete the Amp track's audio files (it's an independent copy, no worries). - Open the new project, and when Cakewalk complains that the Amp track's audio files are missing, select the option to Reference Files from the Current Location, select the corresponding DI audio file for that take, and confirm that the name change is okay. Do this for each of the missing files. - Open the original Project, delete the unedited take clips from the DI track, and then copy-paste the edited clips from the Amp track in the new project into the DI track of the old project. The clips in that project should automatically reference the local copies of the DI files. - Save the changes, and you should be good to go. If it turns out you need to make more edits, manually create the needed selection groups of corresponding clips across the two tracks before you edit.

All the other threads on this seem to conclude it's due to unexpected response from the ASIO driver. Everyone acknowledges RME drivers are generally among the best so that suggests some 3rd party software/driver component is interfering. You might look into uninstalling whatever driver components the onboard audio was using if it's disabled. Or do the opposite, which I usually recommend: Enable the onboard audio and set it as the default audio device for use by Windows, browsers and generic multimedia apps, reserving the RME driver for use by Cakewalk and other applications that you specifically configure to use it.

He pretty much diagnosed and solved it in the original post: "What I suspect is causing this is that I'm playing sustained notes and am rushing (see "not using the metronome" above), so starting them before the punch-in." If that's the issue, let this function as a public service announcement: when punching in a MIDI performance, set your punch point a quarter note or so ahead of where you think you're going to start playing so that sustained notes don't get lost." If the note-on is played before the punch-in, it will be ignored, and you won't get a note. If your timing is reasonable, setting the punch point a 64th early should do the trick. Or do as I suggested, and just Comp-record into a new lane and comp the parts together instead of trying to punch in.

Record levels are determined by hardware input gain/sensitivity on the analog side of the interface. This 'cable' interface may have a physical control for that, or possibly is controlled by the Windows mixer or a separate 'console' app provided by the cable interface vendor. And, of course, you need to ensure the level out of the guitar is the same as previously.

Set LinkPFSendMute=1 in Config file (AUD.INI). The default is 0, and gives the behavior you're seeing now.

Not sure it's clear from previous responses: you can drag the split point between the two takes later to create an overlap so you have something to crossfade. 5-10ms of overlap and cross-fading is all you need. Zoom in on the punch point, and set snap to .005 seconds so you don't have to guesstimate how long the fades are and you can easily get them to start and end at the same place. The cross-fade should negate the need to worry about snapping to zero-crossings, which isn't really that helpful. As I've posted many times (and demonstrated at least once), splitting at a zero-crossing is no guarantee you won't have a pop if the surrounding signal level is high - you still need a 3-5ms fade. The way you did it is fine given that you couldn't play your way up to the punch point because you had to be ready to play the change. Normally, if you were able to play the change correctly - but maybe only once in 3 or 4 attempts - I'd recommend doing multiple takes of several bars around the problem point until you get a good one, and then use the Comp Tool to create splits with auto-cross-fades into and out of the good take, and drag the split points as necessary get the cleanest possible transitions. As a MIDI guy, I don't actually do that much audio recording and editing, but it seems to me that multi-lane recording and comping capabilities make punching largely unnecessary.