CWBRN-43864 : Looped playback with negative Time offset in MIDI track problem

Makes some sense, but seems more like a feature request than a bug. And how should it handle the case that there's another note event on the same pitch in the next measure that's offset into the loop region? Should it ignore all notes that fall outside the end of the loop region without the offset or only prevent collisions/doubling?
 
Since I don't quantize my MIDI to 100%, I often run into the case that notes are missed because they start before the beat that I snapped the loop to. If it really matters, I just move the loop.

Fixing this operation would be particularly helpful when dealing with sounds that have long attack times.
eg. Often I will want to start these sounds ealier relative to the beats they were designed to coincide with.  If the notes also have a long duration this compunds the problem, as missed notes are even more of an issue.
 
Problems with the currently available workarounds:
1: bouncing to audio > not feasable while still in sound design mode!
2: manually create a long loop to work with > very inconvient when working with a track that already has structure in place.
3: spltting the attack portion of the sound from the rest > impossible in some circumstances.
 
While it is possible to work-around the problem, the time inconvience leads me to generally avoid even attempting these kinds of sound design, which is a shame as when I've had time to do it, some nice things can be achieved.
 

As we are only ever going to be playing the track forwards, there is only one case that needs addressing & that is
what happens at the end of the loop.  This case only occurs once already inside the loop & I thought the graphic would help explain how that particular situation would be handled.
 

brundlefly
a loop isn't a closed circle as your graphic shows; it's a loop in a longer 'string' of events

 
I understand & agree BUT surely looped playback when enabled, should simulate an actual loop (/closed circle).
In fact, this is exactly what the currently functionality does when there is no MIDI time offset active.  It is only when there is a MIDI time offset applied to a track, that this simulation breaks, hence why I am viewing it as a bug or an oversight.
 

brundlefly
Looping a section of a MIDI track with a negative offset plays exactly as it would if you destructively moved the MIDI events earlier.

 
No it doesnt!  This is the exactly the problem.
 
A selection that is looped should playback as if the selection were copied & repeated (destructively)
eg. select & loop 'ABCD' should playback 'ABCDABCDABCD'... etc.
 
With a small negative time offset we might expect to see ' BCD' on the 1st play of the looped selection (ie. 1st note missing). However when allowed to play through & loop, we would expect to see ' BCDABCDABCD'... etc.
Currently what we see is ' BCD BCD BCD BCD' etc. which is not what you would get if you copied & pasted the loop consecutively.

foldaway
A selection that is looped should playback as if the selection were copied & repeated (destructively)

No, that's not what looping is...

What you described was offsetting a note that is placed at the start of a loop to just before the start of a loop.  In that case the note should NOT be played on each repetition of the loop.  It is outside the loop boundaries.

Imagine you have a large cymbal hit, let's make it a big gong, that may take many seconds to decay.  It could be played (note on - note off) several bars before the section you want to loop, still being perfectly audible during the section you want to loop, but you'd NEVER hear it during actual loop playback because there'd be no midi info (either note on OR note off) to tell Sonar that it needs to be playing...
 
That is the nature of Midi.  Its been like that since 1982....
 
 
 
Edit: Speeling

The doc states that the MIDI data itself doesn't change, but the audible results do.  But if the audible portion is outside the loop range because the Note On that triggers that audio is "considered" outside the loop range, then I don't know how to expect anything different.  
 
It almost sounds like you're looking for an "Ignore Timing Offset In Loop Mode" type function.   Or...  perhaps even better, the "MIDI Chase" feature request where MIDI is audible if playback is initiated anywhere during a note's duration regardless of the Note On position. 
 

@stevec
 
Given that the events times are calculated in a non-destructive fashion.  I would expect an event + time offset within a loop range, to be ...looped around within that range.  Obviously, this expectation is down to my take of what a loop is! & what I use looped playback for.
 
The MIDI chase feature is more of a sledgehammer type solution to the problem, whearas I'm suggesting a scalpel that can only be used in 1 particular usage case.
 
If this required a new function / option name, something like 'Enable loop playback operation as simulation of consecutive duplicates', might work?  If you can think of a more clear / more descriptive description, I'm sure it would probably help move the conversation forward.
 
@Karyn
 
Your example simply does not apply to the situation I am describing.  I am highlighting a very particular situation where this particular shortcoming (/limitation) of the aging midi standard can be avoided, bringing with it the benefits I have previously stated.
 
So, in this particular & very specific situation, there is indeed 'a way around it'.  Which also obeys all the laws of 'how midi works'.
 
This is why I originally thought that this could have been a bug or oversight, given all the benefits it gives! Call it a missed opportunity or feature request if you'd prefer.  Whatever frame would allow the conversation to continue past it's current apparent impass.
 
I'm sure we all understand how the operation is currently working & there is no need to restate it repeatedly.
I am attempting to discuss potential changes in operation that will bring benefits when working with midi in Sonar.
 
At this point it might be more useful to discuss the merits or otherwise of what I'm suggesting.