buzz forums
http://forums.jeskola.net/

Buzz 64
http://forums.jeskola.net/viewtopic.php?f=2&t=1751
Page 2 of 2

Author:  mcbpete [ Mon Feb 04, 2019 12:20 pm ]
Post subject:  Re: Buzz 64

Yeah I'm on Windows 10 - I guess I can have Buzz32 installed for legacy use and Buzz64 for any future projects that need any hefty VSTis.

Author:  boombaxx [ Tue Feb 05, 2019 5:29 pm ]
Post subject:  Re: Buzz 64

I use buzz 64 because of NI Kontakt and it's big built in libraries. Which is more than 3 gig limit of buzz 32. Although buzz 32 is more complete because u cannot use native 32 bit buzz machines in 64 unless u load them thru polac loader

Author:  mcbpete [ Wed Feb 06, 2019 12:49 pm ]
Post subject:  Re: Buzz 64

boombaxx wrote:
u cannot use native 32 bit buzz machines in 64 unless u load them thru polac loader
Aha - That's probably where all my crashes were coming from, I didn't realise the native buzz machines had to be bridged in Buzz64. Weirdly I could get [some] of them to work with new projects and they just had the text '32' in the corner but it definitely wasn't stable...

Author:  boombaxx [ Sun Feb 10, 2019 2:08 am ]
Post subject:  Re: Buzz 64

I have been using 64 bit Buzz since the first version i have had very few problems. It is a fork of 32 bit that was pretty stable anyway. I only use a select few machines that i can rely on. It would be nice if there was a way to use buzz bmx's in daws like reaper. I have seen buzz type interfaces for reaper

Author:  mcbpete [ Sun Mar 10, 2019 7:56 pm ]
Post subject:  Re: Buzz 64

Well not sure how it does it but just tested Buzz 32bit to its limits with some meaty Kontakt and Falcon libraries (both of which being the 64bit version of the VSTs):

Image

So does the vst.x64.exe bridge operate in 64bit mode hence how it can address this amount of ram in an individual process, and yet somehow work realtime with a 32bit application. Surely this is witchcraft ?! :o

Author:  UNZ [ Tue Mar 19, 2019 3:46 pm ]
Post subject:  Re: Buzz 64

mcbpete wrote:
So does the vst.x64.exe bridge operate in 64bit mode hence how it can address this amount of ram in an individual process, and yet somehow work realtime with a 32bit application. Surely this is witchcraft ?! :o


yes it starts a new 64bit process and shoves the audio back and forth from 32bit buzz to that 64bit process via IPC (inter-process-communication). That IPC probably has some slight overhead, but the benefits of this working at all far outweigh that of course. The same is true if you load a 32bit plugin in 64bit buzz. This feature is quite remarkable as many commercial hosts have not bothered to implement this at all.

Author:  IXix [ Tue Mar 19, 2019 10:07 pm ]
Post subject:  Re: Buzz 64

UNZ wrote:
This feature is quite remarkable as many commercial hosts have not bothered to implement this at all.

Amen to that! Heavy skills round here. :dance:

Author:  boombaxx [ Thu Mar 28, 2019 1:34 am ]
Post subject:  Re: Buzz 64

It is amazing how buzz has become what it is today. When i first used this program i was using a cyrix 400 256mb win 95 wondering after adding a few things why everything was stuttering. The infector was my fav now it,s incredibly detailed sound librarys and synths. Buzz 64 is more for sample based music it removes the 4 gig limit up to 128gb. If you want to use buzz machines in Buzz 64 try Polacs machine.

viewtopic.php?f=3&t=7

Author:  pac [ Sat Jul 20, 2019 8:03 pm ]
Post subject:  Re: Buzz 64

mcbpete wrote:
just deleting some machines may cause a crash


Gravedigging a bit, but I wanted to post my solution to this problem, which I've encountered specifically in Buzz64 on Win10: deleting machines often causes a crash in the auxiliary BuzzEngine32.exe.

Being stubborn, I patched the binary so that the offending code would not execute. Quick and hacky, but now it works fine and I've been using my patched Buzz 64 ever since. You're probably better off using Buzz 32, but if anyone's interested, I'm attaching the patched binary. (I guess this might seem shady but you can always compare it with the original build 1503 and confirm that I only replaced a couple of instructions with NOPs).

Attachments:
BuzzEngine32_pac_patch.zip [65.71 KiB]
Downloaded 39 times

Author:  oskari [ Wed Jul 31, 2019 1:41 pm ]
Post subject:  Re: Buzz 64

pac wrote:
mcbpete wrote:
just deleting some machines may cause a crash


Gravedigging a bit, but I wanted to post my solution to this problem, which I've encountered specifically in Buzz64 on Win10: deleting machines often causes a crash in the auxiliary BuzzEngine32.exe.

Being stubborn, I patched the binary so that the offending code would not execute. Quick and hacky, but now it works fine and I've been using my patched Buzz 64 ever since. You're probably better off using Buzz 32, but if anyone's interested, I'm attaching the patched binary. (I guess this might seem shady but you can always compare it with the original build 1503 and confirm that I only replaced a couple of instructions with NOPs).


Very interesting. :) Did you figure out what exactly was wrong with it?

Author:  pac [ Tue Sep 03, 2019 12:42 am ]
Post subject:  Re: Buzz 64

I did not pinpoint the exact problem, but I made an effort!

First, the steps that reliably produce the crash for me:
    - Open Buzz x64, add any 32-bit generator (eg. Infector) and any two 32-bit effects (eg. cheapo amp), all connected in a single chain to the master
    - It should now look like this: Infector -> ch.amp -> ch.amp -> Master
    - Delete the generator or the effect that's connected to it
This causes a crash on my "new" Win10 laptop, but did not cause a crash on my old Win7 laptop, so it's annoyingly system-dependent, somehow.

If you can reproduce the crash, then I guess that's all the information you need. So I'm not sure if the following stuff is useful, but I'll include everything that I possibly figured out while making my hacky patch:

The crash is an access violation in BuzzEngine32. It occurs inside something that looks like a large `switch`/`case` statement that has a `case` for each type of BuzzEngine32 call. When you make the problematic machine deletion, the `case` for DeleteInput gets called twice. The first call works fine and calls cheapo amp's CMachineInterfaceEx::DeleteInput, but then there's the second call, where the code attempts to retrieve and call a null function pointer instead of a machine's DeleteInput method.

I haven't figured out much beyond this. There's clearly something wrong with the second DeleteInput call, maybe it's happening on the deleted machine? And when I delete the generator, maybe there should only be one call to DeleteInput, because if I do this:
Infector -> ch.amp -> Master
...and I delete the generator and step through the assembly, the DeleteInput case only gets called once and there's no crash. So why does it get called twice when there are multiple effects in the chain? Anyways, that's as far as I debugged.

As for my hacky solution, I think I just NOP'ed out the call to CMachineInterfaceEx::DeleteInput. So it never gets called for 32-bit machines in my patched version, which might cause its own issues, but I haven't noticed them.

Page 2 of 2 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/