Amberwolf

"Finished" it, now called Drywater, Mars: https://amberwolf.bandcamp.com/track/drywater-mars What do you see when listening? I kind of visualize the opening of a Firefly-like TV show or movie where a cargo ship is coming in to land at Drywater while the townspeople look up at it; starting from the POV near the ship itself, watching the pilot struggle to keep the overloaded ship shiny side up and get it down safely while the crew tries to keep containers and cargo from going over the sides. :lol:

Is that the fender asstocaster?

FWIW, if you did want to scale the actual velocity, MIDI tracks each have the Vel+ control that is center-zero-offset, that you can use to do this, if your instruments work the right way to do this. If your trackview is setup not to display this control, you can manually show it (don't know how in the newer Sonar, but I can't imagine they took that away). Lowering the volume on the track via MIDI *or* audio shouldn't scale or otherwise alter the velocity in any way., Just to expand, for future readers of this thread that don't know the details of MIDI and instrument functions: As long as the instrument you use doesn't create any difference at all in the sound produced by one velocity vs another, then that technique works fine. But anything that uses velocity to control the actual sound (whcih is common) won't give the result of just changing the volume if you scale or alter the velocity--it may change the volume, but it also changes which sound is played. A simple example is piano, where touching a note lightly makes a significantly different sound than striking it harder does, in a well-made piano synth. Most of the multitibral rompler synths I've used over the years don't have multiple samples to use the velocity this way, so they respond fine to using velocity as a volume control, but stuff like even just TruePianos that came with some SONAR versions uses velocity like the real instrument would, with different samples being used for different velocity levels (at least for different ranges of velocity), so this technique does not work on those in the expected/desired manner--they do get quieter or louder, but they sound different as well. There are also some instruments that don't respond to velocity at all, though that's rare and I can't remember the couple I had that were like this as I haven't used them in a very long time. (one was hardware, and it didn't have a velocity-sensitive keyboard either, the other was a VI; there might've been two or three of those). For these rare instances, then like those VIs that don't respond to MIDI CC7 (or other CCs) for volume control, you have to use their audio track's volume instead.

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: