Niems
Hey all!
I think I might have discovered a new bug in version 6:
When a song is looping (over any number of beats) and then you jump to a cue somewhere ahead in time (relative to the loop) in the song, the track gets stuck in a loop of miniscule length and sounds terrible! If the cue is previously time, its not pretty either: The song will jump back to the cue you select and play from there, but the loop function will stay on, with the loop end at the point where you had hit the cue button. Basically, the loop should be cancelled automatically either way when jumping to a cue point, otherwise you end up sounding like an idiot :/
My theory here is that the loop does not automatically disengage, causing loops of negative length when jumping ahead of time (which would explain the horrible noise it makes) and a normal (but undesirable) loop when jumping back in time. This occurs on my controller when using 'goto_cue #' and 'cue #' commands, where # is the cue number.
Can someone try confirm this? It happens with and without my controller.
I'm running XP on a Dell M1530 + U46DJ
Any help greatly appreciated!
I think I might have discovered a new bug in version 6:
When a song is looping (over any number of beats) and then you jump to a cue somewhere ahead in time (relative to the loop) in the song, the track gets stuck in a loop of miniscule length and sounds terrible! If the cue is previously time, its not pretty either: The song will jump back to the cue you select and play from there, but the loop function will stay on, with the loop end at the point where you had hit the cue button. Basically, the loop should be cancelled automatically either way when jumping to a cue point, otherwise you end up sounding like an idiot :/
My theory here is that the loop does not automatically disengage, causing loops of negative length when jumping ahead of time (which would explain the horrible noise it makes) and a normal (but undesirable) loop when jumping back in time. This occurs on my controller when using 'goto_cue #' and 'cue #' commands, where # is the cue number.
Can someone try confirm this? It happens with and without my controller.
I'm running XP on a Dell M1530 + U46DJ
Any help greatly appreciated!
Inviato Mon 08 Jun 09 @ 2:12 pm
cstoll
Well one nice thing about the new mapper engine is that when people find these type of bugs they can be over come ... change your mapper code for the buttons to ...
loop ? loop & goto_cue : goto_cue <- add the # number if you want to hard set specific cue points.
This will look to see if in a loop, if so - change the loop state (OFF) and go to to the cue point ; if not in a loop - just go to the cue point.
loop ? loop & goto_cue : goto_cue <- add the # number if you want to hard set specific cue points.
This will look to see if in a loop, if so - change the loop state (OFF) and go to to the cue point ; if not in a loop - just go to the cue point.
Inviato Mon 08 Jun 09 @ 2:23 pm
Niems
Thanks for the quick fix :)
I was trying compound statements with ';' and ',' which wouldn't have worked.
I was trying compound statements with ';' and ',' which wouldn't have worked.
Inviato Mon 08 Jun 09 @ 2:50 pm