ReBuzz

[wde]

Only dtblockfx is having major issues I think.

fftw_2.1.3_float.dll (or any other dlls needed by 32 bit machines) needs to be in bin32 folder.

Song loading time is improved in the latest release. You can also try to set an exception for ReBuzz.exe process in Windows Defender if starting up ReBuzz takes too long.

Note that you can enable CheckForUpdates from settings for automatic updates. Please follow the development and releases here.

[thepedal]

Nice one, thanks. That fftw_2.1.3_float.dll catches me every time I try and set up Buzz from scratch! Use dtblockfx probably more than I should!

[thepedal]

[21:30:33 ERR] Index was outside the bounds of the array.
[21:31:09 INF] Audio Driver Error: Cannot access a disposed object.
Object name: 'Microsoft.Win32.SafeHandles.SafeWaitHandle'.
[21:31:09 INF] WavePlayer error: Error code [ASE_InvalidMode] while calling ASIO method <start>, hdspf init failed
[21:31:22 INF] Audio Driver Error: Cannot access a disposed object.
Object name: 'Microsoft.Win32.SafeHandles.SafeWaitHandle'.
[21:31:22 INF] WavePlayer error: Error code [ASE_InvalidMode] while calling ASIO method <start>, hdspf init failed

This stuff plagues me when I'm trying to change asio settings and generally switch audio driver.

Quick (pos dumb) question. Is the built-in Asio in ReBuzz effectively Polac Asio MK2 and there's no point/need/sense in putting the Asio driver bits from pvst64_v1.1.10b42.zip or whatever into the install dir? I kinda miss the Polac Asio menu which lets me pick a specific output rather than rely on the one my soundcard Asio menu wants me to use.

[thepedal]

Also.... anyone know what this is looking for?

[23:03:54 INF] System.IO.FileNotFoundException: Could not load file or assembly 'C:\Program Files\ReBuzz\Gear\Generators\ReBuzzPatternXP.NET.dll'. The specified module could not be found.
File name: 'C:\Program Files\ReBuzz\Gear\Generators\ReBuzzPatternXP.NET.dll'
at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
at System.Reflection.Assembly.LoadFile(String path)
at ReBuzz.ManagedMachine.ManagedMachineDLL.LoadManagedMachine(String path)
at ReBuzz.FileOps.MachineDLLScanner.ValidateDll(ReBuzzCore buzz, String libName, String path, NativeMachineHost nativeMachineHost, NativeMachineHost nativeMachineHost64, String buzzPath, IUiDispatcher dispatcher)
at ReBuzz.FileOps.MachineDLLScanner.ValidateDlls(ReBuzzCore buzz, NativeMachineHost nativeMachineHost, NativeMachineHost nativeMachineHost64, List`1 machineDllFiles, String buzzPath, IUiDispatcher dispatcher)

[mcbpete]

Does ReBuzz get an update when Polac posts a new version of the PVST loader (like today which specifically lists reBuzz loader improvements), or is it still best to manually update the version of PVST after updating rebuzz ?

(and if so, do we grab the x86 or x64 version ... or both !)

[mcbpete]

Just updated rebuzz to the latest version and then added todays release of Polac (b45) to it as I saw the existing vst loader is from August last year, and it still takes about 3 minutes to fully load and then about 2 minutes to add any VST2 or VST3. In comparison booting up 'regular' buzz only takes about 5-10 secs, and <5 secs to load a chunky VSTi (something like something from Arturia's V-Collection)

[HerrFornit]

Does ReBuzz get an update when Polac posts a new version of the PVST loader (like today which specifically lists reBuzz loader improvements), or is it still best to manually update the version of PVST after updating rebuzz ?

(and if so, do we grab the x86 or x64 version ... or both !)

ReBuzz is 64 bit only (?) So x64?
I expect that wde will add the new PVST to ReBuzz in one of the next versions.

Just updated rebuzz to the latest version and then added todays release of Polac (b45) to it as I saw the existing vst loader is from August last year, and it still takes about 3 minutes to fully load and then about 2 minutes to add any VST2 or VST3. In comparison booting up 'regular' buzz only takes about 5-10 secs, and <5 secs to load a chunky VSTi (something like something from Arturia's V-Collection)

You never know: Does RB have full access to your VST folders? (right management, folder protection...)
For interest: How many VST are in the VST folder?

[mcbpete]

For interest: How many VST are in the VST folder?

*ducks behind wall slightly* ahem..... maybe just over 2000 .... *runs*

[polac]

You only need the x64 version. Also just unpacking the zip to ReBuzz folder doesn't work. You have to put some files to the bin64 folder.

Here for example you have to put the machines.x64.dll which does the vst scanning: C:\ReBuzz\bin64\Gear

To speed up the startup you can disable the vst scanning completely in the loader preferences. But i don't get it that the difference between Buzz and ReBuzz starting is so different for you.

[mcbpete]

You only need the x64 version. Also just unpacking the zip to ReBuzz folder doesn't work. You have to put some files to the bin64 folder.

Here for example you have to put the machines.x64.dll which does the vst scanning: C:\ReBuzz\bin64\Gear

Yeah I noticed I had to play a bit of detective work to move the right files into the right place for reBuzz Pretty sure I'd moved everything correctly (looked for anything on your zip dated this month and found the matching file in the various Rebuzz sub folders )

[richb]

Just updated rebuzz to the latest version and then added todays release of Polac (b45) to it as I saw the existing vst loader is from August last year, and it still takes about 3 minutes to fully load and then about 2 minutes to add any VST2 or VST3. In comparison booting up 'regular' buzz only takes about 5-10 secs, and <5 secs to load a chunky VSTi (something like something from Arturia's V-Collection)

I'm still seeing slow VST3 loads as well (for me startup and VST2 loads are now very quick once both the new 'scan on startup' options are disabled)

Like you, I have a fair few plugins - about 300 VST3. I did a little digging with process monitor - it looks like it's a cumulative effect of a small delay spread over a large number of plugins.

It seems the shell plugin goes through the whole VST3 directory - I don't think it's 'scanning' as such as it's not calling LoadLibrary or anything - I think it's just checking to see if they've changed / working out if it needs to rescan them?

Anyway, each time there's a 'QueryBasicInformationFile' event, which I think is grabbing the creation/modification time for each plugin, there then follows a ~100ms delay. Small enough not to notice unless you've got, say 300 plugins, at which point that turns in to a 30 second load time. I guess if you've got 2000 and a faster PC then me it translates into 2 minutes.

Screenshot 2025-07-15 205804.png (72.47 KiB) Viewed 98 times

I've no idea what happens in that gap as my 1337 hacker skills don't extend as far as disassembly, but something's causing a hiccup that's small enough it'd be super easy to miss - with a sane number of plugins it'd be dwarfed by the time it takes to actually instatiate the plugin you've chosen (which happens after this dive through the VST3 dir)

[oskari]

it's most likely FileInfo (.Length/Size?) in C#. I remember similar effects.