Amberwolf

Another new WIP: https://soundclick.com/share.cfm?id=15104048

If the old comptuer still works, then you can "simply" copy the projects folders and all subfolders to an external storage device, then connect that to the new computer and recopy them to your new projects folder. Make sure you copy the audio files as well as the projects. If you had authorizations and serials on the old system you may be able to find them (possibly with the help of the ocmpanies that made the software if they're still around) and transfer those to the new one. If you made presets for plugins, you can transfer those over by opening each plugin, even if it's in an otherwise empty project, loading your preset, then saving it as fxp / fxb / etc, onto that external drive, then opening eahc plugin in the new computer and opening each of those and resaving as a new preset in the new computer. (there are other methods, but this one is "guaranteed" to work as long as the plugin is the same version; at least, it has in the few instances I have had to require doing this).

There are a number of things that can keep user files from being transferred from one drive to another, and I have not worked with many techs (back when i was lead tech at a computer repair shop) that had much of a clue that it was even a thing, much less able to deal with them in order to get user data from one drive to another, etc. There are various softwares that can help with this, some automaticaly and some with various user-choices, but again, not many techs either know they exist, or the shops don't have licenses to use them commercially so only the techs that know about them and are willing to (in most cases) illegally use them in a commercial enviroment will be able to use them. So not all data ends up transferred, and some techs will even do stupid things like *move* the data or erase the source drive, without notifying the user. (I stopped working in computer-related jobs because I got tired of being yelled at for other people's stupid choices and actions, both those of the users and of the techs).

A quick search finds this page https://filehelper.com/view that shows these properties. I don't know how accurate it's interpretation is. It shows "adder" is an acidized file, but that "amped" is not. There are probably better waveheader viewers or analyzers. Name:HTHT_125_Hat_Loop_Adder.wav MIME type:audio/wav Size:1 MB Modified:Sep 6, 2023, 2:41 AM Encoding:Microsoft PCM Num Channels:2 Sample Rate:44100 Avg Bytes Per Sec:264600 Bits Per Sample:24 Acidizer Flags:Stretch, Disk-based, High octave Root Note:Unknown (0) Beats:999977 Meter:4/4 Tempo:125 Duration:3.85 s Name:HTHT_125_Hat_Loop_Amped.wav MIME type:audio/wav Size:2 MB Modified:Sep 6, 2023, 2:41 AM

Do you have Jbridge or Bitbridge / etc installed / available, so that 32bit stuff still shows and works in 64bit apps?

(You may already know this, but for other readers that don't): Wave files can be "acidized", so that Sonar knows they are intended to be looped, and what their looping properties are, including their root key (so if you have key changes these will be followed during loop playback in various portions of the song). By default wave files do not have this information in them, and virtually none of the sound libraries I've run across (about 1TB of them in the last couple of years, I think, mostly from Ghosthack, Resonance, BlackOctopus, WAProductions, SampleTraxx, ImageSounds, HollywoodAudioDesign, Cymatics) have acidized their files, so when dropped into any audio editor or DAW, you have to manually turn on the looping function for each clip (wave file) and set it's properties. Without acidization, the only info the DAW has is sample rate and bit depth and file length, AFAICR. However, this shouldn't be the OP's problem, because the said that in CbB they did not have the problem, only in Sonar. My guess is that, assuming the identical files behave differently in the same project in CbB vs Sonar, that there is an issue in Sonar itself for consistently reading the acidization properties of the file. Without an actual cut-down-to-just-the-problem project file from the OP, including the files themselves, can't say for sure. If @Skelm can post such a project, then those here with CbB and Sonar can verify if this is the case, and perhaps work out what the specific difference is?

Random thought: "we can't fire the drummer, he's the only one with our name showing on stage!"

This would not generally be a good thing, if by "inactive" you mean the tracks that are not 'in focus", such as for live-input control, playing new notes in, etc. That would mean that none of your tracks anywhere in the project would feed their controls (volume at minimum) to their VIs, unless you have that track active, so none of your projects would playback correctly. If by "inactive" you mean tracks you are no longer using anything from, or have no MIDI clips in them, then you can either disable their volume / etc controls (rightclick-disable control), or more appropriately, mute them or archive them. Then there are no MIDI controls feeding VIs from these tracks, and there's nothing to worry about. I personally never set the volume controls on any MIDI track at all, or use any MIDI CC volume data in clips or tracks, so the VI will be at it's normal default (often max) volume, and then I will simply control the audio output track's volume instead, almost always via automation in that audio track, or even in individual audio clips once rendered (wherever such clips stack over each other in the same track and must have different gain controls). For any multitimbral VI that has multiple audio outs, I'll assign the MIDI tracks and outputs such that I get each sound I need individual volume control over in a separate audio track. For those MT VIs with only a single audio out, I'll use multiple instances of the VI so I get multiple audio outs, each instance fed by just the MIDI track(s) that all need the same volume control. Using MIDI volume to control VIs requires mapping out your project, tracks, and VIs so that no VI will be getting more than one volume control per controllable instrument within it. Also, at least some VIs don't even respond to MIDI volume controls, or require "user intervention" in their settings to various degrees to cause this to happen. So it is "easier" to not use MIDI volume at all, in many cases, which is why I do things the way I do. Back in the days of only hardware synths, they typically didn't have automatable hardware audio outputs, only the MIDI volume controls, and so it made sense to do it with those; it was really the only option. Initially, VIs were done this same way, but nowadays implementations vary signficantly, and it is easier to just use audio-side controls and ignore the existence of the MIDI ones entirely, for many VIs. Velocity is a completely different thing than volume. You normally don't want any control to override your velocity wholesale, because velocity controls (or should) the performance of the instrument; which sample is being used, how oscillators or ADSRs react, etc., so the actual sound being created is (should be) different based on the velocity, for many instruments. If you set the velocity to be the same on all notes from all tracks feeding a VI, this will "deaden" a performance, making it "lifeless" and uninteresting in many (most?) cases. (there are certain cases where doing this is actually useful but it's not common, and I would be using the Velocity MFX to narrow to a range instead of setting them all the same).

Is it in the excluded list of things? If so you can unexclude it and test to see if there was a good reason for excluding it.

Well, they might, but they're not going to say anything out loud.

My first St Bernard, Nana, did that to the bedroom door when she had to stay in there for a short time while the other dog she had started a fight with was in a different room.... I fixed the door and put a metal plate as it's lower half, so she dug thru the wall next to it instead.

My brother not infrequently drops bottles of soda, and they don't even go ffft when opening them, much less explode like the coke-mentos volcano you'd expect. I would bet that the mentos trick doesn't even work anymore. :roll:

That particular kind of machine is a bit older than me; I've only seen them in some anime shows in country roadside shops....

Test: Close Sonar. Unplug their midi cables, or turn their power completely off. Open Sonar and your project. Playback as many times as desired to verify problem occurs or not. If the problem persists it is not caused by anything on those controllers. If the problem no longer occurs, one of them is possibly sending spurious data causing the event.

Had fizz, at least. (I don't drink soda but my brother complains constantly about how nothing has fizz anymore). And I'm this old (when it was half the price on that pepsi pic and was in bottles)