azslow3

Start investigation with Windows Resource monitor (resmon). Windows computer starts with several hundreds processes, some of them are "heavy". Many are starting "on there own" later (updates, telemetry, etc.). Don't forget to set "Ultimate" (or at least "High performance") power plan when running DAWs. ASIO buffer affect performance, but in different domain (once you are approaching tiny buffers, the effect is plug-in dependent). Start with 512. Size under 128 may require audio optimization (on system and BIOS level). Sizes under 64 normally require special computer, audio interface and optimization to be useful (for anything except marketing).

"4 months without a hitch" with global echo and build-in MIDI learn (remote control) ??? Man, you are lucky. With that approach I had a problem within the first 4 minutes the first time I have tried to use it, with my first MIDI controller, with one instrument on one track. I have assign the first knob to the track volume. Controlling? Yes. But something is wrong with the sound of the synth... reloaded the project. Everything fine. Controlling the volume - my synth is crazy again. Changed the synth - everything is fine, I can control the volume and that second synth produce expected sound. Problem with the first synth??? Not really... Cakewalk remote control doesn't block assigned MIDI, so it "leaks" to synth

If your keyboard can switch channels easily, you can follow mentioned by John Vere way instead of selecting tracks. That has more chances to work reliable. -------------- At this point I want to mention that following method is NOT for live performance in front of big auditory... At the end I will give an example "why". -------------- I hope you are not using "remote control" way. It is limited... You will have to use Control Surfaces plug-ins approach for anything above mapping particular control in the project to particular hardware element. In "ACT MIDI Controller" that is "Next/Previous Selected Track" assignment to buttons. In "AZ Controller" that is a combination of "Strip Track <Current> -1/+1" and "Function Select strip" Actions. "Strip" Action allows absolute track selection (including by name) and so you can pre-define buttons to select particular tracks instead of moving up and down. "Mackie Control" will not help there with NanoKontrol (real Mackie has "select" buttons) and "Generic surface" doesn't has that function. Some controllers allow computer keyboard shortcuts, so up and down keys. But I don't think Korg has that. -------------- As promised... Put several synthes on several tracks in the project, "Echo" follow focus, so when you select particular track you play one instrument. Now press one note and without releasing it select another track (f.e. by mouse). Press second note... with a bit of luck you will understand what I mean...?

Try https://www.azslow.com/index.php/topic,297.0.html

If you want create a project "on the fly" (so add/replace VST/VSTi or generic way to change the sound), especially without keyboard and mouse, better get host/controller designed for that (f.e. NI Maschine). For just changing the sound on particular track you can use "sub-host" approach (f.e. NI Komplete Kontrol + keyboard). Cakewalk supports MIDI controllers, for direct steering and as a "Control Surface". Using the first option your particular VSTi can be MIDI learned to adjust particular parameters using particular knobs/buttons, some VSTi also allow changing presets this way. As Control Surface (key word for Cakewalk is "ACT"), you can ask buttons/pad on your controller select tracks, control transport, etc. In both cases you have to prepare the project (s) for your live performance, with all assignments already done before.

Note that Sonar (prior Platinum) users can use serial based activation, for corresponding versions of plug-ins (Z3TA+2, DimPro). I don't think there was improvements worse the trouble of "activation". I still remember I put "newer" version of Z3TA+2 on my installation stick, just to find out it requires activation (and as usual in our live, at the moment of installation the Internet was down). I know, it has grace period. But I still prefer to have a "basic" set of music software which I can install without Internet, fortunately Z3TA+2 and DimPro are in that list.

As you could conclude from my previous post, there are such people... At least I (the author of ReaCWP) and the author of AATranslator have tried. Every single tiny parameter and property, including "trivial" (f.e. fader position, timeline position), are not easy to match even with dedicated and analytical effort. In some cases that is at least possible (f.e. fader position), but in most it is not (f.e. an automation of fader, if it has any curves and used interpolations inside DAWs do not match). And so that is the only reasonable way to go ?

There was many threads on many forums on the topic... DAWs have no "own sound". But there is no single "right" way to do almost any arithmetic operations a DAW should apply to the digital audio. So the results depend from the settings and design decisions. Normally "comparison" threads are about audio only. Even there things are not "standard". When it comes to VSTi and MIDI, there are even more variations. Some differences between 2 particular DAWs you can find in the documentation of my ReaCWP: https://www.azslow.com/index.php/topic,406.0.html But most important for any tests with many VSTi (and some FXes), as was already mentioned, they are not producing exactly the same result. Even if they are called from the same DAW, playing the same input track. From what I remember, that was primary reason to introduce "AUX Tracks" in Cakewalk, as a possibility to record live performed VSTi output since playing recorded MIDI sometimes produce different audio (so different that during recording there could be "loud wide sound" and during playback "almost silence"). That is not a bug. That is expected.

There is ready to use AlphaTrack preset for AZ Controller (https://www.azslow.com/index.php/topic,172.0.html), the installation has "complexity" of VST installation and preset selection. I mean special knowledge is not required. But unlike with original plug-in, it is possible to change everything in the functionality. That requires understanding how AZ Controller works. Even in this case you don't have to do this. You can ask on my site for the tweak. For me making simple tweaks takes just several minutes.

I guess you have never tried to write DXi of DX MFX... Especially with the second one, it is absolutely clear "that can't work well..." right at the first try ? Several hundreds of people team... are you writing about rocket science or DAW development? Read the license for AU and VST3, notice the difference. From what I know REAPER supports LV2 and Clap on ALL platforms. ------------------- Note that almost no-one is developing plug-ins in particular format for particular platform. Developers are using "frameworks", which create several formats for several platforms. Yes, there can be some overhead for support of yet another format, but if you support 2-3 formats on 2 platforms, yet another one should not be a problem. There can be some forced changes if format tries to "kill" something, f.e. if you was developing GM-like plug-in and want it in VST3 form... but that is not the case with CLAP. So as I have already written, once/if JUCE include CLAP in the list of outputs, many plug-ins will be "magically" available in CLAP format. ------------------- Supporting new format can hit some logical problems in "historical" program as Cakewalk. But in CLAP there is nothing orthogonal to existing approaches (unlike f.e. ARA) and that format dost not force "wrapping own head" (like f.e. VST3).

Have you ever thought why it takew so long? And why Steinberg had to force use it after 2018? Why there are several formats at first place? Also ProTools is an "industry standard". Why you try to use something else, like Cakewalk? ?

That doesn't tell much about it. If it is i9 or i7 and has M2 PCIe slots, I wonder why you don't have corresponding disks already. That was almost "standard" 5 years ago. If you don't have M2 PCIe slots, that is a good reason to think about new computer. Otherwise put a good M2 disk there. Cloning software is disk dependent (Samsung has own, WD has specific version of Acronis, etc.). You don't need to re-authorize major software, but some plug-ins may ask to do so. Note there are cheap M2 PCIe disks with effectively performance between HDD and SATA. I mean don't buy the cheapest, the price difference is not worse it. Also note in most configurations only the first M2 slot supports full performance, even in case there are several such slots. It make sense to buy the biggest disk and put it there.

@JoseC I have tried to make presets without having the controller on my table, not only that is far from easy and error prone job, the results was far from perfect (f.e. as I have found with X-Touch Mini, once I have bought it). I have bought M32, so I have made a good preset for it. I don't have Launchkey, and so I have no plans to made preset for that device. Note that Launchkey support HUI and has finite controls. In other words there are several simple ways to make it work with Cakewalk: Mackie plug-in, ACT plug-in, Genertic Surface plug-in, AZ Controller with "Startup" preset. Each has advantages and disadvantages, but basic functionality is achievable with any of these approaches. Sure, complete integration, with all supported by device modes, particular user wishes and good LED feedback needs dedicated solution. Programmers reference exists for MK3, so that is possible by third party (in 'C++' using Cakewalk API or as a preset for AZ Controller). I just mention that because not all controllers have programmer references in public (some are possible to get privately, for some devices producers don't give them at all...).

@Jim Fogle Why future? My OSC preset is quite "popular", there are at least 3 users ? May be my NI (M32/A49) preset will be popular as well... in 6 years... even so NI controllers are popular and my preset has more features with Cakewalk then official integrations into other DAWs, I am still waiting for the first feedback ?

You are asking a company to provide you a tool to locally debug a problem in the software of that company because you don't trust the company. Oh man... You've made my day. ? PS. I am a programmer/admin.

With Freezing it always was a bit fancy. One of related bugs seems like just visual, so "Freeze" button is grayed while freezing is possible. I can't reproduce with exact sequence, but I managed to get it in that state within 1 minute. Project saving/reopening as well as mute/unmute the track helps to get that Very old trick toggling mute brings that in consistent state.In general it is better have Rack visible when working with freeze, it sometimes shows different picture. When having problems, check routing. I mean which tracks are pointing to the synth and how its output is routed. I have never used MIDI-Output from synth (it was never working for me good), but I guess that also can influence some internal logic. A bit strange behavior with routing is reproducible: * one simple instrument track, muted. Freeze is available. Frozen. Silence is rendered. It was muted, so logical. Unfreeze. * add new midi track, set output to the same synth. Freeze the first (still muted) track. It is rendered using both MIDI tracks. This time not really logical... ?

In short, in Windows device manager switch option to see all (also disconnected) devices and check you don't have "duplicates" in MIDI devices. Always connect USB-MIDI devices to exactly the same USB port. Even short connection ("by mistake") to another port and you have to re-visit device manager and cleanup. That is not eliminating the problem, but at least reducing a chance of strange mappings. A bit longer... Cakewalk does not use deepest possible way to re-discover devices. They save "names" and "numbers" (as can be seen in INI file), but both are not really persistent in the Windows world of MIDI devices. Better way is in fact rather tricky... Not all MIDI devices are USB devices and there is no strait route from USB world to MIDI world. Not only MIDI, but also USB devices are not "unique" (unlike f.e. network interfaces). If some device is "re-connected", it is not possible to detect it is the same or just similar. In addition, several devices of the same type can be connected at the same time. There is absolutely no way to distinguish between them, f.e. if you swap there cables. So Windows is using the only available "safe" approach, if USB device with the same IDs is connected to the very same USB port, it is matched to previously registered device. If there are any doubts, it is declared and registered as "new" device. One visible "name" will also be "new", matching by names is more complicated then someone can think. To attempt match things better, software should try to detect if some MIDI device is USB device and if so try to track re-connections to different USB port, also doing that at run-time. Windows does not really help in that journey. Apart from "known" MIDI devices (with some of them enabled) and assignments to surfaces, Cakewalk project also keeps a sequential list of MIDI devices activated at the time it was saved. So when opened with a "new" list it should be somehow matched. For "known" MIDI devices the goal is just detect any changes and detect what was not changed since the last time. But a project could be created long time ago or even on different computer. On one side users will probably hate explicit re-route MIDI on project open every time after any MIDI configuration change, "I was using a MIDI keyboard for recording on one computer and it is natural another MIDI keyboard is auto-used on another computer, if there is one". But in general such "natural" mappings are failing, especially in case there is more then one MIDI device. What I mean, for that part there is no "right" approach, any particular approach will have some consequences.

https://www.azslow.com/index.php/topic,295.0.html

Sorry, but I don't believe you ? If knobs on Mini are in relative mode, it always change the value relative to current (once DAW is configured to accept relative value, otherwise the knob always effectively set one of two fixed values...). There are several relative modes and DAW surface plug-ins support several, but both have to be set manually to match each other. StudioOne supports several types of not Presonus controllers, but in general they protect own controllers market. So you just had luck "it works!" for your controller. When you have a controller with which it does not work, you can't make it work. And no-one (except Presonus) can. They don't have open surface API (unlike Cakewalk, REAPER, Ableton and Bitwig). The same with Cubase. ProTools long time was supporting just one protocol for surfaces (Mackie HUI), any controller had to implement it to work with ProTools. Since long time they also use EUCON. I mean your claim "other DAWs" do it better with controllers in general is not true. Cakewalk was the first DAW which has published open source surface API. The only other DAW which has done the same is REAPER. When someone writes about changing a DAW because of controller support... that is just LOL. DAWs are different and each has advantages and disadvantages. Many users have and use more then one DAW. You can't "replace" ProTools if you are forced to use it. An attempt to "replace" Ableten or Maschine is not going to work well (if you used them for the purpose they was designed...). And there are FL, Tracktion, etc. which are also quite specific. There can be (and was, when Sonar had EOL...) discussions about changing between Cakewalk/S1/Cubase/REAPER/Samplitude/some other since they have significant overlap in the functionality and in the framework. But there are always pro and cons for each, which by far overweight a possibility to work with the cheapest controller with encoders on the market (Behringer X-Touch Mini).

With Behringer X-Touch Mini you have several options: put it into Mackie mode and use "Mackie" control surface plug-in in Cakewalk. But It will not control VST plug-ins, only strip pans (Unlike Compact and big X-Touch, it has no sufficient number of controls to mimic Mackie). put it into MIDI mode, set knobs to transmit relative value, use "ACT MIDI" control surface plug-in, set it to use relative values for knobs. There you can configure to use knobs for different parameters, including "dynamic plug-in mapping". It will not "jump", but there will be no ring indication ("ACT MIDI" is not supporting feedback). put it into MIDI mode, set knobs to transmit relative value, use it as MIDI input (without control surface plug-in) and MIDI learn in VSTi in question (assuming it support relative MIDI controls learning). Unlikely you will get any feedback. put it into Mackie mode and use preset for AZ Controller: https://www.azslow.com/index.php/topic,377.0.html You will get feedback and can control VSTs in "Plug-in control layer". Sorry to says, but quickly searching YouTube videos for Mini and Cubase/Protools/etc., most videos are a kind of "it's so boring!!!" for one or another feature which doesn't work. Well, logical... google top "known bloggers" which normally have no idea what are controllers and how to make them working, with any DAW (till particular controller officially support particular DAW) ? Any controller/DAW combination require the user spend a bit of time to learn how to setup it optimally for the use case (which can be different). You can "hit" something good working "by luck", f.e. when someone has added particular controller support into particular DAW or controller comes with own software for particular DAW. But you can't expect that magically automatically works. "A controller" is not "a mouse", they are all different.

I expect Cakewalk inform me when something is changed homogeneous way. Asking Cakewalk to do something does not means it has done that immediately, it can be not possible or is done later. Well, that is not so important, I am just monitoring the value without caching now. @norfolkmastering AZ Controller specific processing is relevant for AZ Controller only. There are times Cakewalk does something not possible to "fix" in AZ Controller, like original BR, and there are times AZ Controller does something unexpected, like your last observation. Lets not disturb Cakewalk with something they do not manage

"The controller" is like "the music instrument". That tells nothing about which device and mode of it you use, and for your question that is important. If your controller has encoders (infinite knobs), they send right type of messages (increment/decrement) and "ACT MIDI" is configured to understand these messages, you will have controls always "in sync". If your controller expect a "feedback" from the DAW and it is sending absolute position, the DAW should know how to send the feedback. That is controller specific and can't be done "generic" way. "ACT MIDI" is not designed for that. Some DAWs support simplest feedback (send current value to the place and in form the control is sending to the DAW) and for some controllers that works, but in most cases there is a separate software for particular DAW and controller combination.

Are you sure that is the case when you change by the API? Sure it can be my bug, but in my observation the flag is set only in case you change is done by mouse.

I think MIDI jitter and audio jitter are from a bit different "domains": Audio is a continuous stream. Audio is sampled using clock and when this clock is not accurate, samples are for "wrong" time. Audio jitter is inaccuracy in the time of samples. If there is more then one clock and they are not synchronized, f.e when two interfaces are used in parallel, there are "drift" and "jitter" between audio streams. If interfaces are synchronized, there is no drift but still there is some jitter between stream (samples taken at the same world time are not put at the same time position in the audio streams). Note that audio transfer way/speed/latency does not influence that jitter. MIDI events are not sampled as continuous stream. Jitter there is a deviation in latency. So how late an event is delivered in comparison with usual delivery time. Unlike audio, there is no predefined "sample rate". Obviously there is some "rate of reading hardware sensors and converting them to events", but it is unknown and device specific. The only known clock/delays is MIDI hardware transfer clock (~31kHz) and so it takes ~1ms to transfer one note. Hardware MIDI transfer use uni-directional continuous stream, so a note can be delivered as soon as prepared. In other words ~1ms is full (and constant) delay between the note is ready and delivered (important for comparison with USB). USB-MIDI has much higher transfer speed in comparison to MIDI. Even USB 1.1 is at least 1.5MHz (up to 12MHz), so transferring one (or even several) notes is way faster using any USB (one note in less then 0.02ms). But USB use host driven packet delivery. And here comes the problem, in a "standard" mode used by computer keyboards, mouse and "cheap" USB-MIDI, delivery from device happens every 5-12ms ("polling rate", device+mode specific fixed number, easy to see in Linux, I have not tried to look under Windows). So a single note, in case of 10ms quantization, will be delivered between 0.02ms and 10.02ms after it is ready for delivery. And so there will be "jitter" up to 10ms. USB-MIDI devices with own drivers are supporting (and using) lower polling rates. With 1kHz polling rate max deliver jitter will be ~1ms, for any number of simultaneous notes (USB2+ can go higher, but I have not checked if that is used in USB-MIDI).

I have not done the test, but one "theoretical" note. Let say you have 100Hz sin wave. That means its "turnaround" is 10ms. If the interface input to output latency is 5ms, recording input and output simultaneously should produce 180° phase shift. I mean visual shift between waveforms depends from the frequency and the interface RTL. PS. I assume you have checked the interface reported latency is accurate, using loop-back recording. Good interfaces report it correctly, but if external mic pre-amp with digital output is used, it is not (can't be) auto-accounted into the interface RTL. Also while RTL is easy to measure with loop-back (in a DAW or with special utility), its division into input and output parts is way trickier to deduct.