Xoo

Might have been that to be honest (it was a while ago), but it bugged me a lot anyway. I may re-try when 1.8 is out of beta. UPDATE (January): I can't get it to glitch now, so it may have been an issue with the audio drivers (I was playing using WASAPI at the time, which I find quite unpredictable). I don't think I'm going to keep it installed though - the UI for the synth at least is just too finickety for me to work with.

Groan ?

Or you can create a shortcut to use start /affinity <bitmask> <exename> eg. start /affinity 0x555 cmd.exe starts cmd.exe using cores 0, 2, 4, 6, 8, 10 on my 6/12 core Ryzen.

I like the idea of Surge, but found it extremely glitchy to use (as in audio glitches) - I think there is/was an issue with the release control not being smooth, as it was at the end of notes that I could hear a "click". Or maybe the presets were badly programmed. Either way, it didn't inspire me to keep it installed.

I loved my MMT-8!

And (just in case): Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ASIO for the 32 bit "ASIO" driver.

3.2.3 is the latest anyway (and they sound pretty nice at first quick listen).

Not knowing the exact amount CbB attenuates by, but could it be the difference (when adding up multiple tracks) between 3dB attenuation and a more accurate 3.01dB? db = 20 * log10(amplitude) But it can be cheaper (in terms of CPU) to calculate 6.02 * log2(amplitude), where 6.02 ~= 20 * log10(2)) * * log10(2) = 0.301029996, 20 x log10(2) = 6.020599913 Or different tapers on the pan law (remember CbB - and SONAR before it - can do sin/cos as well as square root)?

This is a good article (I think) about the why's and wherefore's of SMT/HT: https://bitsum.com/tips-and-tweaks/why-you-should-not-disable-hyper-threading-or-why-you-should/ Scheduler and architecture has changed: previously, Windows had a "habit" of using logical cores on the same physical core rather than spreading threads out over logical cores across physical dies.

That's true but within a CPU with HT on, the 2 "cores" are sharing the same hardware.

But there is no physical core (as opposed to logical) as such - a physical core has 1 or more logical cores. All logical cores on one physical core share the same physical hardware, registers etc and to communicate to the outside world.

Citation for this? From a Windows perspective (slight simplification), there are just cores, not virtual (logical) and physical, so it can't assign a thread to a physical core as there's no such thing. A bit old, but clear: https://techgearoid.com/articles/difference-between-physical-cores-and-logical-processors/

There's a phrase for people like you who have studios like that... ?

That is exactly what Freeze does (although on a track, not a clip) - it converts the MIDI+softsynth into audio.

From memory, it's a permissions issue with UAC, because the files are saved in a Program Files subfolder. You either need to run as admin (try not to!) or use the drop-down menu at the top of the window to save presets.

I'd definitely agree with this.

Ah - the old IBM Manual feature.

Given that clip automation does do gain automation, I'm finding it hard to understand what you're after. Can you expand?

At that (high) buffer size, I wonder if it's a case where CbB needs more memory allocated - there's an aud.ini setting that changes this for plug-ins, but I forget the details (ExtraPluginBufs - default 0, I believe). Might be worth digging into that?

No error code, it just (still) says it's not suitable for 2004.

And no PACE driver on my Melodyne 5 machine.

Under 2 seconds here for the CbB 16 track template. AMD Ryzen 5 2600 (6 core/12 threads), stock speed (3.4GHz, but it boosts itself to ~3.75GHz all the time), 32GB RAM, NVMe Windows/application disk, SSD (Samsung 860 EVO 250GB) data drive, 2GB nVidia GT 1030 video card. So nothing that special (for 2020!). Windows Defender realtime scanning disabled completely.

Did you hear about the man who had his house made backwards so he could watch TV?

And, from memory, you can change the filter on multiple tracks using quick grouping.

My bad terminology - I don't mean driver interfaces, I meant using different "driver" APIs (sure, they're not all drivers in terms of pure Windows nomenclature). Rather than having to interface to ASIO, WDM, DirectX, MME, WASAPI, just write an ASIO interface layer and pass the buck to an off-the-shelf translation layer for non-ASIO soundcards.