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.
SubTick Timing Bug (or PXP)
SubTick Timing Bug (or PXP)
- Attachments
-
- subtick_bug.PNG (41.57 KiB) Viewed 8972 times
Re: SubTick Timing Bug (or PXP)
Is that original PXP, Chahur's mod or both?
Re: SubTick Timing Bug (or PXP)
original pxp, didn't try pxp mod.IXix wrote:Is that original PXP, Chahur's mod or both?
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?
Re: SubTick Timing Bug (or PXP)
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.
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.
Re: SubTick Timing Bug (or PXP)
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.IXix wrote: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.
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..
Re: SubTick Timing Bug (or PXP)
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.
Re: SubTick Timing Bug (or PXP)
I can reproduce the problem also with patternXPmod.
I'll try to have a look ... but not in the next 10 minutes
I'll try to have a look ... but not in the next 10 minutes
Re: SubTick Timing Bug (or PXP)
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...
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...
Re: SubTick Timing Bug (or PXP)
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.
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.
Re: SubTick Timing Bug (or PXP)
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_per_subtick: 184 (CORRECT)
BPM: 100, TPB: 25, RPB: 64 ---> samples_per_subtick: 176 (CORRECT)
BPM: 100, TPB: 26, RPB: 64 ---> samples_per_subtick: 254 (BUG? should go down, no?)
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_per_subtick: 184 (CORRECT)
BPM: 100, TPB: 25, RPB: 64 ---> samples_per_subtick: 176 (CORRECT)
BPM: 100, TPB: 26, RPB: 64 ---> samples_per_subtick: 254 (BUG? should go down, no?)
Re: SubTick Timing Bug (or PXP)
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 <--- shouldn't this stay at 138 ?
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 <--- shouldn't this stay at 138 ?