Amberwolf

I most certainly would love #2.

Equalizer APO should be able to do what you want--I keep intending to try it out, to sit between the system default audio output for windows and the actual audio hardware (effectively). https://sourceforge.net/projects/equalizerapo/ In the meantime what I use is VSTHost https://www.hermannseib.com/english/vsthost.htm to setup my fx chain (presently just mda multiband, used to highly compress, eq, and limit all audio output from everything *other* than audio editing programs so I can't be surprised / annoyed by all the volume variations from video playback/streaming, etc). But it is complex to setup, and totally unintuitive for how to save your settings and setup. To get audio into and out of it, I use VB-Audio's virtual cable https://vb-audio.com/Cable/ as the system default audio device, as the input to VSTHost, and VSTHost's output is the secondary speakers on the laptop audio device (because that way I have a physical separate volume control knob for those vs my audio-editing speakers, so I never touch the AE levels so I always have the same reference level for AE).

I can see it now--they buy the ASIO4ALL project and build it in as a layer...like they did with certain things many years ago when they bought Bars&Pipes from Blue Ribbon Software (or maybe they bought the whole company?) so they could have something in the DirectX devkit (for what reason, I don't know) just as BRS was getting the Windows version of B&P ready (it had been Amiga-only before that). (this was the reason I ended up getting into Cakewalk, because it meant that B&P would never be available for Windows and I had to move to it from Amiga....)

From the very very little coding I have done (mostly arduino, esp32, rpi recently), *nothing* is "just" a recompile for a different platform and/or cpu/mpu. With luck, that's not true of situations like this, but....

I'd guess they've changed the way it works in the last >decade-and-a-half-plus since my version was made. In mine I don't have to select the group as long as I have the option enabled to select all the group members if I select any of them...but even if I try it the other way by manually selecting them all, and nothing that's not in the group, it will still only do the same edits the same way--slip edits, splits, clip-fades, etc only work on time-aligned/overlapped clips, in my version. But it's still useful and a timesaver, and I'm still glad of the reminder of the feature that made me go re-explore it!

Well, that pile is almost big enough. Almost, for the morning snack, at least. (for me.... the dog wants bread instead, dunno why)

New version 10 120524 000001 000085y https://amberwolf.bandcamp.com/track/a-peek-over-the-wall Assorted minor edits and mix changes, replaced some shakers with dog pants from JellyBeanThePerfectlyNormalSchmoo, added some crow sounds. I couldn't get JellyBean to pant in time with the notes so used Audiosnap and dragged the markers around as needed to fit. Timing not perfect yet but had to move on for the moment; couldn't listen to the looping of the short section anymore tonite. 😢

One unfortunate side effect of having to make filters to catch spammers...higher moderator workload, annoyance to regular users. But often better than immense amounts of bot spam. (I've had to use this method extensively when we had bot floods)

I'd forgotten about that feature; I never got it to work in my ancient SONAR...but i just rechecked it out in my ancient version and found that I had simply missed setting the correct editing options within Global options - Editing (it was set so that edits did not autoselect other clips, and so that splits created new groups instead of leaving them in the old ones). But, even with them set correctly some edits don't affect all the clips (just those that are at the same "time" as the one being manipulated). (split, drag-edge for fades or length changes, etc) Some edits don't affect any clip except the one you actually clicked on, such as adding clip envelopes, etc. Maybe the newer versions are different? Some edits don't affect the clips as just themselves, but act (perhaps as expected, though not as desired in this case) as if you'd just selected all those clips, like bouncing to clip--any clips on the same track that are part of a group are turned into a single clip, though those on a different track are not combined with them, which is good--but it would be nice if they were bounced each to their own clip. (perhaps is different in newer versions but I doubt it; it's probably not desirable for many users as it's different than the usual behavior). (also, the bounced clips are no longer grouped at all, which is also probably expected behavior but not desirable in that now you would have to re-group them after you figure out which ones they are). Still useful and will do a lot of what I want, so thanks for bringing it up!

I've been poking around at mixing tweaks, and ran into a wierd issue that took several days to figure out the cause of; the cause is listed at the end, in case anyone ever runs into this, but it's wierd, and doesn't make any sense to me. It's quite likely that whatever wierdness caused it isn't even present in current versions of Sonar, but I don't have those to verify, so this is just archival info partly so I can refer to it later if I ever run into the issue again. Removing some unused empty archived tracks (mostly MIDI) suddenly caused all synths to stop receiving any MIDI from their tracks. The MIDI tracks feeding them all had signals on their MIDI meters, so they were outputting data, but none of the synths were receiving any. The synths would work if I played them from their internal keyboards in their GUI, but not from any clips on any track, even re-routing tracks to other synths, or inserting new synths, or deleting all synths and making new synth tracks, etc. Same for the MIDI tracks--I even made new tracks to route to existing (and later new) synths, and drew in notes that should've worked, but didn't. Undoing all the way back to the original empty archived track deletions did fix it.... but nothing about those tracks could affect the others, even if they weren't archived they had no data on them, etc. Certainly shouldn't make all synths suddenly unable to receive midi data. Redoing the deletion, then changing the midi buffers in Global prefs from the 25ms I always use (without issues) to 250ms (because adding a zero was fast and easy) also fixed it, but anything less than 250ms would not work, even though the projects all work fine with a tenth of that (except for this one after the track deletion). So I deleted the empty archived tracks one at a time until I found the specific one that did it, and it had two disabled MFX in the bin--Track Doorman by TenCrazy, and Quantize by Cakewalk, in that order. Removing TD would cause all synths to not work, but removing Q didn't affect anything. Neither should affect anything, as neither one is in an active track, and this track is archived as well as empty. Adding a TD to the track doesn't fix the synths, *only* undoing the original TD deletion. Tried rerouting the track midi output to all possible ports, channels, but still deleting the TD or the track would nuke the synths MIDI again. Moving the TD to *any* MIDI track in the project, active, inactive, archived, empty, or with data, still allows the project to work as normal...and removing the empty archived track doesn't then cause any issues. No other TD (existing or added now) causes this problem when removed...just this one. 😕 So I just left the disabled TD in one of the tracks, and the project works fine...but I have no idea how removing a disabled MFX (that was in an empty archived track!) could break all MIDI in a project. Back to the irregularly unscheduled updates of the track, now that I can work on it again.

I don't know that there's a "good" way to implement undoable input-quantize, because it is altering the data *before* the clips are created, so the clips don't have the unquantized data--that is gone. It would require storing all of that track's original input as well as the IQ'd input. The "easy" way to implement the undo would affect everything on the track--it would unquantize all clips on that whole track, which you probably wouldn't want. It would be possible to store the data per-clip, but is likely a lot more complex to program. Assuming the feature doesn't get implemented (or at least until it does, if it does), you could use one of these (or other) options: The following "solution" doesn't have all the qualities that IQ does, but it would at least let you undo. It doesn't alter the way the data is displayed on the track, so if you need that, this won't help--it only affects the way the data is sent to it's destination: Instead of IQ, use the Quantize MFX per-clip, in the clip FX bin of each clip, so that you can keep altering the quantize properties as needed, or disable it entirely, toggle it on/off, etc., and have the clips that need it using it, and the clips that don't left alone. (or use it in the track FX bin if you want the same settings on the whole thing, but IIRC you can't alter, apply or undo just part of it that way). If you use it per-clip, you can apply the FX to permanently alter it and have it display as quantized for stuff you're sure of. The following alternate "solution" does have the qualities of IQ (except it's not automatic), and lets you undo, and it does alter the way the data is displayed on the track: Record normally without IQ, then copy the results to a muted or archived track. Then quantize the original as needed, and if you need to undo, that is still in the other track. There are probably other ways to do this, too, but those are both ways I've used.

There are also a couple of possible solutions in this thread:

In Device Manager (in the System control panel, I think (they keep changing where things are in Windows control panels in various updates), but can be accessed a number of ways, including rightclicking on My Computer icon and choosing Manage), you can double click on a specific device and look at the drivers tab. There is usually an option to revert to a previous driver. You may need to uninstall the NVidia software suite first to try the Microsoft built-in driver, but you can try it without that first. Keep in mind that this is just a guess as to what's wrong and isn't a high chance of fixing it...but it's worth trying.

I have had a number of recent projects where this would be a handy function (especially where I am messing with a bunch of separate parts of a "kit" of sounds, and want to alter each of the separate parallel clips in the same way (but still have them on separate tracks and/or buses for different fx chains, etc). Some edits can be done the same to multiple parallel clips at once, simply by selecting them all before performing the action: --split --click-drag length from beginning or end --copy or move (probably others I can't recall ATM) Splicing clips (bouncing multiples down into one) couldn't be done this way because it would bounce them all to one clip instead of leaving them as separate tracks.

Are you using the NVidia drivers? If so, can you try reverting to the base Windows drivers instead? Or, if you are using the base Windows drivers (by Microsoft, rather than NVidia), then try the Nvidia drivers. I have had odd display issues with Nvidia-specific drivers now and then over the years ever since they started up (often in 3D-modelling programs doing 3D rendering, but sometimes in the regular parts of various programs. I don't recall an issue like this specific one you have, but it wouldn't surprise me if it turns out to also be an issue).