buzz forums

do you get an exception when you close it? i still get those kernelbase ones on close. No, nothing like that. One thing that has been happening since I got a new machine and transferred to VS2019 is I've been getting random exceptions (something to do with ucrtbase.dll) when debugging Magic but I a...

but if you calculate your LFO to correctly update in all cases (not just when pos_in_subtick ==0), taking into account the different (current) lengths of a subtick, it should be the same but at reduced latency and possibly increased resolution imho, you do indeed have to count samples then tough i g...

this sends control changes only when pos_in_subtick is 0, my question is: why? In all honesty, I don't really know. IIRC it's what Oskari said you should do. i just made my own lfo control machine test which sends it immediately without waiting (like the parameter window) and it seems to work contr...

i have a question about these lines in the code: int pos = m_pSubtickInfo ? m_pSubtickInfo->PosInSubTick : pMasterInfo->PosInTick; if (pos == 0) { CPeerCtrl::BeginImmediateBatch(); DoLFO(Reset); CPeerCtrl::EndImmediateBatch(); } this sends control changes only when pos_in_subtick is 0, my question i...

i just tried it again and it doesn't happen always... right now it's sitting there silent, but this afternoon it constantly spew exceptions... very odd as nothing is different and i'm not even loading machines.

do you get an exception when you close it? i still get those kernelbase ones on close.

so this is indeed a bug.

from the changelog:
--- June 2008 builds
- all audio buffers 64-byte aligned

in buzzengine32.exe, the output buffers are not aligned.

If i run buzz in the debugger and just leave it sit there without doing anything, it throws exceptions and seems to start and stop a thread about every 1 second. Not using any fancy theme, just the regular default with pretty much all eye candy turned off: Exception thrown at 0x75554402 in buzz.exe:...

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 3...

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 w...

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 ...

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 ...

@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 3...

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...

another test: at 100 bpm and 4 tpb: samples_per_tick: 13230, samples_per_subtick: 138 at 100 bpm and 8 tpb: samples_per_tick: 6615, samples_per_subtick: 138 at 100 bpm and 16 tpb: samples_per_tick: 3308, samples_per_subtick: 138 at 100 bpm and 32 tpb: samples_per_tick: 1654, samples_per_subtick: 207...

oskari, i think i found the bug in buzz: here's a few numbers to see what happens (all at 88200 khz, should be half at 44100): BPM: 100, TPB: 22, RPB: 64 ---> samples_per_subtick: 200 (CORRECT) BPM: 100, TPB: 23, RPB: 64 ---> samples_per_subtick: 192 (CORRECT) BPM: 100, TPB: 24, RPB: 64 ---> samples...

OK, this looks like it's something on my end, i copied the exact same code into a new project (to make a minimal repro), but then just compiled and it doesn't leak! So it must be something with my project / compiler settings, sorry to bother you

it's easier to test in a .exe, i will try to make a minimal repro .exe to send you. this is just a wild guess, but 4 bytes sounds like a pointer (testing this in a 32bit exe), and since it only occurs when loading a vst dll, maybe it is a missing freelibrary matching the loadlibrary ? or missing a c...

i use this to find leaks, it served me very well: https://docs.microsoft.com/en-us/visualstudio/debugger/finding-memory-leaks-using-the-crt-library?view=vs-2019 basically if you load 1 plugin: 4 bytes leak, if you load 2 plugins: 8 bytes leak and so on, so yeah it's probably something allocated afte...

thanks for your reply! i got it to work, but now i have another small problem: mi->Init(nullptr); mi_ex->SetInstrument("mda Piano"); delete mi; this sequence leads to a 4 byte memory leak. mi->Init(nullptr); //mi_ex->SetInstrument("mda Piano"); delete mi; this does not leak. (btw...

nevermind, the problem solved itself by updating to the latest PVST! :) EDIT: the real problem seems to have been that i can't just load machines.dll and Polac VSTi 1.1.dll from my normal buzz folder, but have to place the whole contents of the zip file into my DEBUG / RELEASE folder... quite obviou...