Buzz 64
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.
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
Re: Buzz 64
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...boombaxx wrote:u cannot use native 32 bit buzz machines in 64 unless u load them thru polac loader
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
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):
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 ?!
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 ?!
Re: Buzz 64
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.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 ?!
Re: Buzz 64
Amen to that! Heavy skills round here.UNZ wrote:This feature is quite remarkable as many commercial hosts have not bothered to implement this at all.
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
viewtopic.php?f=3&t=7
Re: Buzz 64
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.mcbpete wrote:just deleting some machines may cause a crash
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 367 times
Re: Buzz 64
Very interesting. Did you figure out what exactly was wrong with it?pac wrote: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.mcbpete wrote:just deleting some machines may cause a crash
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).
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:
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.
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
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.
- temporalsounds
- Posts: 134
- Joined: Sun Jan 27, 2019 3:29 pm
- Contact:
Re: Buzz 64
pac wrote:I did not pinpoint the exact problem, but I made an effort!
Last edited by temporalsounds on Wed Mar 25, 2020 11:11 pm, edited 2 times in total.
Re: Buzz 64
Is it possible to have both 32 and 64 installed? Do they use the same registry keys?
For music I'll stick with 32 but it would be good to be able to test my machines on 64. Got a new laptop at last!
For music I'll stick with 32 but it would be good to be able to test my machines on 64. Got a new laptop at last!
- temporalsounds
- Posts: 134
- Joined: Sun Jan 27, 2019 3:29 pm
- Contact:
Re: Buzz 64
YesIXix wrote:Is it possible to have both 32 and 64 installed? Do they use the same registry keys?
Last edited by temporalsounds on Wed Mar 25, 2020 11:13 pm, edited 2 times in total.
- temporalsounds
- Posts: 134
- Joined: Sun Jan 27, 2019 3:29 pm
- Contact:
Re: Buzz 64
Today ,I tried to run Buzz32 and Buzz64 at same time.IXix wrote:Is it possible to have both 32 and 64 installed? Do they use the same registry keys?
- Attachments
-
- buzz 64.JPG (396.77 KiB) Viewed 9806 times
Last edited by temporalsounds on Sun May 31, 2020 12:19 pm, edited 3 times in total.
Re: Buzz 64
I can't imagine ever wanting to run them simultaneously! If they can live happily on the same system without messing up each other's settings then that's all I need. Looks promising.temporalsounds wrote:Today ,I tried to run Buzz32 and Buzz64 at same time.
Re: Buzz 64
@temporalsounds
Sorry for the OT.
Would you mind to share your Buzz Skin? Looks ace
Oh, and Happy New Year to everyone
Sorry for the OT.
Would you mind to share your Buzz Skin? Looks ace
Oh, and Happy New Year to everyone
- temporalsounds
- Posts: 134
- Joined: Sun Jan 27, 2019 3:29 pm
- Contact:
Re: Buzz 64
Oh,if you mean off topic,you don't need to apologize viewtopic.php?f=2&t=2386domtron wrote:Sorry for the OT.
Would you mind to share your Buzz Skin? Looks ace
Last edited by temporalsounds on Wed Mar 25, 2020 11:12 pm, edited 1 time in total.
Re: Buzz 64
I've been using Buzz 64 with the patched version of BuzzEngine32.exe by pac. No issues with few 32 bit Buzz machines I'm using. Seems to be very solid fix!
The only issue that I've noticed is that if you drag&drop a machine from the 'More Machines' list, I get an error saying: "LoadLibrary(...) failed. %1 is not a valid Win32 application."
However, if I copy the machine directly to effect/generator folder in my Buzz 64 setup I can run the machine without issues. Any fix for this?
Would be great to get these fixed in the official build.
The only issue that I've noticed is that if you drag&drop a machine from the 'More Machines' list, I get an error saying: "LoadLibrary(...) failed. %1 is not a valid Win32 application."
However, if I copy the machine directly to effect/generator folder in my Buzz 64 setup I can run the machine without issues. Any fix for this?
Would be great to get these fixed in the official build.