bvideo

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.

All the references above to "zoom" are not referring to the clips pane zoom controls but the per track zoom, which refers to the range of midi notes that can fit in one track display. (There is an audio version of that as well that refers to the waveform display.) Did you try sjoens' instructions?

Perhaps that track is zoomed in too far to see all the notes.

A multiport midi interface supplies a group of ports in one USB connection. When that is the one and only MIDI interface on your computer, the order and friendly name assignment is never lost. Example: midi express 128.

There's a basic issue with USB MIDI interfaces: the standard for device configuration does not include a serial number or any other unique ID for MIDI interfaces. Therefore, it is difficult for the OS to distinguish one from another. Only if you are lucky, when you boot Windows it will find the interfaces in the same order it did last time, and thereby match up with the friendly names. If you ever unplug/replug one, or if reboot or sleep/wakeup finds them in a different order, they will not match up. There are some other discussions about this (example)

Sending the DRM from Cakewalk should be asking for a channel number. That number needs to match a global setting in your M1. I can't find my old M1 manual just now, but is it possible the channel number is 1-16 in the global setting but 0-15 in the DRM dialog... Same consideration when sending a sysex dump; the channel number in that sysex needs to match the M1 setting.

Does this happen with more than one particular synth? There have been unfreeze problems before related to at least one specific synth (sektor).

In the manual, it seemed I could see a playback mode (how to transmit your composition) to an external synth|host (cf Cakewalk) in such a way as to transmit the bank/prog numbers. When cakewalk receives them, it will populate the track header widgets with the corresponding names from your .ins file. As far as your latest problem, it is best to save your project as a cakewalk native project (.cwp) for reopening to continue editing. You can write your .mid file separately for sending directly to your synth. A .mid file can't hold all the information of a Cakewalk project, so is not good for revisiting / reediting.

I wonder what you are actually doing in Cakewalk. Almost sounds like you are composing on the PA900 and just using cakewalk to create a midi file. But it looks like you don't really need cakewalk for that. Isn't there some way to save your PA900 composition to a midi file on a local thumb drive or to local storage? Most likely, that file will have all the required sound setup. It looks like you can make the PA900 look like a hard drive to your PC. Then save your composition to the PA900 internal storage and then copy midi files from your PA900 to your PC. I looked very briefly at the manual, and it looks like you can do without Cakewalk. Or if you want to use cakewalk, it looks like you can configure your synth to send program/bank changes so CW will have them for writing a midi file. (See pg 121)

If you chose banks/programs for your tracks in Cakewalk, they will get saved to your midi file and sent to your PA900 before playing notes. But maybe you set up the sounds in your PA900 instead of in Cakewalk. If that's so, playing the MIDI file has no information how to set up your sounds. Whatever sounds the PA900 already has set up by default will play, probably piano. You can: 1. see if the PA900 has a way to save a setup of your sounds, then load that setup when you play that MIDI file. 2. look into how to set up bank/program numbers in cakewalk. First, see if there is a publicly available .ins file for the PA900. And check the cakewalk manual for how to install and use it. Otherwise, try to read out the bank and program numbers from your PA900 setup and enter those raw numbers into each track's bank and program number widgets in the headers of the tracks. Either way is how Cakewalk knows which sounds to play in your PA900. 3. there may be a way to transmit your PA900 setup into cakewalk so it can be made part of the MIDI file. That involves transmitting a sysex dump from the PA900 into your Cakewalk project so that when you save the project as a midi file, that setup dump will be sent to the PA900 in preparation for playing back with the correct sounds. See your PA900 manual for how to send the sysex dump and see the CW manual for recording it and putting it in the song.

The usual reason is mismatching sample rates between Cakewalk's setting and the audio interface.

It's an odd choice in the Korg SV-1 if, as it seems, note-on velocity 0 is treated as a note off at max-velocity.