Notebook
Re: Notebook
@wde I found that Notebook wouldn't load properly in Buzz64 so I tried building it myself. I had to use the 64bit BuzzGUI dlls as references and set the platform to x64 rather than 'Any CPU'. I guess that makes sense but in my ignorance I thought managed machines didn't care about x86/x64. I don't know much about this new fangled stuff.
Re: Notebook
Very nice! I don't have Buzz 64 installed so thanks for trying this out.IXix wrote: ↑Wed May 06, 2020 9:10 pm @wde I found that Notebook wouldn't load properly in Buzz64 so I tried building it myself. I had to use the 64bit BuzzGUI dlls as references and set the platform to x64 rather than 'Any CPU'. I guess that makes sense but in my ignorance I thought managed machines didn't care about x86/x64. I don't know much about this new fangled stuff.
Perhaps there is something 64 bit specific in the dependencies that require forcing platform to x64 in a .NET dll. Seems to be pretty simple and straightforward exercise. Next you can try AudioBlock
Re: Notebook
if you have any native code dependencies you have to ship both versions of the native dll iirc... and ANY cpu won't work then i think, so you still have to have two .net dll versions...
Re: Notebook
That makes sense, thanks.
@wde AudioBlock won't load in Buzz64, same issue.
Supporting diferent reference platforms is awkward. You'd think that if BuzzGUI.dll is in two paths and using one of them throws a warning, the compiler might be smart enough to try using the other instead but no, that would make life too easy. Maybe that's something the non-free versions of VS do?
Anyway, I found this at StackOverflow and it seems we have two options:
1. Have separate projects for x86 and x64 builds, so each can reference the appropriate set of Buzz dlls.
2. Edit the project file yourself to add conditional stuff so it works properly based on the active solution config.
I tried option 1. The solution is set to AnyCPU, the x86 and x64 projects are identical except for the reference paths and post-build file copying commands. Both are set to build with AnyCPU as the target platform and both work fine in their respective Buzz versions.
In the process of trying to figure out what was what, I added explicit x86 and x64 configs too. I don't know if there might perhaps be some performance advantage in using those instead of AnyCPU so I left them in place. I also changed the build output paths so the files don't get output straight into the Buzz folders but rather are copied via the post-build actions. Here's the solution for your perusal...
- Attachments
-
- WDE AudioBlock_src_IX.zip
- (2.8 MiB) Downloaded 163 times
Re: Notebook
Wow this is really great information. Thanks guys!
It's inspiring to see that 64bit support is there with just minor adjustments to the project file. Might make it more realistic for me to start testing Buzz64 at some point. And the potential memory limit is gone
@UNZ Are mixio and Buzz64 friends? Can't live without it.
It's inspiring to see that 64bit support is there with just minor adjustments to the project file. Might make it more realistic for me to start testing Buzz64 at some point. And the potential memory limit is gone
@UNZ Are mixio and Buzz64 friends? Can't live without it.
Re: Notebook
just tested the 32bit version quickly, unfortunately there seems to be an issue, will have to look into it. the gui is .net and i'm quite sure it has no other dependencies, so probably not a simple recompile, it's odd because it loads in a 32bit process (buzzengine32.exe), so nothing should be different.. but let's see, probably something with the gui communication.
Re: Notebook
so i'm trying to debug this... but buzz64 freezes as soon as i load more than 1 32bit machine.. for example try loading jeskola trilok twice..
if i use trilok + mixio -> crash
if i use qsine + mixio -> works
edit: ok 1 instance of trilok is enough to make it crash too, just have to hit play
very odd, i think this might unfortunately be something in buzz (in the 32bit bridge), but what i can do is compile a 64bit version of mixio.
if i use trilok + mixio -> crash
if i use qsine + mixio -> works
edit: ok 1 instance of trilok is enough to make it crash too, just have to hit play
very odd, i think this might unfortunately be something in buzz (in the 32bit bridge), but what i can do is compile a 64bit version of mixio.
Re: Notebook
another observation:
i was able to build mixio 32bit against the 32bit .net dll and it seems to work, confirming that ANY cpu seems to work if there are no further native dependencies in the .net gui.
however the 32bit bridge seems indeed very experimental and as soon as i try to do a bit more than play with mixio 32bit and other 64bit machines, all bets are off and it crashes a lot... i think this is a general problem with the 32bit bridge... mixio works fine as is (including gui) i think, but a lot of other stuff doesn't.
i was able to build mixio 32bit against the 32bit .net dll and it seems to work, confirming that ANY cpu seems to work if there are no further native dependencies in the .net gui.
however the 32bit bridge seems indeed very experimental and as soon as i try to do a bit more than play with mixio 32bit and other 64bit machines, all bets are off and it crashes a lot... i think this is a general problem with the 32bit bridge... mixio works fine as is (including gui) i think, but a lot of other stuff doesn't.
Re: Notebook
ok this is really odd, on another machine, the released 1.3 doesn't work and crashes...
on my dev machine, the same code works...maybe the recompilation with new CRT etc actually changed something...
EDIT: it's something in the project configuration of Debug vs Release build, because debug version works.
EDIT2: this will take a little longer to figure out as it's hard to debug, you get no breakpoints for 32 bit native dll since its loaded into another process... and it's only crashing in release mode anyway... will take a look again tomorrow
on my dev machine, the same code works...maybe the recompilation with new CRT etc actually changed something...
EDIT: it's something in the project configuration of Debug vs Release build, because debug version works.
EDIT2: this will take a little longer to figure out as it's hard to debug, you get no breakpoints for 32 bit native dll since its loaded into another process... and it's only crashing in release mode anyway... will take a look again tomorrow
Re: Notebook
OK i found the problem:
void MultiWork(float const * const *inputs, float **outputs, int numsamples)
it looks like buzzengine32.exe doesn't give you SSE aligned (output) buffers. this is very unfortunate and in my oppinion a bug, because every machine that assumes that the pointer where aligned in 32bit buzz.exe will now crash...
i can work around it by doing unaligned loads until hitting an aligned offset, but:
1) they are a bit slower
2) i should not have to do this, as compatibility with buzz.exe is not given at this point... maybe the pointers where aligned by accident in buzz.exe, but it doesn't matter, not doing it for buzzengine32.exe leads to compatibility issues so it should be fixed there...
by the way: if you ever have to debug your native 32bit machine in buzz64, you can attach to buzzengine32.exe manually to get breakpoints etc working.
void MultiWork(float const * const *inputs, float **outputs, int numsamples)
it looks like buzzengine32.exe doesn't give you SSE aligned (output) buffers. this is very unfortunate and in my oppinion a bug, because every machine that assumes that the pointer where aligned in 32bit buzz.exe will now crash...
i can work around it by doing unaligned loads until hitting an aligned offset, but:
1) they are a bit slower
2) i should not have to do this, as compatibility with buzz.exe is not given at this point... maybe the pointers where aligned by accident in buzz.exe, but it doesn't matter, not doing it for buzzengine32.exe leads to compatibility issues so it should be fixed there...
by the way: if you ever have to debug your native 32bit machine in buzz64, you can attach to buzzengine32.exe manually to get breakpoints etc working.
Re: Notebook
Feature request: any way to put links in the text? Not sure if it's possible since it's an RTF file, but links would be amazing.
I did a quick look online & found this:
RTF Hperlink Syntax Discussion
Not sure if it helps or hinders…
See You In The Shadows…
I did a quick look online & found this:
RTF Hperlink Syntax Discussion
Not sure if it helps or hinders…
See You In The Shadows…
Re: Notebook
Seems to be that there is a good reason to tag Buzz64 as 'experimental'. Great findings and hope these fixes end up in Buzz!UNZ wrote: ↑Sat May 09, 2020 11:32 am OK i found the problem:
void MultiWork(float const * const *inputs, float **outputs, int numsamples)
it looks like buzzengine32.exe doesn't give you SSE aligned (output) buffers. this is very unfortunate and in my oppinion a bug, because every machine that assumes that the pointer where aligned in 32bit buzz.exe will now crash...
i can work around it by doing unaligned loads until hitting an aligned offset, but:
1) they are a bit slower
2) i should not have to do this, as compatibility with buzz.exe is not given at this point... maybe the pointers where aligned by accident in buzz.exe, but it doesn't matter, not doing it for buzzengine32.exe leads to compatibility issues so it should be fixed there...
by the way: if you ever have to debug your native 32bit machine in buzz64, you can attach to buzzengine32.exe manually to get breakpoints etc working.
Last edited by wde on Sun May 10, 2020 11:15 am, edited 1 time in total.
Re: Notebook
Cool Thanks WDE!
See You In The Shadows…
See You In The Shadows…