Notebook

User avatar
IXix
Posts: 1113
Joined: Wed Nov 23, 2011 3:24 pm

Re: Notebook

Post by IXix »

@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. :lol:
wde
Posts: 332
Joined: Sun Jan 08, 2012 9:28 am

Re: Notebook

Post by wde »

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. :lol:
Very nice! I don't have Buzz 64 installed so thanks for trying this out.

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 ;)
User avatar
IXix
Posts: 1113
Joined: Wed Nov 23, 2011 3:24 pm

Re: Notebook

Post by IXix »

wde wrote: Thu May 07, 2020 4:26 pmNext you can try AudioBlock ;)
Count on it. :D
User avatar
UNZ
Posts: 808
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: Notebook

Post by UNZ »

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...
User avatar
IXix
Posts: 1113
Joined: Wed Nov 23, 2011 3:24 pm

Re: Notebook

Post by IXix »

UNZ wrote: Thu May 07, 2020 7:56 pm 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...
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. :dance:

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 148 times
wde
Posts: 332
Joined: Sun Jan 08, 2012 9:28 am

Re: Notebook

Post by wde »

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 :D

@UNZ Are mixio and Buzz64 friends? Can't live without it.
User avatar
UNZ
Posts: 808
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: Notebook

Post by UNZ »

wde wrote: Fri May 08, 2020 5:34 pm @UNZ Are mixio and Buzz64 friends? Can't live without it.
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.
User avatar
UNZ
Posts: 808
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: Notebook

Post by UNZ »

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.
User avatar
UNZ
Posts: 808
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: Notebook

Post by UNZ »

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.
User avatar
UNZ
Posts: 808
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: Notebook

Post by UNZ »

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
User avatar
UNZ
Posts: 808
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: Notebook

Post by UNZ »

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.
User avatar
Candle
Posts: 296
Joined: Sun Apr 23, 2017 1:03 am
Location: Canada
Contact:

Re: Notebook

Post by Candle »

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…
wde
Posts: 332
Joined: Sun Jan 08, 2012 9:28 am

Re: Notebook

Post by wde »

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.
Seems to be that there is a good reason to tag Buzz64 as 'experimental'. Great findings and hope these fixes end up in Buzz!
Last edited by wde on Sun May 10, 2020 11:15 am, edited 1 time in total.
wde
Posts: 332
Joined: Sun Jan 08, 2012 9:28 am

Re: Notebook

Post by wde »

Candle wrote: Sat May 09, 2020 10:45 pm 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.
Links seem to work. You just need to type 'http://...', or 'https://...' to make the link active.
User avatar
Candle
Posts: 296
Joined: Sun Apr 23, 2017 1:03 am
Location: Canada
Contact:

Re: Notebook

Post by Candle »

Cool 8-) Thanks WDE!

See You In The Shadows…
Post Reply