XPMCK

I've disabled anonymous bug reports due to high levels of spam.
Tasklist

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
Task Type Bug Report
Category Compiler
Status New
Assigned To Mr Super User (mic)
Operating System All
Severity Low
Priority Normal
Reported Version R28
Due in Version Undecided
Due Date Undecided
Percent Complete 90%
Votes 0
Private No

Details

In 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

Comment by Mr Super User (mic) - Monday, 14 February 2011, 07:53 GMT-7
>> A o3 [c>c]2 plays o3c o4c o3c o4c
>> 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.

Loading...