buzz forums

forums of the buzz
It is currently Sun Aug 20, 2017 9:04 pm

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Fri Jan 20, 2017 2:11 am 
User avatar

Joined: Mon Nov 21, 2011 9:42 pm
Posts: 680
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 606 times ]
Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 9:20 am 
User avatar

Joined: Wed Nov 23, 2011 3:24 pm
Posts: 504
Is that original PXP, Chahur's mod or both?


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 10:18 am 
User avatar

Joined: Mon Nov 21, 2011 9:42 pm
Posts: 680
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?


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 8:23 pm 
User avatar

Joined: Wed Nov 23, 2011 3:24 pm
Posts: 504
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.


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 8:31 pm 
User avatar

Joined: Mon Nov 21, 2011 9:42 pm
Posts: 680
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..


Top
 Profile  
 
PostPosted: Sat Jan 21, 2017 10:18 am 
User avatar

Joined: Wed Nov 23, 2011 3:24 pm
Posts: 504
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.


Top
 Profile  
 
PostPosted: Mon Jan 23, 2017 8:17 pm 
User avatar

Joined: Sun Nov 27, 2011 5:19 pm
Posts: 191
I can reproduce the problem also with patternXPmod.
I'll try to have a look ... but not in the next 10 minutes :-)


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 10:23 pm 
User avatar

Joined: Mon Nov 21, 2011 9:42 pm
Posts: 680
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...


Top
 Profile  
 
PostPosted: Sun Mar 12, 2017 7:37 pm 
User avatar

Joined: Sun Nov 27, 2011 5:19 pm
Posts: 191
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group