azslow3

To scope, you can use "MIDI loop" driver (so something which send output to input), f.e. loopMIDI, and scope itself which can display what is going on, f.e. MIDI-OX I guess Presonus developers used the same logic as you. Studio One sends "Start" after count-in, so from device perspective count-in does not exist. And they don't send clock when transport is stopped. REAPER sends "Start" at the beginning of count-in and immediately start sending clock, so from device perspective count-in is the same as recording start and so device will start playing in count-in. Clock is not sent when transport is stopped. So build-in clock logic is troublesome, but there are "workarounds" with VST or script based plug-ins which can do things differently. Cakewalk follows MIDI specification with count-in. It sends clock when transport is stopped (but with previous active transport rate, possibly different from current project/position). I mean 3 different DAWs use 3 different approaches. And all of them are MIDI specification conform. But I think Presonus way is most "compatible", at least for this century equipment. --------------------------- From device developers perspective it is unclear how to do things most user friendly way. MIDI specification does not help solving the issue: master CAN send clock when transport is stopped, so some do (Cakewalk) and some don't (Studio One, REAPER). And so device, to be user friendly, should assume there are periods of time when there is no clock and switch to own clock (transport is stopped in some DAWs, DAW exits, DAW crash, etc.). the specification has solution for that, Active Sense. When used, device at least knows when the master is still active. So many devices support it (Roland, Korg). Unfortunately that is an OPTIONAL feature, all mentioned DAWs does not support it (I am not 100% sure, but I have not found related options). between "Start" and clock there can be significant time, as in case with Cakewalk. So, device has a choice. It can follow MIDI specification and "freeze" itself till clock is there or user explicitly reset synchronization or ignore the specification. So my whole original guess is that Roland has decided ignore the specification when Active Sense is not in use, to don't freeze the device.

I don't think most software/devices really follow all specifications. F.e. Cakewalk doesn't follow MIDI specification in part "clock should be sent at the current tempo when transport is stopped (in case it is sent at all)". Changing position to different project tempo doesn't change the clock rate till playback/recording is started (unlike with soft synths). ? I don't have TR8S, so the rest is just a speculation based on its documentation and MIDI chart. With count-in set, Cakewalk sends "Start" at the beginning of count-in, but pause the clock till recording starts. It never sends Active Sense (does Cakewalk support it ?). All that is correct behavior according to the MIDI specification. Since Roland start playing early, it can happened Roland violates Active Sense rule. It should ignore "silence" in case it has never received Active Sense. But it can happened Active Sense timer is always active, so after timeout it thinks there will be no clock. And since "Start" was given, it starts playing (syncing later, when it receives clock again). My guess is easy to check: make count-in 5 measures. Does Roland still start playing during the first count-in measure? My theory is proved then.... Sorry for the noise otherwise ?

GPT should not be forgotten... especially in case boot settings have compatibility mode enabled, so during installation the system/Windows can decide to use legacy boot instead of UEFI, and that is looking for possible troubles in the future (and sometimes in present). From my knowledge, splitting disks make sense in case you want backup/restore them separately. On 3 generations of my computers I never had a wish to re-install OS from scratch but keep something on the same disk. But many times there was a wish some disk is not split (on foreign computers), the situation when one partition is full while other is not is inconvenient. The difference in speed/safety/integrity is virtually zero (for solid state disks).

Theoretically, everything is possible ? But practically, as far as I know, ReaCWP is still the only existing converter which deals with more then just audio tracks (at most with volume automations). I guess DAW developers don't want people transfer whole projects away from own eco-system (internal converters exists, f.e. Cakewalk <-> Bandlab). Another aspect is the format. There are several interchange formats (Cakewalk supports OMF), but there are for audio/video only. MIDI, FXes and other staff is not foreseen. REAPER has a text based and so a kind of open (not really officially documented) project format. Cakewalk use proprietary binary format. And so converting from Cakewalk is hard, but way simpler then converting to Cakewalk. Converting to and from REAPER is technically not a problem (and the reason more export/import projects exist). Converted projects have Cakewalk signal flow. That signal flow is not obviously limiting when you work in Cakewalk itself, but once observed in the "freedom universe" of REAPER, things in fact look fancy. MIDI and audio are separated, Synths are in general different from FXes, buses and tracks are not the same... BTW the signal flow is converted with explicit sends. While REAPER folders could be sufficient in most cases (Cakewalk strip always has one "primary" output), "unrolling" the project to make it more "native" will break routing otherwise.

Sorry, I hit some bug in the webform editor, can't enter/edit in previous post... Check that Digital Input switch is NOT pressed. According to the documentation, it works as "Loopback mode" when pressed and no digital signal detected.

@Paul Logue

So, uncheck "X18..." in Inputs and Outputs, then you can enable "zero controller" again. Sure, that only make sense in case you don't want MIDI tracks from Cakewalk control your XAir. I mention that since the feature is not bad, you can automate XAir from Cakewalk. Also since XAir has OSC over SYSEX and Cakewalk supports SYSEX, you can f.e. setup the mixer when particular project is loaded (with some programming to covert required settings into SYSEX form). So, it depends from your use of XAir+Cakewalk combi.

Note that option is global and it is here for a reason. If you are not explicitly controlling your mixer from MIDI tracks, it is better not enable it as MIDI device. Otherwise you probably hit related problems in the future, in case you use any MIDI. Just imagine you send some MIDI by mistake to that port, that can change random and difficult to find settings in the mixer.

All roads lead to... In any case, most people who want multi-asio don't realize that: (a) something has to sync interfaces, on hardware level (b) most restrictions for ASIO come not from technical difficulties, but from its license...

Check (in Cakewalk preferences) you haven't enabled MIDI inputs/outputs to/from XAir, at least not those which control it.

Try to use ASIO mode with native drivers. That always provide the best possible for (any) interface latency. In case you can't set the buffer to 128 or lower in ASIO, check computer optimization for audio. The rest depends from your PC and used plug-ins. Note that without native drivers Windows and the interface add huge latency which is just not shown. If you don't want optimize the computer and ready to accept consequences, WASAPI sometimes can produce reasonable results (I guess ASIO drivers assume you are serious about audio and so some of them are not forgiving related computer problems).

I guess everything over ~20k (as you can see quite a lot...) lands somewhere under 20k (with full "weight"). The synth can also try to use resulting frequencies later in the own chain. Just imaging a band 30-40kHz is used to modulate sub 100Hz band. What I mean, end result is not limited to just digitally aliased frequencies, any kind of distortions can be triggered. BTW such spectrum is a definitive confirmation the plug-in/preset creator has done something wrong. Audio plug-ins should not produce ultra-sonic components. That is no longer "audio" since there is no equipment which can reproduce it (and even in case such equipment is created, no one is able perceive it, except resulting analog world distortions and aliasing).

What you mean by "right"? May be the person who has created the settings was using 44.1kHz, and so that sound is intended. May be he/she was using 96k. And it can happened it was 192... There are way more frequencies in 44.1 version. I am not an expert, but that can be aliasing results from math. I mean everything over 22kHz calculated in 44kHz rate produce something inside 22kHz. Your "96kHz" mp3 is 48kHz, only you can see (on original 96kHz track) what is inside ultra high range. Plug-ins/preset developers who care check that generated (also intermediate) frequencies are always in reproducible (by sample rate) range, and oversample + LPF when not. Other don't care. Fortunately Cakewalk can do that too.

That is well known effect. It comes from bad math inside plug-ins, but used as an argument 96kHz sounds "better". In Cakewalk you don't have to do everything in 96kHz (that is one time decision since you can't change sample rate in existing projects), you can use "local up-sampling" when make sense http://www.noelborthwick.com/cakewalk/2015/10/24/improving-your-synth-sounds-with-real-time-upsampling/ Some people just use 96kHz for everything, to not think about possible troubles with plug-ins. If you do that, check what you send to your monitors doesn't have high frequency (apply LPF to the limit of your hardware).

To get Cakewalk working again, probably disconnecting the keyboard and starting Cakewalk will work (cleanup MIDI and Control Surfaces in Preferences, exit, connect the keyboard again and start Cakewalk again). If not, delete TTSSEQ.INI and ctrlsurface.dat in the %APPDATA%\Cakewalk\Cakewalk Core folder. Before configuring surface in Cakewalk, check you have chosen Mackie mode. From the documentation I guess you can try to select Studio One or REAPER (see keyboard documentation how to select target DAW). You need to enable correct MIDI ports first. Do NOT enable all of them! Try enable just the first one and play some soft synth with keys. Probably that should work (different sources in the Internet mention different numbering), if not enable one after another (disabling previous) till you find "keyboard" MIDI port. Enable DAW ports (Input and Output), all sources suggest they should be the 3d. Add Mackie and assign these ports (so most probably 3d) to it. Try some DAW operations. If not working, open Mackie interfaces (from Utilities menu in Cakewalk) and set "Disable handshake". If (and only if) everything works so far... If you have some hardware connected to physical MIDI (5 pin) ports of the keyboard, you can enable port 2. There is one pair of ports for M-Audio Editor, enabling them in Cakewalk is looking for troubles (by default keyboard sends some information to all enabled ports, who know how EDITOR port interpret that). In case you want add ACT, assign the same port as you use for keys to it (NOT port you use for Mackie). I hope that helps. Note that I don't have that controller, all suggestions are from device documentation (and personal experience with Cakewalk).

Mobo, memory, storage, video card and audio interface should be selected carefully for audio (real-time) applications. All related BIOS and Windows settings should be tuned for that exact hardware combination. The result can be 'pro'. Apple does that for your with Apple computers. There are people/companies which does that for you with Windows computers. You have 'rolled your own' and then blame Microsoft/Steinberg for the result...

To have best experience with audio under Windows, the computer should not be "put together", but constructed specially for audio by people which know how to do this. That is major difference between "PC" and "Apple", the first can be constructed by anyone... the result is unpredictable. On Windows there is RME Audio interfaces and "other" audio interfaces. Again, if great result (in flexibility, latency, etc.) is expected out of the box and the user has "no time" for tweaking, especially on not "audio special" computer, the interfaces has to be RME. Apple lovers should understand that situation.

Since there is a link to my post in OP... In fact Cakewalk has improved the authorization schema since that time. There is no need to re-authorize throw Assistant (which rarely manage to update itself and refuse to work till updated) and there are "warnings" when the authorization expire soon. I think Cakewalk went as far as they could (assuming they want time limited authorization). I personally don't like authorizations. But they are almost impossible to avoid these days. Windows software is known for long time compatibility, but at some point Microsoft can consider to break it. Will software X authorize and work correctly in Y years? No one knows. For myself I prefer to have an option for "disaster" case. It can be not "perfect", but I like when it exists. For Cakewalk there are options: X2-X3 with offline authorization (WINE compatible, so available forever since x86 platform can be emulated) and converter to another DAW (which requires no authorization and work on any system). I mean nothing can completely "brick" Cakewalk projects, not even instant shutdown. In the modern world that is "sufficiently safe" for me.

If a DAW crash after using some plug-in, it make sense contact plug-in developers first...

@Kevin Perry Thanks for the tip! I still could not reproduce the issue. I have swapped ~1/~2 for 2 VSTs, so 8.3 names was swapped (while original long names kept). Cakewalk still could find everything... VST scanning has reported 1 "new" plug-in and 0 removed (I don't think I have made any other changes, so expected 2/2). And so I can imagine how strange things can happened. UUIDs for synths in fact include 8 characters from 8.3 name + VST2 ID (not that I don't trust Noel, just wanted to check I also "see" them ). I link automations by other UUIDs, which do not include name/VST id, worked fine so far. And so the problem doesn't affect my code (that was my worry). But I am not Cakewalk...

I have tried to reproduce, but I have failed... put VST2 on a separate disk, played with 8.3 enable/disable, renaming long/short, etc. Every time Cakewalk was able to find the plug-in and its automations. According to the (Windows) documentation, 8.3 related call just return 8.3 in case it exists and return original (possibly longer) name when not. I can only imagine there is no check when it returns more then 8.3 and that produce overflow (garbing something).

@foldaway from my experience, feeding plug-ins with incompatible data can produce way more strange effects then just a crash... VST2 is identified by ID, not by file name. This ID supposed to be unique, registered by Steinberg. But who follow all rules... Unlike UUID, VST2 ID is short (4 characters) and so clashes are likely, forcing DAWs to use some (unspecified) method to distinguish physically different plug-ins with the same IDs. As I have mentioned, it seems like Cakewalk in general match plug-in in the project with currently installed one. I mean it seems like 8.3 name issue is more glitch/bug then regular (also from OP and discussion, it happens for automations matching, not for plug-in matching). In case Cakewalk is unable to match some plug-in at all, most probably plug-in developer has done that on purpose and attempts to find a "back door" is not a good idea...

I have thought plug-in replacement is the only case when (instance) UUID+parameter (that is how I match automations when parsing projects) can be disrupted... I remembered changing dll name was not affecting project loading. And I have just checked again: after renaming TruePianos.dll into True.dll and re-scanning in Cakewalk, "new" dll was matched in the project and related automation was not orphaned.

Automation data are linked to plug-in parameters. I don't think plug-in installation path is ever stored in projects. I suggest you to check you are using the same plug-in format (VST2 or VST3) on both computers. Cakewalk could automatically "replace" VST2 with VST3, in case VST3 is installed (and compatible with the procedure, at least from Cakewalk perspective). If such replacement happens, parameters list can be different and so existing automation data can't be matched.

I remember one discussion about X32. Some of it's build-in effects have delay (just like some software plug-ins), but the devices is not compensating (so it works like Cakewalk with PDC off). Such delays are not reported to the DAW and so can't be compensated by Cakewalk PDC. You can correct X32 real latency manually in Cakewalk (in section "Sync and Caching"). There are many posts (for any DAW) how you can do this. F.e. real settings on X32 (with all desired effects) and headphones record beat listening backing track. Adjust offset till tracks are in sync on playback (you need to re-record after every adjustment). There are more accurate methods as well. Note in case the band listen backing track throw speakers, every 1m from speaker to listener adds ~3ms acoustic delay. Probably not significant in your case, so just to keep in mind these tiny (but visible in DAW) delays exist. But if you have 2 live tracks and put a plug-in with delay on one of them, live sound should be in sync (both tracks delayed). In case you have some plug-in which fail that (easy to check one by one), I guess it is better just avoid that plug-in.