Hi, I would like to report what potentially could be a bug related to the Cycle function.
Here are the steps necessary to replicate the observed behavior:
Set up a cycle within a Part of a Song
Set the Song End Action as When Last Event End → What Start Next Song
Play the Song from the beginning and reach the section delimited by the L and R marks
The section delimited by the L and R marks is repeated cyclically, but the progress of the Part continues and, when the end of the Part is reached, the performance suddenly goes to the next Song without any user action disabling the cyclical execution
That is a bit unclear. Tried: new project, create 3 Parts, set Part 2 trigger to left locator (5.1), set Part 3 trigger to right locator (9.1) which i guess you mean by that? Created a MIDI track and event spanning cycle (5-9). Then when cycle is on (or not), as soon as the event end is reached, the next Song start to play.
Ah - if the event end exceeds the right locator it does behave weird. Will check and fix, is that what you mean? As always, thanks for reporting!
Hi, thank you for the answer and I try to represent you a more precise scenario, so as not to leave doubts:
Create a Song consisting of the Parts:
Part 1 → from 1.1
Part 2 → from 4.1
Part 3 → from 8.1
Create a MIDI track with an event between positions 1.1 and 10.1
Set up a cycle in Part 2 with the locators L → 5.1 and R → 7.1
Set the Song End Action as When → Last Event End and What → Start Next Song
Play the Song from the beginning and reach the section delimited by the L and R marks
The section delimited by the L and R marks is repeated cyclically, but the progress of the Part 2 and Part 3 (represented on the left side of the GUI) continues and, when the hypothetical end of Part 3 is reached (end of the MIDI event), the performance goes to the next Song without any user action disabling the cyclical execution.
I hope I have provided you with the way to perfectly replicate the observed behavior.
Thank you, as said before it is wrong when the event exceeds the right locator. Internally, it simply continues to run as if there was no cycle, so when cycle starts over it will eventually reach the end of the event. The bug has been found and fixed, thanks for reporting!
I revived this old post as I found myself in a situation similar to the scenario described initially by the post.
The bug as initially described has actually been fixed, but the behavior obtained by performing steps 1-3 with the current version of the software still seems inconsistent.
During the first repetition (second cycle) of the song section delimited by the L and R markers, the progress indicated on the left side of the GUI still shows that Part 3 has been reached, a part which however begins after the R marker and therefore in reality is not yet been reached during the execution of the cycled section.
The real problem is that reaching Part 3 implies loading the layers and stacks associated with this part even if the midi track execution is still within the section to be cycle.
You are correct. The algo takes the “unrolled” time (as if there was no cycle, and time just moves on) and decides that the next Part is to be selected. Will be fixed with the upcoming version, thanks for reporting!
unfortunately there still seems to be a particular case for which I believe that the software behavior is not the expected one, i.e. when the right locator of the cycle coincides with the beginning of Part 3.
In this case you end up loading the layers and stacks of Part 3, even though the cycle causes track execution to remain in Part 2.
I hope I have described this particular case clearly enough.
unfortunately still a case where the behavior of the software seems unexpected.
Consider a Song made up of the Parts:
Part 1 → from 1.1
Part 2 → from 4.1
Part 3 → from 8.1
and set up a cycle with the locators L → 5.1 and R → 9.1.
Although the case is a bit particular (the Cycle is cross between two Parts) the result of the execution of this scenario means that the Part 3will never be triggered during the execution of the Cycle, but only after deactivating the Cycle function .
So you set cycle and expect Part trigger to override cycle operation? That is arguable, and also leaves the question “why would you do that”
But if you say so, we’ll change it.
Hmm… I have the feeling that this time he failed to explain correctly what I would have expected.
I try to use different words: during the execution of the portion of the timeline, which is enclosed between the two locators R and L, I would expect that the Parts of the Song highlighted in the left section of the GUI and the consequent activation of events associated with Layer and Stacks are always consistent with the triggers defined for the Part and the point where the Songis playing.
This does not happen in the last scenario proposed by me, although, I realize, the scenario itself is rather unusual considering that the cycle appears cross Parts.
I hope I explained better the reason for my perplexity in considering the behavior of the 1.1.42 version of the software.
I understand that. But you might also argue that with an activated cycle, it is likewise inconsistent to break cycle operation by jumping somewhere else. Nevertheless we will do as you suggest, because the event of a Part trigger comes first (sequentially, before cycle end).
While implementing, tried to set the 2nd Part to bar 6. After the fix, Part jump at 8, then at 9 cycle jumps back to 5 and at bar 6, the previous Part is selected. Hope that is what everyone expects…seems logical, at least. So pls check with next version.
given that I continue to have some doubts between what could be considered a behavior intended by programmers and what turns out to be a real bug, but what happens in the Setilist Module, with a Cycle that contains or interrupts the execution of a Part, continues to be something unexpected for me.
I’ll try to explain better than what has been done so far, reporting the result obtained and the one I expected on the basis of two scenarios, scenarios represented in the attached small project.
Scenario 1 is represented by the SongTest 1 and I briefly report only the Song Position where the unexpected result is observed:
Cycle → from 2 to N
Song Position → 0002.1.1
Setlist Module:
Resulted → 100% of Part 3
Expected → 50% of Part 1
Scenario 2 is contained in the SongTest 2 and once again I report only the Song Position where the unexpected result is observed:
Cycle → from 2 to N (even cycles only)
Song Position → 0003.1.1
Setlist Module:
Resulted → 100% of Part 3
Expected → 0% of Part 2
Note that in this scenario interrupting the execution of the Song and re-executing it without moving to Test 1 and then returning to Test 2, seems to alter the behavior of the software in a somewhat unpredictable way.
in 1.1.51 software version, the behavior of the Setilist Module now seems to actually be as expected… when the activation of the trigger is performed as programmed.
Unfortunately, the trigger activation set in a location inside the cycle, the relative updating of the Setilist Module and the execution of the events associated with the parts often do not happen at all in a way that would appear to be random (or at least I have not been able to find a logic of cause and effect).
The solution seems to be closer now, but you should understand why the behavior of the software, upon reaching the beginning of a part, seems to be different cycle after cycle.
