eliadevico
I'm still convinced that this is a bug in the program. In fact, the manual says:
"If a clip’s position is locked, and you change tempo (YOU CHANGE TEMPO!)... its Absolute position (SMPTE) does not move, but its M:B:T position shifts."
Now, if you try, you will see instead that Absolute position move, but M:B:T position does not shifts".
I have just tried in X2 and it works as documented (M:B:T is shifted).
In the whole help page, you see "Position" and "Data". Note that the "Note:" in question mention Position only, not data. And so the documentation is accurate.
eliadevico
I have to make another clarification. I do not expect the program to ignore the changes in the tempo map (which is absurd). But when the clip is locked (Absolute time) and you change the tempo, the program must recalculate the 'musical' position of the Midi events (the bars, rhythm values, ie M: B: T) without shifting their absolute time position (H : M: S: F).
Logic did this very easily (but Logic no longer works on Windows). Sonar is a great program, but here is a defect, I believe. Anyway, I thank all those who answered me with great kindness.
Yes, Sonar does not have it. Sonar always keep MIDI information in M:B:T, it also keeps it not in original "MIDI events" but in own "MIDI events", f.e. instead of "Note ON + Note OFF" it keeps the information as "Note + Duration". Not the best (for other reasons), historical approach. But...
Now, that is not a "defect" or "bug". That is not implemented feature. Different programs have different set of implemented features, we can not call a program "buggy" just because it has not implemented something.
I agree that is a good feature request, but I guess CW will implement it only after replacing 15+ years old MIDI engine (supporting MIDI VST, dropping strange internal format and organizing flexible MIDI routing). That is a huge work, the engine is bound to many Sonar parts which have to be rewritten then.
Normal problem is reversed from your: something is recorded without a click, then correct tempo is detected and somehow should be applied to the project. But MIDI events move with tempo changes and since there is no Absolute time locking, the result is not what people want.
For that (reversed) case, I have written a Lua script (can be CAL) to "correct" MIDI events timing. Its use is not simple, it works only once (when initial tempo is constant), there should be exactly one clip per track, started at the beginning and (manually) extended above the end of target time. But when people hit the problem, the project is normally already in that form.
While I could write "reversed" script, so taking current fluctuating tempo and pre-calculate M:B:T for constant tempo, it will be too hard to use in your case (bouncing/extending clips, many clicks per track, splitting the result, and in case something was specified wrong, redo the whole procedure). So I do not think that is feasible.
I can be wrong, but I think most people are "humanizing" by changing MIDI events (manually, with MFX or loop recording corresponding MIDI VSTs), not by project tempo. I can imaging that if ALL other material except particular clip can be fixed in absolute time (effectively ignoring tempo changes), it is possible to "draw" something for the purpose. But since that is not directly supported in Sonar (all other MIDI tracks should be temporarily Frozen), the only logical conclusion:
At the moment it is too hard to work this way in Sonar.