msmcleod

AFAIK, AZController uses Cakewalk to send it's MIDI messages, as it'll be using the control surface API. So whilst the calls to refresh can be increased, the frequency of how quickly MIDI messages can be sent out from AZController can't as long as it's doing it via Cakewalk. What I think is required is for AZController to call midiOutShortMsg and midiOutLongMsg directly. This would require @azslow3 to make some modifications to AZController. You'd also need to ensure that the MIDI out device was NOT enabled in Cakewalk so ensure that AZController had full control over it. In other words, in Cakewalk, you'd configure your MIDI In device only, but the MIDI Out device would have to be set within AZController itself. It's also worth noting that a refresh frequency of 10ms had an adverse affect on Cakewalk's performance. I experienced a fair amount of dropouts unless all other applications were closed - just having a browser open would cause dropouts in Cakewalk. I suspect this would be improved if AZController had full control over sending MIDI messages, but given that all control surface functions are performed in the main thread, I'm not sure this would be a significant improvement unless perhaps AZController used a separate thread for sending MIDI messages. Any calls to Cakewalk must continue to be done in the main thread though, and doing this every 10ms will adversely affect performance.

I use the MidiSport 8x8 (the old blue & yellow one), and I don't have issues with it causing CbB to crash not close properly.

I've got an MCU + XT + C4 in my studio, but in my spare room I use the Korg nanoKONTROL Studio which doesn't have motorised faders. For the most part, I don't find the lack of motorised faders much of an issue. Sure, it's a pain setting them up to initial values, but: I try to keep the fader at zero as much as possible, using offset mode to get it to the right place. It's primary function for me is to record bus volume automation by riding the bus faders during mixdown. I find it very useful to be able to control 8 buses at once. For tweaking tracks, it's equally useful, but I use it less for that.

Definitely MCU - why? HUI is dead, and MCU replaced it... and as far as Cakewalk is concerned, MCU is supported whereas HUI is only very partially supported. HUI was originally conceived by DigiDesign & Mackie for ProTools ( before AVID took over ), and came up with HUI: A few years later, Mackie did a similar thing with eMagic for Logic and came up with this: Presumably realising they couldn't keep coming up with completely new surfaces for each DAW, Mackie discontinued the HUI, and turned the eMagic Logic Control into the Mackie Control Universal ( same hardware, different ROM ). The Mackie Control Universal works in three modes: HUI ( for ProTools ) Logic MCU ( for everything else ) They also brought out some extenders to add to the MCU ( which speak the same MCU language: The XT (an extra 8 faders), and the C4 ( lots of knobs for controlling plugins) : These were given a new look in the MCU Pro series, but apart from some minor differences (e.g. USB interface & better faders), functionally they're exactly the same: The MCU Pro and the MCU Pro Extender are still available. Unfortunately the C4 Pro isn't - except on eBay - a pity really, because the C4 rocks.

FWIW, there's a pretty good relationship between most DAW manufacturers. PreSonus have been great with regards to Cakewalk - the FaderPort range have Cakewalk/SONAR modes, however this does piggy back on the existing MackieControl support. Steinberg & Cakewalk also have a good relationship. With the AVID product though, it gets tricky. Writing a custom surface DLL from scratch takes a fair amount of time & investment. The question AVID will be asking is, "How many more $30K surfaces would we sell if we did support Cakewalk?" For Cakewalk it would be, "How many more users would we get if we supported this $30K surface?" The answer to both is most likely, "...not enough to justify the investment." The solution might be for the OP to pay a developer to write a custom Control Surface DLL (or configure AZ Controller if this is feasible). However, from experience I can confidently say the majority of time developing a Control Surface DLL is spent in testing... and a developer will need access to one of those $30K control surfaces (and the physical space to set it up somewhere!).

It's the stereo mix of all the drum parts, as opposed to the individual outs of each kit part.

@norfolkmastering - I had a look at the refresh interval issue. It looks like some of the UI optimisations have had the effect of capping the refresh rate at 25ms. Although the timer controlling the refresh is in its own thread, the refresh and any MIDI messages that are requested to be sent out by the control surface are synchronised to the main thread. I did manage to find a way around this to support a refresh of 10ms, however its worth noting that any MIDI messages sent back out via Cakewalk will still be capped at 25ms. The only way around this would be for your control surface DLL to deal with the MIDI messages outside of Cakewalk - either that, or not use MIDI at all for controlling the analog side.

I sounds like Spire is generating MIDI events which are being picked up by the subsequent recording. You've two options: 1. Disable MIDI output on Spire by going to the drop down menu at the top of the synth's dialog; or 2. On the track you're recording on, make sure your MIDI input is only set to your controller keyboard instead of "All Inputs".

If you've got audio clips with automation, and you're changing tempo without stretching those clips to match the tempo, then you need to make sure your automation timebase is set at Absolute. e.g.:

Yeah, I think I'll raise one. Thanks for checking it out though - it's good to know I'm not the only one with the issue.

An analyzer may give you an indication as to where frequencies are dominant (or not), but that's really only any use when you know what you're looking for (i.e. you can hear something bad, but not sure where it might be). It can also be useful if two instruments aren't fitting well together, as you can identify where their common frequencies are. But in all honesty, visual tools can lead you down a rabbit hole where you're cutting/boosting frequencies for no good reason at all, and in the end it just sounds awful. My best advice is... use your ears, not your eyes!

Two jumped out at me right away. PAD Man at the corner LED Birdland

I upgraded and almost immediately reverted back to 2.9.8 as a few of the presets are totally messed up.

Cakewalk attempts to recover from dropouts during playback, depending on the DropoutMSec setting in your configuration file. This isn't the case for recording where dropouts aren't tolerated because you don't want glitches in your recording. Plugin UI's should really be designed to be as lightweight as possible (CPU wise) rather than be focused on maximum eye-candy.

https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=AudioPerformance.24.html

When importing audio, take note of this setting: If it's checked, then the audio will be inserted at the timestamp embedded within the audio. This is useful if you've exported clips from another DAW that all start at different times, so this setting will preserve their start time. If you want the audio to be inserted at drop location, leave this option unchecked. Note that not all waveforms have time-stamps embedded, but if you do drag a wave file into your project and can't see it, it's likely this setting that has caused it to be inserted later on in the project.

Although the (+/=) key will toggle between the last edit filter and the clips, SHIFT + (+/=) will toggle between the clip gain automation and clips. SHIFT + (+/=) doesn't alter the "last edit filter", so you can use it to access clip gain automation regardless of what the non-shift version has set as it's last filter. Typically I use (+/=) to toggle between track volume and clips, and SHIFT + (+/=) to toggle between clip gain automation and clips.

Click on the clip to select it, then press SHIFT + G - the now time will go to the start of the clip.

I'd need to look into the practicalities of this. I'm on vacation at the moment in any case, so it'll have to wait until the new year.

I've gotta go for D minor:

It's worth mentioning however, that CbB can also send out multiple CC's and/or note events for a single articulation, so the problem they're describing in the article isn't actually an issue for CbB. For example, for sustain & legato you have two choices: 1. Create a Sus & Legato articulation that sends out both F0 & A#0; or 2. Create separate Sustain and Legato articulations, but put them in different groups. For Cinematic Studio Strings you can actually do this all in one CC message ( CC#56 by default). However if you do use this method, make sure Chase mode is set to "Full" (this mode was actually created specifically for CSS's CC#56 behaviour).

Yes - I did this for a project using TTS-1. I put the legato strings on Ch 1, pizzicato on Ch 2, and tremolo on Ch 3. I then set up my articulation map as follows: This is only transforming notes however - you'll need to add an additional transform for CC events if you need that too (basically exactly the same, but with "CC" in both "Kind" dropdowns).

The "Out of Memory" error is what Windows reports when a MIDI device is open by another application.

Right click on the track - you'll find it in the context menu: If you're using a workspace, you'll probably have to re-saving your workspace after changing the default height, else it'll revert back to what is stored in the workspace.

The latest public version is 4.65.5.68 which AFAIK was released a month or two ago. I had to update to this after upgrading to Windows 20H2, as the older 4.63 / 4.64 drivers were giving me a BSOD on boot. There is actually a 4.87.4.709 beta release as well, which is VERY new.