SubTick Timing Bug (or PXP)

Post Reply
User avatar
UNZ
Posts: 747
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

SubTick Timing Bug (or PXP)

Post by UNZ »

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.
Attachments
subtick_bug.PNG
subtick_bug.PNG (41.57 KiB) Viewed 4570 times

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

Re: SubTick Timing Bug (or PXP)

Post by IXix »

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

User avatar
UNZ
Posts: 747
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: SubTick Timing Bug (or PXP)

Post by UNZ »

IXix wrote: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?

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

Re: SubTick Timing Bug (or PXP)

Post by IXix »

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.

User avatar
UNZ
Posts: 747
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: SubTick Timing Bug (or PXP)

Post by UNZ »

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

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

Re: SubTick Timing Bug (or PXP)

Post by IXix »

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.

User avatar
chahur
Posts: 203
Joined: Sun Nov 27, 2011 5:19 pm

Re: SubTick Timing Bug (or PXP)

Post by chahur »

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

User avatar
UNZ
Posts: 747
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: SubTick Timing Bug (or PXP)

Post by UNZ »

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

User avatar
chahur
Posts: 203
Joined: Sun Nov 27, 2011 5:19 pm

Re: SubTick Timing Bug (or PXP)

Post by chahur »

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.

User avatar
UNZ
Posts: 747
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: SubTick Timing Bug (or PXP)

Post by UNZ »

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?)

User avatar
UNZ
Posts: 747
Joined: Mon Nov 21, 2011 9:42 pm
Contact:

Re: SubTick Timing Bug (or PXP)

Post by UNZ »

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 ?

Post Reply