Michael Elliott

.

Is it possible that reader view is being activated somehow? (maybe the page is listed in the sidepanel reading list?)

It'll have to be a little thicker than that. AFAICR, a large volume of water or liquid hydrogen would do a better job than metal shielding (don't recall why). It's easier and cheaper and smaller to minimize the issue by using three systems, all of which always perform every operation the same way at the same time, with a "voting" (output matching) system that takes a minimum of two identical results to allow an output from the system. It is virtually impossible for them all to get the *same* error, at the same time, from a radiation-induced event, so there should never be a fault from that. If there's enough radiation you could get errors in more than one of the three, causing the operation to have to be redone, and with enough events it could cause delays in system response...but a system without the triplication would just be crashing or otherwise erroring all the time instead, so.... I don't recall the statistics for radiation events at the surface of the planet, but it's pretty low. Since most events pass right thru the matter they enter without hitting anything, the number of events that cause problems is even lower. In areas with planetary magnetic field anomalies and degradation (south pacific for instance) it's higher by quite a bit, and can actually be a serious issue (IIRC some satellites have to shut down when passing thru the SPA area); it can be more of an issue in the north and south magnetic pole areas as well (for the same reason--particulate radiation is channelled via the field down to the surface, which is what causes the auroras). But...even at the lowest, it can still cause glitches in computer / etc operation. Another likely cause of glitches, that you cannot shield against or do anything about, is quantum effects, including quantum tunneling. These also have more effect the smaller the components are; they are one reason that there is a limit to how small/compact we can make devices.

That probably means something else is restoring the "bad" files, probably by reverting changes made (such as to a driver). What else is installed on the machine?

While the neutrinos probably don't do it, there is plenty of particulate radiation that does this sort of thing every day all over the world, from cosmic rays (fast protons, etc) that hit the atmosphere and release multiple further particles that shower down and scatter (some of which trigger lightning, etc). It's more and more of an issue as we make smaller and smaller circuits, especially memory devices, as it becomes easier and easier for a single tiny particle to have enough energy after it makes it thru all the solids to hit the silicon and either change the charge on a memory cell, or actualy damage it.

If you mean the "shortcut manager" you specify in the title of the thread, Cakewalk has had one for a very long time, as far back as I can remember. It's under Options KeyBindings in my version. It doesn't show a keyboard as your graphic for Unity does, and it's kinda unrefined and not as easy to use as it could be, at least as of the old version I use, but it's there, and you can assign or reassign most of the shortcuts in the program to suit your needs. It even has presets to emulate other DAWs' shortcut arrangements, and you can save your own setups and switch between them as needed. (so you could have a setup that makes all the stuff you need instant access to for a specific workflow like recording / comping / etc in easy, then another that makes workflow like midi editing easy, etc). If you mean something else, then be as specific as you can about what you're after.

You reference "keyboards", "recipient MIDI software", and "soft synths" separately, but it sounds as if you are using them all to refer to the same thing. If this is not true, please explain what you mean by each one, specifically. (it might make a difference to the troubleshooting) If they do all refer to the same thing, then it means that the soft synths *do* output audio, but only from clips/notes already on the track(s). If that's not true, please explain the specifics. If these are both true, then the only thing I can think of offhand is that input echo is not turned on for the tracks, or something has gone wrong and IE is not working. Without IE, data will record to the track, and play from it, but it will not be passed directly from the input to the output for live playback of that input.

Way way back when I was at deepfry...er, DeVry learning electronics, we had to use the 6502(?) MCU box with hexadecimal keypad to do something "interesting" or the instructor would not pass you (regardless of your actual grades), so I used it to drive two dacs to make the Reliant scoot across a 'scope screen and shoot at the enterprise that just sat still (both in side view cuz they could just be straight lines and very simple). Wanted to do the whole mutara battle but I barely figured out how to code just that, and it took *hours* to key into the MCU via the keypad (there was no other way to input it, and if it lost power, made a mistake, or lost your place, you started over). Somebody else did "pong", I don't remember anybody else's.

122224 000001 000021g -- first public version. https://amberwolf.bandcamp.com/track/if-i-should-wake At only 30 seconds***, it's likely this is just going to be the intro for a long evolving track. This one is another experiment with "misusing" sounds from assorted sources (mostly Ghosthack and Cymatics for this one) and building something around them after dropping them randomly in the track view, then rearranging (a lot) to make it musical, and begin forming what I want out of it, as I begin to hear something coming together. ***with two new sections now added, it's up to a bit more than a couple of minutes now. BTW, if you like the theme from "The Expanse", I've been told that the third section bears some resemblance in sound. I haven't gone to compare them directly yet, but I certainly liked that theme (the whole show actually, not just the music) so I'm surprised that I didn't hear this resemblance myself. 😊 assorted tiny timing changes, stretched a few small sections of some clips to better flow 12-29-24: 122224 000001 100035j -- first extension and transition, using some of the same pieces as the first section (re-edited for the new one) plus some edited (retuned, snipped, processed, etc) parts of clips from Ghosthack's beautiful Shymer collection. 12-30-24: 122224 000001 100042k -- extensive small edits, added sounds, altered pitches, etc. Note the second section is stylistically different from the first; connected by the sounds and some of the musical phrasings. Only adds another minute for a total of about 1 and a half minutes total, enough to leave you wishing for more. 12-30-24: 122224 000001 200063p -- second extension and transition (this section is more "cinematic"). Still under 3 minutes so far; am working on section four now, which will probably add another minute or so. 12-30-24: 122224 000001 200069r -- extensive small edits in all sections 12-31-24: 122224 000001 200071s -- extensive small percussion and timing edits. BTW, if you like the theme from "The Expanse", I've been told that the third section bears some resemblance in sound. I haven't gone to compare them directly yet, but I certainly liked that theme (the whole show actually, not just the music) so I'm surprised that I didn't hear this resemblance myself. 😊 1-1-25: 122224 000001 200076u -- extensive small percussion and timing edits. 1-4-25: 122224 000001 200080w -- extensive small percussion and timing edits, mostly removing percussion tha was "in the way" of other things.

Necrotopic REVIVE! Is there any way to "block" a plugin (VST) from sending parameter changes, to prevent the autosave triggering? Note that I'm still using an ancient SONAR (happens even in in 6, 7, etc) , so no answer from devs is expected, but anyone with insight is welcome to respond with useful feedback. 😉 I know it's a plugin issue, not cakewalk/etc. I use Acmebargig's Shred, and any project with it in there, *even if it's disabled in the bin*, will instantly dirty the project when I save the project. I can let the project just sit there, and eventually it will autosave on it's own long before the timed autosave. It's even worse if I am doing anything, especially play/stop/play/rewind/stop/click in timeline/play/stop/etc--it may autosave everytime I hit stop, and sometimes do it several times in a row before I can even do the next thing, with my finger already pressing the next editing key. There is no automation feeding Shred, and it doesnt' matter if it's UI is open, minimized, or closed. Or if the track's automation read RD button is disabled or not. Or bus vs track vs clip fx bin. Just having Shred in the project causes it. I use autosave at every 100 changes, 10 minutes, which I've found is a reasonable balance between annoyance of autosave at the wrong moment and data loss. I also frequently SaveAs with a new filename using my own versioning system with tiny notes in the filename, but the autosave is "just in case" and sometimes is useful for recovering from a stupid or a plugin hang or crash with minimal editing loss. Upping the changes number to something ridiculous slows the process down, but doesn't stop it, and then it doesn't autosave for my real changes after I delete the plugin. Oddly, it does not *appear* to autosave more often if there are multiple copies of the plugin in different track bins (using different heads/chains), which seems wierd...but it happens so often anyway, it's not easy to tell if this is really true. AFAICR its' the only plugin I use that does this...but it's annoying enough that whenever possible I bounce the clips used with it and delete it from the project. However, there are many projects I can't do that for a long time because I'm working a lot directly with the source clips that feed it, tweaking them (or the shred setup itself) for the "right sound". I have other amp sims, but this one has a bunch of presets that are already close enough to what I want that I use it a lot.

I'll have to check that one out. Except for the mono part, I do that with the old Sonitus Multiband Compressor, with a preset that essentially disables the compression/limiting, and just lets me solo each of the 5 bands (you can solo all of them or only one or a few), to mute the other ones. But it looks simpler in Isol8. I've used ChannelTools to do different stereo/mono filtering, but I don't do much of that so don't know it all that well.

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)

Above posts' content transferred to the first post instead, based on feedback in a different song thread that said new posts for the updates wasn't a good idea.

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 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.