I've disabled anonymous bug reports due to high levels of spam.
FS#12 - bugged octave after [...] loops
Attached to Project:
XPMCK
Opened by Mr Super User (mic) - Monday, 14 February 2011, 07:53 GMT-7
Last edited by Mr Super User (mic) - Saturday, 25 June 2011, 08:18 GMT-7
Opened by Mr Super User (mic) - Monday, 14 February 2011, 07:53 GMT-7
Last edited by Mr Super User (mic) - Saturday, 25 June 2011, 08:18 GMT-7
|
DetailsIn pmck, A o3 [c>c]2 plays o3c o4c o3c o4c
In xmck, it plays o3c o4c o4c o5c That shouldn't matter very much, but watch out... more octave bugs (that only occur after a loop that ends in a different octave than it started)! A o4 d < > d d d ; This example works fine--all four notes are played in the same octave ( the < and > cancel each other out). (vs.) A o4 [c > c]2 d < > d d d ; Now the last 3 notes are played in a lower octave!? Uh oh, bug. (vs.) A o4 [c > c]2 d < > > d d d ; Now they're all the same octave, but why does it work? Bug. (vs.) A o4 [c > c]2 o5 d < > d d d ; This works fine because of the o5. Looks like if you reset the octave after your loop, you don't run into this problem. |
This task depends upon
>> In xmck, it plays o3c o4c o4c o5c
This is not a bug - it's the intended behavior.
I'll look into the other cases.