Amberwolf

Not sure what the icon looks like now, but for me it's a keyboard icon near the top right of a plugin window frame. This allows you to to pass or deny keystrokes thru to SONAR while a plugin window is in focus. If it's pasing thru, you can get behavior you don't want or expect if you don't realize this.

Most likely at some point you changed to offset mode and upped the gain or volume output while there, without realzing it. Unless shortcuts have changed, if you hit O it changes to offset, and pressing it again brings you back to automatable controls view. (I think it would be nice to have a view that has both visible to keep track of this sort of thing easier; don't know if that's possible in modern Sonar). So it's easily possible to be, say, trying to rename a track, accidentlly not click on it right, type someting and end up accidentlaly triggering assorted shortcuts via the keys you pressed--and O is a common letter in English0 musical words at least (Vocals, Viola, Bowed, Orchestra, Toms, etc) so ti's very very easy to do this. (ask me how I know 😊 ). Then go change a control (volume, gain, whatever) somewhere, then later on rename *another* track and switch back to automated mode, all without ever realizing it's happened, utnil you run into something like this. Deleting the track fixes it, since it deletes the offset control value. Antoher thing that can cause it is clip gain envelopes, or an automation envelope for the main gain or volume that was later hidden to be able to see something else more clearly, and then forgotten about. Since the value of an automated control still shows on the control, you'd see this change...but not if you did the automation, and hten accidentally switched to offset mode--that version of hte control doesn't change with automation, so.... In offset mode, at least in my ancient version, there is a + sign in the controls that have that mode when you're viewing them. There is no + in them if you're in the automatable view, so it is easy to see which mode you're in if you remember to look for that (took me a while to learn to check).

If you turn the track(s) down, does the problem go away or lessen? If so, you're simply overloading the output whcih causes clipping. Beyond that, we'd need to know how you have the project and metronome setup, your bussing structure, audio driver info, et.c

Are you drawing the notes in and having them end up in the wrong place? Or do you have a clip that you are editing? If you are editing a clip, are the notes in it different than what you see in PRV? Are you using the song key map to tell it to change from the key that it was already in? Or something else? More specific details are necessary to find out if what you are seeing is normal or not, and if not, how you might correct it.

I wonder if they're using (like many companies) a poorly-trained AI for support tasks? Or maybe it is just a poorly-trained human.

What happens with any loop when dropped into a project depends on what the loop creator actually set within the file. There are some loopmakers that set the flags for all the proper things, and even include marker data so when you drop it in there are markers automagically placed in the timeline. Most don't seem to set all the flags, and some don't even set the loop flag nor include the tempo data, forcing the user to do this for each file. Some of them don't seem to have the beats info even though looping is enabled, and Sonar sometimes guesses wrong on how many so it plays twice or half as fast as it should. And it seems to be hit or miss with some loopmakers where some of their stuff has some things, and some has others, and none of it has everything. So I long ago got used to just checking the looping properties of everything as I drop them one at a time into a project, by pressing Alt-Enter on each clip as I go, and no longer pay attention to what was already set right, so I don't know which makers do it right or not.

Apparently, Drywater, Mars has infected my brain thoroughly; it's gone beyond just a few music tracks and now I'm buildng the universe and want to write the stories, then make webisodes for them. A thread for the development of the ideas, if anyone is willing to help out: https://cff.ssw.net/forum/viewtopic.php?p=106959#p106959

They have a free loops pack fo choreographs that might give some idea of the sounds it can make, if that helps.

This version is much more useful; I'd suggested a few things after making these with it, and all of it was implemented and more. I suggested a few more things so we'll see if there's a 3.0 tomorrow. 😆 (the biggest thing was to remove or allow moving the square where the cover art would go, because it looks *so* good with just the background art....) Drywater, Mars: A Sci-Fi series (Opening Titles) Drywater, Mars: A Sci-Fi series (The Heist) Drywater, Mars: A Sci-Fi series (Intercept)

FWIW, earlier today when I was poking around for more info on the company, nine volt audio to see what else they made, etc, it looks like they closed down (to do other things instead) perhaps a decade ago? I hope htey still get *something* out of each of these sales, for all the work they did. https://vi-control.net/community/threads/why-is-nine-volt-audio-shutting-down.34729/ Still a good deal if you need any fo these kinds of sounds--there's a bunch I could use.

If the synth exposes a standard MIDI port as if it were a hardware device, or as if it were a midi loopback, then it should "get around" whatever it is in Sonar that disallows using windows' midi mapper. Or, if the synth can internally be set to connect to the output end of a midi loopback (like LoopMIDI, Hubi's, etc), then you can use the other end of the loopback to show up in Sonar as a normal "hardware" MIDI port, and then Sonar wouldn't know the difference and would just send midi data to it like any other midi port.

AFAICR, the autosave only does anything if you have saved at least once for that project, or else it doens't know what or where to save. So if you intend to use it, make sure you *always* save the project once you set it up before you do any actual work in it. Even if you just save it once you open your template or start a blank project, you have at least given Sonar a starting point to begin autosaves. If you are going to use the x number of minutes autosave, it seems to work normally regardless of conditions / plugins / etc., But if you are using the x number of *changes* autosave (in addition to minutes or instead of), there have been plugins that constantly dirty the project for whatever reason and cause the autosave to happen very frequently or even continously (essentially locking up the program). It's not a problem with Sonar itself (and wouldn't matter what version you're using, even my ancient one)--it's doing what it is supposed to...it's the plugin... For me, the one I have this issue with is Shred by AcmeBarGig...but I still use it because it is a "good enough" amp sim for my purpsoes and has a bunch of preset racks that already do the sounds I'm after. I just have ot turn off the x-number-of-minutes autosave in projects I'm using it in. If the plugin is not in the project, there's no problem.

And not all USB3 ports are compliant with USB3 power standards, either (just as USB and USB2 ports may not be). So...sometimes you have to use a separate power source regardless of the port something is connected to. Similarly, the power from such a port isn't always as clean as the adapter that came with a device (though often enough the converse is true).

Iv'e used Sanitycheck, Whocrashed, and Whysoslow from resplendence to track down issues before. I've also used ProcessLasso from Bitsum to temporarily restrict specific things that I can't prevent from running entirely, but that sometimes get in the way and cause glitches in playback or recording,

That usually means that you need to turn down the levels of all the input tracks that feed the combined output to compensate for the total combined track levels being higher than the output can tolerate. You can either turn down the input gain of the combined track, or you can gang (permanently or temporarily) all the output volume controls of the audio tracks feeding that combined track and reduce them all by the same amount. Teh amount you need to reduce by depends on the total number of tracks (and their actual output levels). I tried a quick search for a rule of thumb on how many dB to turn a certain number of tracks down by get that combined output to be below what a combined track input should have, but didn't get any useful answers. (there may be no good rule). So I'd just gang all the faders of the tracks feeding the combined track, and turn them down until it sounds "as clean as the live" output of the keyboard. A compressor / limiter can also do this job but the result will sound significantly different from the way it does when you simply turn them all down by the same amount. The compressor will only change hte volume at the points where it gets louder than the "knee" point you've set in the compressor (or whatever other settings it has; some of them are complex). If you want it to just sound exactly like it would all coming out of hte keyboard at the same time, then unless the keyboard itself has a compressor effect on the master out that is used in combining all the sounds it's playing at the same time (not likely), you're probably giong to get a closer result by turning all the tracks down. BTW, you say the "live midi out of keyboard" but I presume you actually mean the *audio* output of the keyboard, since the midi is just a data stream to tell some other synth what sounds to make and when. If you actually mean something else you'll want to specifiy that, as it changes what you need to do to accomplish your goal.