bvideo

There are differing degrees of multiprocessing. One special case is "plug-in load balancing", where the chain of plugins on a single track is handled by multiple processors, one per plugin. I was wondering if you tried disabling that. I'm sure one of my projects had a problem with it, but only with certain plugins and certain settings thereof. I asked you about buffer size because plug-in load balancing is disabled when the buffer is smaller than 256 (by default). So I am still curious if you have tried those things. Aside from plugins and audio drivers, the core of Cakewalk & Sonar is shared by dozens (hundreds? Thousands? ???) of users, not many reporting playback or rendering corruption. That's why I'm asking you these questions about a corner case I believe is there, and has been there since plug-in load balancing was introduced. (My early report).

Hi Henrizzle, "... disabled multiprocessing ..." How exactly? Did you do that in the BIOS? Did you disable "plug-in load balancing"? Did you set CPU affinity to just one processor? Something else? (I ask with curiosity because of a prior experience of mine.) Also, do you have "64-bit Double Precision Engine" disabled or enabled? Do you use an audio buffer size of 256 or greater or smaller? Do either of these changes make a difference? Does Sonar after September 2016 do the same? To reach Cakewalk support directly, see "How do I report a problem with a Cakewalk product?". It says "please contact us at support@cakewalk.com."

If it's onedrive, your network connection is important. Wifi? Some wifi hardware can need too much CPU at times. The latency monitor tool might be able to help zero in on the problem.

My first modem was 110 baud.

Also try enabling 64-bit double precision. Also, an audio buffer size below 256 will disable plugin load balancing.

That "server busy" comes from drag and drop, so if you dragged from the desktop to the program icon (about double-clicking the icon, not sure, maybe the same), it indicates that the program has not yet accepted the handoff after some time period. It may eventually. So a question is, does Cakewalk normally take a long time to start up on your system? Or maybe is your system especially busy, or just restarting, when you try to open that way?

Monty Hall / three doors (doahs) scenario?

My goodness, how far off topic this thread has gone!?

Does the arpeggiator give options for sync to beat? Or does it simply clock each sequence starting when that key is pressed? If the latter, then the arp is just reflecting how much out of sync your keyboard technique is. For on-the-fly playing on an arp, it seems like it might be preferable to have an auto-quantizer enabled.

Here's a page of comparisons of some measurable qualities of how various DAWs do sample rate conversion (SRC). It's one proof that all DAWs are not alike. Of course SRC is only one technology of audio processing, and depending on the project and other DAW optimizations, it may or may not play a part in outcomes. SRC can be invoked when a project is rendered at a sample rate that is different from some of its source files. It is also used by some DAWs and plugins in an oversampling stage to improve results of audio processing that are sensitive to aliasing in high frequencies. Maybe not all the audio outcomes shown in the various graphs on that page are audible. It looks like some of them should be. The audio material used in the tests is not the least bit musical. But it is convincing to me that DAWs are different. Just for fun, you can note that some older versions of Sonar can be compared against the X3 version.

If LUFS is a calculation over the whole file, the ones with silence will come out different from the ones without, even if the sound part were identical.

If exporting the wav file is done by non-realtime render or bounce, moments of silence are not likely caused by CPU exhaustion or anything about the sound card. But what, I don't know. maybe: Is there a master bus plugin that is not authorized on your home system?

Did you get such a discount for your Teac 3340S? I still have mine, but it badly needs service. I think it was expensive, and still can get high prices used. It has playback through the record heads so you could lay down more tracks in sync with the existing tracks. That only became obsolete when computer-based recording became readily available (Cakewalk 1.0?). Occasionally I use mine for capturing old family recordings, such as from 1958 or so.

That cable looks really wrong anyway. The USB won't connect to your computer. Is there a link for that ?

You can try changing your 64-bit on/off, and plugin load balancing on/off. And depending where the rendering mistakes are, you could pre-bounce some tracks to reduce the load so you could then use real-time render, or conversely, to eliminate rendering the misbehaving tracks in fast render. Or do all the tracks misbehave?

A misconfigured all-notes-off sequence.?

There is a chance that if you look deep into the Kontact piano, you might find an effect that is sensitive to tempo change. In any case, can you tell which track or bus produces the hiccup?

I had some too. Reported it a few times way back. Also, try with/without 64-bit rendering.

Your wheel events are recorded on 5 different channels, so it shows up 5 times in the piano roll view.

That Wdf01000.sys is a "driver framework", so it could be used by any non-class-compliant device on your computer. Since it is a "gaming" computer, there may be a device built in that uses a driver tuned to gaming. Another possibility is that your anti-malware software has provided some alternate or stacked drivers, e.g. for keyboard and mouse (mine does), though wdf01000.sys is unlikely from anti-malware software. So mainly have a look at the driver stack for keyboard and mouse. Control panel -> device manager -> Keyboards (or) Mice and other pointing devices (double click or right click) -> properties -> Driver -> Driver Details and see if wdf01000.sys is there.

Check for the MIDI 'shift' key configuration. Check in the upper right of this "preferences" subwindow.

This is the special case of "phase" corresponding with a polarity flip. It can only happen with a purely symmetrical wave and only with a 180° time shift as determined by the period of that wave's fundamental frequency. So it would be possible to construct a case where transmitting a sine wave through a time delay of exactly 1/2 the wave's period would appear as polarity reversal. (edit: some pointless material removed)

The drivers for USB or DIN (usually connected by USB, only much older equipment was connected by serial or printer port) can be viewed by going through the device manager and finding the item associated with that device and inspecting the driver stack. Most likely, they all use the Windows "class compliant" drivers, but it's worth checking. Variations are more likely within the h/w dongle or, in your case, the synth, which, by the way still has to pass the DIN output through another interface (which is also USB connected?) Audio drivers, particularly ASIO, are the ones that suffer from some manufacturers' efforts.

"... wait until everyone has upgraded their systems (including all gear) to MIDI 2.0 ..." (User 905133) This thread reminded me we had one on the old forum (midi "Jitter" it Does Exist). It was started in 2007 and it frequently referred to the imminent MIDI 2.0 ?. The final post on that thread was in 2015. It was full of wild conjecture and a lot of misinformation, but there were a few examples of good experiments. I just finished reading the whole thing, and I don't recommend it (it's 18 pages!). But it did point out that there were variations from one VST to another and even from one note to another for at least two VSTs (one of them seemingly purposeful). And also variations from one MIDI interface to another, and external synths made things even wilder. So experiments need to develop anchors that eliminate unpredictable latencies and jitters. In John Vere's post, there are indeed mysteries in the latency timings. But there are quite a few places where latency can spring up (including the drum brain converting to MIDI, including velocity, and also generating the associated audio). The 180 degrees out of phase is not especially mysterious, since the mic wirings or the speaker's amp could be responsible for that. (And it isn't strictly phase, which would relate to some timing issues -- it's a signal polarity reversal.) Also, the little bump on the "monitor mike" at 294 samples, where did that come from? Did that mic hear the drum pad from a short distance away? It can be worth it to try a VST (not TTS 1), maybe a drum VST in parallel with the drum machine.

"Does not work" leaves out some important description. "Does not NULL" maybe, leaving little differences? Or "Does not line up" meaning the two signals are different in phase? If there is no difference, then why would we need oversampling? Your test might help one way or another in that question. If there is a visible difference, is it a difference that sounds different? If there is some phase shifting in the over all oversampling/resampling process, it may be difficult or impossible to judge anything by the visuals.