David Baay

100ms is a lot although I recall Noel recommending an upper limit of 200ms at one time. Mine's been at 20ms for years without issue.

If CPU Conservation Mode fixes audible 'stuttering' that would suggest some interaction between graphics processing and DPC latency, audio drivers, USB hardware/drivers or some other system hardware/driver issue. I would start by monitoring DPC latency using the free LatencyMon application, and see if the stuttering corresponds to high/spiking DPC latency: https://www.resplendence.com/latencymon

I would suggest using just one track routed directly to Main Outs with the mute grouped in opposition with the Master bus mute. Then put your reference audio in lanes of that one track. Lanes have a built-in exclusive solo feature which simplifies that part of the process, and using a single track greatly simplifies the setup, and reduces the plugin load. Not sure how this will work as a template due to grouping the mute with the Master bus, but it will be much simpler to set up manually if necessary. I use this setup to A/B bounced mixes against the 'live' mix on the Master bus.

Recorded audio, frozen synth audio, bounced synth audio or MIDI? If some sort of audio, make sure the track you're fading is the one you're listening too. If MIDI, you'll either need to render it to audio first or use a MIDI Volume or Velocity automation. EDIT: Or automate volume on the Master bus, which will work regardless of the source, and is SOP when fading a full mix.

Did a quick test, and could not reproduce that; a sequence of 32nd notes converted fine for me. 16 steps per quarter-note 'beat' is 64ths. That's not an option for conversion from MIDI (strangely), but you can create an SS clip with 64ths from scratch. Can you share a copy of the MIDI?

Options > Meter Options > Show Track Peak Markers I'm not aware of a shortcut that will toggle peak markers on/off, but it's possible. You can also right-click a track/busand enable peak markers on that one track/bus; Options menu does it globally.

- Select All - Expand the Audiosnap section of the Clip properties tab in the Track Inspector. - Check the Enable box. - Set the Follow Option to 'Auto stretch'. - Check the Follow Proj Tempo box. The above settings can also be accessed by hitting Alt+A to open the Audiosnap 'palette'. Now you can freely change the initial tempo, and clips will follow the tempo change while maintaining pitch. By default, the stretching is rendered by the Groove Clip algorithm which is fine since you're going to change the tempo back, and don't have to worry about quality of the temporary stretching. After recording the new part(s), Select the new clip(s) and enable Auto strech mode on those as you did above, and then change the tempo back. Now you can disable the Audiosnap on the clips that had to be slowed down, and they will be back to their original condition. Try out the different 'online' (real-time) stretching algorithms on the new clip(s) to see which yields the best result, and then set the matching algorthm for offline stretching and Bounce to Clips to render the stretching permanent. Or Bounce to Tracks if you're not ready to commit or you want to try one of the offline Radius algorithms that doesn't have an online equivalent.

It's the same in the Prochannel tab of the Track Inspector. Click the >> arrows or double-click the graph in the compact display to fly out the full UI, But, yeah, if the Track inspector isn't open you're out of luck in the TV.

Firt step is to check Deferred Procedure Call (DPC Latency). This is a measure of how quickly the system can respond to a request from the audio driver to process a buffer of audio. It's typically measured in microseconds, and should ideally stay under 200us (1/5 of a millisecond) to allow running small ASIO buffers for low latency. It's very common on laptops that Bluetooth and WiFi drivers play hell with DPC latency, occasional crackles/pops in mild cases or severe distortion. 'Zipper' noise is usually associated with changing volume, but I don't think this is what you're referring to...? Download LatencyMon (https://www.resplendence.com/latencymon) to measure DPC latency, and if it's running over 300-400us all the time and/or spiking over 1000 intermittently, go into BIOS at startup, disable onboard Buetooth and WiFi systems, and see what how it looks. Sometimes just one or the other is the main culprit.

If there's no meter activity when armed to record, that would suggest the driver isn't opening the input port. If that's the case, I could see how switching to a different input and back would re-open the port. You might experiment with the Always Open All Devices setting in Audio > Playback and Recording.

When input monitoring is failing, do you get either or both input or output meter activity on that track? Really sounds like an interoperability issue with the driver.

Are you using WDM driver mode to have both interfaces available, or only using the Layla PCI in ASIO mode currently? If so, I'd recommend trying ASIO mode with just the Focusrite interface, and see if ithe problem persists. Years ago I had an issue with input-monitored tracks going silent on rewinding after recording a take with my EMU 1820m PCI. In that case, toggling the audio engine or just restarting the tranport would bring them back to life, and stopping the recording with R instead os Spacebar before rewinding would avoid the problem entirely. Something seemed to be causing the audio driver to close the ports on rewind from stop. Have not seen the issue since the 1820m died, and I started using a MOTU PCie interface.

If their are FX in the track, you can't know that it's echo that's failing. If the FX aren't passing audio, there's nothing to be echoed out. You implied earlier that is can happen with no FX in the bin. Are you sure about that?

Yeah, guess I was little to vague with "enable Audiosnap in Autostretch mode": In the Audiosnap section of Clip properties: - Check the Enable box. - Set the 'Follow Option' to ' Auto stretch' - Then check 'Follow Project Tempo' If the follow option is anything other then Autostretch, the clip will immediately try to confirm to the timeline tempo according to its clip tempo map (which we're not using), and will typically 'go into chaos' as you say. Autostretch mode doesn't do anything until you change/delete tempos.

To work one track at a time, graphically, set the PRV to Show Controller Pane in the View menu. Double-clicking the clip to open it in the PRV should then show all controllers as separate lanes in the Controler pane where you can swipe across controllers with the Erase tool to delete them without affecting notes. https://cakewalk.com/Documentation?product=Cakewalk&language=3&help=Views.05.html Alternatively, you can select tracks/clips, go to Edit > Select by Filter, and check boxes to select only the controller number you want to delete, then hit Delete on your keyboard. You could also use this method to delete controllers from all tracks that have competing Modulation and Expression controllers in one go, but take care that you don't include a track that has only the one controller type. The page I linked earlier does not explicit state that CC1/2/11 affects brightness as Jim suggested, but that might be true, I haven't confirmed one way or the other., but have not really noticed that in the past. I would probably just keep whichever controller is at the highest average level so that you get a good, strong level out of every track as a starting point for mixing.

I just checked, and the 'move' cursor is not interfering with deleting the marker as described here. Possibly you've bound the Delete key at some point for a special purpose...? Or you're trying to use Del on the NumKey pad instead of Delete on the main keyboard...?

An ARA-enabled clip (Audio Random Access) will display 'RFX' (Region FX) in the upper right corner. Groove clips will have beveled/rounded corners, and locked clips will have a lock icon in the upper left corner. You might also check for Audiosnap being enabled under Clip properties in the Track Inspector. If the clip is in any of these special modes applied, slip-stretching will not be allowed. In the case of MIDI, Step Sequencer clips cannot be stretched, either.

Glad to help. Garritan is somewhat unique in using Modulation to control volume. IIRC, they added support for CC11 at some point to be more compatible with GM conventions. CC2 (Breath) also does the same thing. You might want to find out what characteristic of the sound is controlled by Modulation in Spitfire, and see if it's possible to emulate that with a different controller. Here's a summary of controller implementation in Garritan: https://usermanuals.garritan.com/GPO5/Content/controls.htm EDIT: I should add, if the parameter controlled by Modulation in Spitfire has a counterpart in Garritan, you can copy the Mod controllers to the appropriate controller number in the PRV, and then delete the Mod controllers.

Maybe more precise to say say 'offset' the existing MIDI. In other words, 'lie' to the synth, making the timestamps later so the audio renders later without actuallly delaying the audio output. So you could offset the existing MIDI while passing live input MIDI through immediately, and have both in sync with plugin-delayed tracks.

EDIT: Nevermind. Had missed the first of your two updates.

That should still work in CbB. Check that clip isn't locked, Groove-clip-enabled, Audiosnap-enabled, ARA-enabled, etc.

I didn't watch the video, but for a project with tracks already matching a constant project tempo, the procedure is simple: - Select All - Show Clip properties in the Track Inspector, and expand the Audiosnap section. - Check the Enable box, set the Follow Option to Autostretch, and check the box to Follow Proj Tempo. - Change the tempo.

So I got the same stuttering effect here, and noted it was happening particularly on strings and in places where the tempo wasn't changing. I looked at the controllers in the PRV, and found both Modulation and Expression controllers following the same pattern but at different average levels. In Garritan, Modulation (CC1) and Expression (CC11) both control the Expression parameter, so the controllers are competing with each other, and rapidly switching the level up an down since the curves are at different levels. Deleting either set of controllers eliminates the stuttering.

Actually pretty straightforward: - Check the box to Enable MIDI Out when inserting Jamstix - Insert another MIDI track, and set it's Input to Jamstix. - Leave Input Echo disabled. - Arm the MIDI track to record, and hit R. I wouldn't be surprised if there's an option to drag MIDI out of the Jamstix UI, but I've always used the above method because I just like to watch it do its thing in real time, and listen for parts that I might want to modify, move, delete, copy, re-arrange, assign to a different synth, etc. After recording, you can drag that clip to the Jamstix track and switch it to MIDI Playback mode, or take parts of it to different tracks or separate lanes of the of the Jamstix track... whatever works. EDIT: Looking back at some of the projects where I used it, I've usually just set the input of the Jamstix MIDI/Simple Instrument track to the Jamstix MIDI Out, and recorded directly into that track. So long as you leave Input Echo disabled while Jamstix is in Jam mode, that works fine.

Are there tempo changes in the project? Possibly Aria Player is not handling them as well as a Miroslav, though I would expect it should. If the stuttering persists after freezing/bouncing to audio, that would take the audio driver/hardware out of the equation. It could also be that some particular controller in the MIDI is causing problems with Garritan. If you want to share the Garritan version of the project somewhere, I could give it a run on my good-but-less-than-state-of-the-art system to see how it behaves.