buzz forums

another short video : with mixIO parameters Settings is same for both builds yeah this looks like a bug in buzz64, or at least it doesn't behave like buzz32. for some reason parameterchanges to itself are not sent / received by mixio... might have something to do with threading across the bit bridg...

ok, that's odd, is Settings/ProcessMutedMachines the same on both builds? by the way, ignore my previous comment, it's wrong and only applies to the (unreleased yet) mixio 2.0. i want to know if it's a problem with the GUI or Buzz: if you right click on mixio and show parameters, and then do a SOLO ...

SOLO and MUTE states are independent of each other, SOLO does not set MUTE state, but it still "mutes" the sound of the other channels. it's a bit different, but more flexible, than a traditional mixer. In other words: SOLO is not implemented through MUTE, but separate. At least that's how...

Maybe try these options in PVST (individually):

-Save VST Params To Song
-Sync Process/SetProgram/EditOpen
-Multithreading (OFF)
-Run In Separate Process

never mind, these values are not supposed to be sent to the machine, pxp handles the delay and the cut by itself and just sends the note later / note off earlier. doh...

kind of a mixed bag for me, i had one completely random crash in a few weeks when just letting buzz sit there... but overall it does seem more stable now... also these messages are back Exception thrown at 0x767EDF72 in buzz.exe: Microsoft C++ exception: EEMessageException at memory location 0x0019F...

In my native machine i'm capturing midi input via the following: virtual void MidiControlChange(int const ctrl, int const channel, int const value) this works for the following columns in PXP: -MIDI Pitch Wheel -MIDI CC It does not work (function is not called) for: -MIDI Note Delay -MIDI Note Cut v...

try disabling multithreading
or try enabling "run in separate process"

I've noticed that PVST doesn't detect a .vst3 (when scanning the shell) unless the file name of the dll is exactly the same as the stringPluginName specified in DEF_CLASS2.
other hosts don't care about this and i think it doesn't make much sense to enforce this?

so after a bit of thinking about this and testing some hosts here are my thoughts: some hosts don't seem to care for NumPrograms = 0 and work just fine, others have issues with it. i could not find a definitive answer in the VST standard that says anything about 0 being legal or not. i think even if...

i have a very simple vst (2.4) with one parameter. it mostly works, but: if i change the parameter value from the buzz parameter gui or from pxp, PVST crashes with a null reference exception. changing the parameter value in pvst's built-in parameter gui works. unfortunately i don't get a proper stac...

yes, debugging was such a pain in the ass with those! (btw, you can filter some in VS, it helps a bit)
what got me suspicious was that only 1 out of 5 computers i have here had this problem (my main dev rig..), so i thought it must be solvable..

let me know if this fixes your issues too.

I think i figured it out: running NGEN again seems to fix the problem, so just re-install buzz over your old installation and make sure that checkbox is ticked. i think this happened because i migrated this windows installation to a new machine with a different CPU, so the AOT apparently had to run ...

My Buzz is not stable since quite some time, i can basically just open it and let it sit there (with a silent audio driver, empty machine view) and after a few minutes it crashes. If i attach a debugger and wait for the crash, this is what i get: Unhandled exception at 0x76ACEDDB (ucrtbase.dll) in b...

thanks, yeah i had a hunch it was ticks and that you'd have to resort to subtick granularity to detect transport jump. should be good enough i guess.

Haven't researched this yet very fondly, but it looks like there is no easy way to just get an accurate song position in Buzz? You'd think it's in MasterInfo, but nope, all relative to the current tick, and subtick info is relative to current tick also.. i guess these two would help, but they return...

the drawing is pretty accurate i think, except that i think win11 only will assign p cores to an app that doesn't specifically ask for something else and use the e-cores for OS level tasks. i could be wrong, but this would avoid most issues with software that's not specifically geared to exploit bot...

buzz works fine on win11, same as on win10

GPU brand shouldn't matter for a DAW in general. BUT: nowadays there are efforts to move plugins to GPU processing (for example https://www.gpu.audio/) and from what i can see is that everyone always starts developing in NV and only later ports to AMD and Intel etc. Also CUDA is NV exclusive, so som...

hehe, i'm the complete opposite, my cpu (11900k) + gpu (3080ti) alone can draw up to ~700w when fully loaded, and my pc stays on 24/7. good thing you're compensating for my sins.