buzz forums

this one seems connected to samplerate, so at 88.2khz, with 144bpm, 12 tpb and 96 rpb, all odd rows in pxp don't trigger ANY parameter changes/notes:
confirmed by 2 other people. different samplerates give different results, at 44.1 it seems that only every 4th row works etc.
i noticed this while working on my own machine, but all machines are affected so its either something in pxp or subtick timing in general.

Is that original PXP, Chahur's mod or both?

original pxp, didn't try pxp mod.
EDIT: if the original had this bug, i assume pxp mod does too if its not something that got fixed.
its worth mentioning that both buzz notes / parameter changes and midi notes / midi control changes are affected.
i had a quick look at the PXP source code but didn't spot it immediately, but the DoMidiPlayback() code seems a little more explicite in how it handles the range etc, so worth looking at.. maybe here:

auto range = GetRowSubtickRange((*i).second.rowInBeat, (*i).second.RPB, stpt);
int dtime = range.first + min((*i).second.delaytime * (range.second - range.first) / 96, stpt - 1);
int ctime = (*i).second.cuttime < 96 ? range.first + min((*i).second.cuttime * (range.second - range.first) / 96, stpt - 1) : 0x7fffffff;



we're also investigating another bug which seems to affect recording at TPB other than 4.
that one might be related to this line: outpwi.BuzzTickPosition = (pos - (int)pos) * 4.0f / pmi->playingPatterns.begin()->second->ppat->rowsPerBeat;
this seems related to quantization of recorded events, but if that 4.0f is TPB, why is it hardcoded to 4.0f?

Could you perhaps try to duplicate it using pattern editors than PXP? If you can then it's a Buzz bug, if not then probably PXP itself.

My audio won't do 88.2k. If you can give me settings to replicate at 48k or 96k I'll see if I can get it to happen here.

its easy to replicate at 44.1 too, even more rows don't work there (just use the same bpm, tpb, rpb). basically, the lower the samplerate, the less rows work. at 96khz you'll have to go a few BPM higher for the problem to start showing, 157 iirc.
i tried the new WPF pattern editor too, but i dont see a way to change RPB in it so it can't be tested there. The Classic Pattern editor obviously can't do it either..

Yeah, happening here too. I've got a ton of real life to do this week but if nobody's fixed it by the time I'm done I'll see if I can help. I suspect you're probably on the right track with the hard coded numbers though.

I can reproduce the problem also with patternXPmod.
I'll try to have a look ... but not in the next 10 minutes

found an even stranger variant of this bug: when a machine is muted, even more rows stop to work! (ProcessMutedMachines has to be TRUE).
10 rpb, 4 tpb, 117 bpm is enough to make this bug appear, row 0 works, row 1 doesn't.
my guess is that when the machine is muted, subtick timing is completely ignored...

I am pretty sure that the problem is not in PatternXP.
After some heavy debugging, I couldn't spot any part of the code involved in playing.
My guess is that it's done in the core of buzz.