brundlefly

I've never seen that before which makes me think it's related to UWP driver mode for MIDI. If so, try changing to the default MME mode under MIDI > Playback and Recording. So fas as I know, there's no performance or functional advantage to using UWP mode with hardware connections. It's main benefit is supporting Blutooth. My old multiport MOTU interface driver only exposes a single port in UWP mode, and there ar eno errors reported, but it doesn't work.

It's been a long time since I messed with ACT, but if you're using a single MIDI port for both Control Surface and keyboard controller functions, I think you need to distinguish which channels are intercepted by ACT, and which are available for musical/performance data input to tracks. As it stands, it sounds like ACT is intercepting all channels.

Not sure exactly what this means, but you can do all of the following: - Have a single track record and echo MIDI from multiple input ports (choose Omni or see 'Manage Presets' option in the MIDI Input pick list). - Have multiple tracks record and echo from the same MIDI port (pick the same Input port for both tracks - with or without differentiating channels). - Have different tracks record and echo from different ports, exclusively (pick a different port for each track's Input - with or without restricting the channel ). What does this mean in terms of where exactly you run into a problem? Can't see the device in Preferences > MIDI> Devices? What is the device, and are you using MME or UWP driver mode for MIDI interfaces? FWIW, I've had a problem that started with the last major Win 10 update that I have to power up my MOTU USB MIDI interface after booting. If it's powered up during boot, Windows shows the driver loaded, but no application sees the driver.

It's not the physical cable that imposes the restriction; it's the MIDI communications protocol, itself, and, indirectly, the data rate of the serial PC ports over which it had to operate. Only 4 bits were allocated to specify a channel. 4 bits let you count from 0 to 15 in binary; hence 16 channels. Since binary 'word' lengths are restricted ot 4-bit 'nibbles' or 8-bit bytes, the choice for developers would have been between 16 channels and 256 channels. The approximately-1-MIDI-message-per-millisecond data rate of a serial port would make it impossible to get acceptably good timing when pushing anywhere near 256 channels of data through a single port. Even 16 channels can be too much if there's a lot of controller data being pushed along with basic note on/offs.

Seem to be having ongoing miscommunication. I said exactly the above in my first post. But if that setting is overriden by changing a track directly (or by importing a track template or possibly other means), the discrepancy will persist until you re-select or change the setting in options which resets any overrides.

Yes, I understand. What I'm saying is that it's expected behavior that you can have a difference between the default range setting for new tracks in meter options and the actual range of a particular track. And there are several ways to get a project into that perfectly valid state. Using track templates would be another. Without knowing the history of the project, it's impossible to say how the difference arose, but just that fact that there's a difference doesn't mean anything is wrong.

Working as designed, I think, unless you're sure you never changed the individual meter scales by right-clicking...? Or maybe started the project from a template with overriden scales. Capturing that in a Workspace might also be expected behavior.

As an oldtimer, you may be more comfortable setting Workspace to 'None'. Then each project will retain its own layout and settings as you're used to.

So should there also be checkmarks next to Insert Audio Track, Insert MIDI Track, Insert Instrument, etc. when one of those objects already exists in the project? Having a checkmark next to a repeatable function just because it's been used once doesn't seem especially intuitive to me. If I want to see sends in a collapsed track, I show the Inspector.

Sounds like clips are muted. They'll be grayed out, but solo will override clip muting. Muted events will be excluded from a bounce. Hotkey 'k' will toggle muting of selected clips.

It can be shortened to: - Ctrl+A - Alt+A - Clip Follows Project But it's best to check the follow mode first.

Selecting a range by right-clicking a meter overrides the default you have set in Options. Reselecting that default (or a new one) should reset any meters that have had the default overriden. Working here.

Yes, if you don't set an output channel, Cakewalk defaults to sending controllers from track widgets on channel 1.

EDIT: Re-read the OP that it can be off the grid either way, so it's not Snap Offset Another possibility: Snap to Landmarks enabled, and aligning with other MIDI notes/clips...?

How many measures is that? I think Step Sequencer has a limit of 64 beats = 16 measures of 4/4.

As an example, here are the channel assignments for parts in the 4-layer Indie Drone.st3m. They should all be channel '0' to work properly in ST4: <MultiPath>/Volumes/BACKUP/IK Multimedia/SampleTank 3/Multis/Syntronik/J-60/Indie Drone.st3m</MultiPath> -<Part0> <MIDIChannel>0</MIDIChannel> ... -<Part1> <MIDIChannel>1</MIDIChannel> ... -<Part2> <MIDIChannel>2</MIDIChannel> ... -<Part3> <MIDIChannel>3</MIDIChannel>

I assume you're talking about input monitoring latency; is that right? Can you share the project file with no plugins and no audio files?

Yes, Audiosnap and Groove/REX clips are incompatible. But you can have a mixture of Audiosnapped and Groove-Clipped audio in the project. I didn't think this was probably relevant of the OP, so didn't mention it. And you need to be sure to set the Follow Option to Autostretch before enabling Follow Project. The other modes will immediately try to fit the the clip tempos to the project, and usually not do a good job because the clip tempo maps are wrong. Otherwise, so long as you haven't messed with clip Timebases or are other timing/stretching related settings, it should work pretty consistently. Crashing is not something I've encountered before, but I don't use it a lot.

Make sure you are set to Snap To, not Snap By. Easy to miss in the PRV because it only shows when you have the resolution pick list open.

Sounds like you set the experimental 'Aggressive' ThreadSchedulingModel=3 in AUD.INI (Preferences > Audio > Configuration File) that was introduced as an option in the 20.01 release. It was not enabled by default, and many have reported similarly bad results from trying it. Steadily increasing latency was one of the symptoms. Unfortunately, some made the change, and then didn't recall having done so by the time they discovered problems.

The Tempo Ratio function you might have read about went away a long time ago with the introduction of support for audio since stretching was not supported at that time, and it never came back. You can manually change the project tempo and MIDI will follow, but audio will not by default. To have the audio follow the change both visually and musically: - Ctrl+A to Select All (doesn't matter if MIDI clips are included) - Go to Clip Properties in the Track Inspector, and expand the Audiosnap section. - Click to check the Enable box. - Set Follow Options to 'Autostretch' - Click to check the Follow Proj Tempo box.

Assuming individual tracks are not hitting 0dBFS when their input Gain and output Volume controls are at 'unity' (i.e. 0.0 - no gain or attentution from what was recorded in the .WAV file), check the level on the Master bus. The levels on individual tracks may be okay but sum to clipping on the Master. Cakewalk provides essentially infinite mathematical 'headroom' for summing inside the box, but the D/A converters on the soundcard/interface will be clipping if the Master bus is peaking above 0dBFS. You can pull the input gain on the Master down, but it's best to lower output Volume faders on the individual tracks.

+1 to everything Steve said, except I think he meant to label that last link 'PDC button'. ;^) The latency is primarily on the audio side of the process, and the onboard GS Wavetable Synth will have ~50ms of extra latency vs. a soft synth like TTS-1. I recommend uninstalling ASIO4ALL, and using WASAPI Exclusive mode which should allow you to get the buffer all the way down to 3ms for a simple project (Preferences > Audio > Driver Settings > Buffer Size).

I'll have to do some more testing to confirm, but it seems PDC can have an effect. Disabling two instances of LP plugins and one of Transient Shaper eliminated glitching in one project I checked, and disabling only two of them had no effect. PDC had to be completely eliminated to eliminate the glitch in this case. Also, since timeline-seeking is involved, the OP might want to check the setting of 'Set Now Time with Full Restart' in the Track View Options menu. Having this enabled can cause glitches in manual timeline-seeking.

See View > Grid Resolution > Follow Snap Settings in the PRV menu.