i cannot confirm the behavior, but it raised a concern, nevertheless.
are you merging two (or more) just created clips that haven't seen their backs yet on disk as a regular .mid file? That might happen that you're nigh to overwrite the brand new-to-be clip(s) filename(s); if you simply hit yes (on replace warning that is) you'll end with undefined behavior oh yeah, in particular if you think of Undo-ing what you just made (a clip merge that replaced the previous clip filename);
besides that particular situation (undo a merge that replaced an existing .mid filename, for which you said OK to replace anyway:)), I can't really see where the issue might be. Maybe my eyes and brain are old and dismissing the obvious, who know's?
Cheers.
ps. just fixed the situation: the proposed merged clip filename is now bumped to the next numerical suffix, so that you are not misguided to replace a previous existing one, unless you really want to get into trouble ;) on git head master now (qtractor >= 0.8.6.22git.fdd5de).
hi Frank,
i cannot confirm the behavior, but it raised a concern, nevertheless.
are you merging two (or more) just created clips that haven't seen their backs yet on disk as a regular .mid file? That might happen that you're nigh to overwrite the brand new-to-be clip(s) filename(s); if you simply hit yes (on replace warning that is) you'll end with undefined behavior oh yeah, in particular if you think of Undo-ing what you just made (a clip merge that replaced the previous clip filename);
besides that particular situation (undo a merge that replaced an existing .mid filename, for which you said OK to replace anyway:)), I can't really see where the issue might be. Maybe my eyes and brain are old and dismissing the obvious, who know's?
Cheers.
ps. just fixed the situation: the proposed merged clip filename is now bumped to the next numerical suffix, so that you are not misguided to replace a previous existing one, unless you really want to get into trouble ;) on git head master now (qtractor >= 0.8.6.22git.fdd5de).