behavior of Seq. with markers

[Eggu]

As I understand the markers in a seq. have a new behavior since Mulab 3.x:

- Loop start/end markers are belonging to the sequence,
and are common for all (shared) copies of a seq.-part.

- Start markers (triangle marker) are unique for each part, each (shared) copy has its own,
this marker can be set in the note editor, or implicitly by changing part start, or split function.

agreed up to now ?

But what about the following example, where the start marker is right of the loop end marker ?
Look at the resulting part, I do not understand the underlying rule.





And furthermore:
When dragging the left side of the part a little bit to the left,
the start marker jumps to the left of the loop-end-marker and looping becomes effective:

[Eggu]

Hmm, some more strange behavior:



When starting playback (e.g. Piano):
first note does not trigger (red marker),
ok, is part of longer note, start of note and trigger left from part start.

But second note (blue) also does not trigger ...

Third note (green) let trigger both blue and green together.

Then when looping, yellow note (which is same as blue note)
does trigger properly.

[MuTools]

As I understand the markers in a seq. have a new behavior since Mulab 3.x:

- Loop start/end markers are belonging to the sequence,
and are common for all (shared) copies of a seq.-part.

- Start markers (triangle marker) are unique for each part, each (shared) copy has its own,
this marker can be set in the note editor, or implicitly by changing part start, or split function.

agreed up to now ?

Yep.

But what about the following example, where the start marker is right of the loop end marker?

This situation is not supported, i.e. the sequence part won't be played.

I guess there is room for improvement here. Added a note on the whishlist.

[MuTools]

Hmm, some more strange behavior:



When starting playback (e.g. Piano):
first note does not trigger (red marker),
ok, is part of longer note, start of note and trigger left from part start.

But second note (blue) also does not trigger ...

Third note (green) let trigger both blue and green together.

Then when looping, yellow note (which is same as blue note)
does trigger properly.

Could you please email me this musession. Thanks.

[Eggu]

Could you please email me this musession. Thanks.

Ok, done.

[MuTools]

Thanks for the musession.

It's a bug. Will be fixed in the next version.

[janamdo]

Thanks for the musession.

It's a bug. Will be fixed in the next version.

Well, looping in the Sequenze screen with Set Part Start(SPS)marker gives a problem when you position the SPS marker right from the loop
When it should function properly than the songpointer starts on the SPS marker and is moving to the end of the measures ..and than start on the begin of the loop and it than repeating the loop.

Is it not possible to add a End Set Part (ESP) marker in MUlab ?
Than you can select one measure as example or smaller ( also more than one measure possible)
You can pick out notes for using this with the loopnotes
Make this sense?

[MuTools]

The end of a sequence part can be defined by... the end of that part.

I mean: if a sequence part goes from 5.1.0000 to 9.1.0000 then it will stop playing at 9.1.0000.

No need for an extra locator, imho.

[Eggu]

Please also consider following (surprising) behavior:

- Create (or import) a (short) midi seq., without any markers (remove start, loop start, loop end markers -> important).
- Make a shared copy (place it in the track right under the original to watch what happens, do not place the parts totally on the left, if you want to proceed with following steps).
- drag left end of part (start position) to the left.
--> this empty part beginning is (automatically) created by shifting all notes (in the seq) to the right, because no markers are available.
--> but this causes also to add empty space to the beginning of the shared copy ! (logic, because it's the same identical seq., but surprising and usually not wanted).
- drag the left side part of the original part back to the position as it was before any drag-operation
--> left side part of original and shared copy are now aligned again, but:
--> original part looks like at the beginning, but inside of the seq. the add. space on the left is still there, and a start marker was automatically created to keep start position of notes, on shared copy no markers are added.
--> so at the end the original part looks as at the beginning,
but the shared copy has its notes still shifted to the right.

==> a part operation (dragging left side to the left)
causes an implicit seq. operation (shifting notes to the right).
Really as intended ?
(Sorry for trying unusual cases, but in my job such cases leads to the biggest add. costs )

[MuTools]

Please also consider following (surprising) behavior:

- Create (or import) a (short) midi seq., without any markers (remove start, loop start, loop end markers -> important).
- Make a shared copy (place it in the track right under the original to watch what happens, do not place the parts totally on the left, if you want to proceed with following steps).
- drag left end of part (start position) to the left.
--> this empty part beginning is (automatically) created by shifting all notes (in the seq) to the right, because no markers are available.
--> but this causes also to add empty space to the beginning of the shared copy ! (logic, because it's the same identical seq., but surprising and usually not wanted).

I see.

Indeed technically it's correct/intended, but from user point of view it's unwanted.

- drag the left side part of the original part back to the position as it was before any drag-operation
--> left side part of original and shared copy are now aligned again, but:
--> original part looks like at the beginning, but inside of the seq. the add. space on the left is still there, and a start marker was automatically created to keep start position of notes, on shared copy no markers are added.
--> so at the end the original part looks as at the beginning,
but the shared copy has its notes still shifted to the right.

==> a part operation (dragging left side to the left)
causes an implicit seq. operation (shifting notes to the right).
Really as intended ?
(Sorry for trying unusual cases, but in my job such cases leads to the biggest add. costs )

You're absolutely right highlighting this.

Yes, it's all intended. And in fact it's the functional result of several chats here on the forum.

Question: how would you like it to be? (while prioritizing simplicity please)

[Eggu]

Question: how would you like it to be? (while prioritizing simplicity please)

when dragging left part side (part without any markers) to the left (part operation), then shifting notes to the right seems the easiest way to gain extra space at the beginning (as of today, but this is a implicit seq. operation, I suppose).

What about the following solution:

You always have at least a (might be virtual) start marker at the left side
(if not set otherwise).
.. and you always have enough empty space (might be also thought as virtual) left from the start marker.

--> then when dragging part start to the left, the start marker also goes to the left (revealing the empty space).

But at all shared copies the start markers stay at old position
--> no surprisingly moving notes at other parts.

Will this lead to any conflicts with bar numbering ?

[MuTools]

when dragging left part side (part without any markers) to the left (part operation), then shifting notes to the right seems the easiest way to gain extra space at the beginning (as of today, but this is a implicit seq. operation, I suppose).

Yes, implicit sequence operation indeed.

What about the following solution:

You always have at least a (might be virtual) start marker at the left side
(if not set otherwise).
.. and you always have enough empty space (might be also thought as virtual) left from the start marker.

--> then when dragging part start to the left, the start marker also goes to the left (revealing the empty space).

But at all shared copies the start markers stay at old position
--> no surprisingly moving notes at other parts.

Will this lead to any conflicts with bar numbering ?

Just went for some biking and the fresh air whispered something similar into my ear: Allow the start marker to go negative in time, i.e. negative sequence time. This would keep things simple and consequent, and it won't cause the unexpected shift in a shared sequence part. I'll research this.

[Eggu]

I'll research this.

Ok.

Please let me finally describe a typical situation, where the "note-shift-issue" appears:

- Import a ready midi file (for educational or inspirational) reasons.
--> no markers !

- make a shared copy of a part, e.g. for add. strophe at end of song.

- adjust left side of original part, to do alignment, or simply to check if there migt be some more notes to the left, or ... whatever.

--> Upps ! notes in copy are shifted !

==> So I think it is worth to fix the current implementation.

[MuTools]

==> So I think it is worth to fix the current implementation.

Yes, certainly, it's a confusing situation. Good that you discovered this.

[MuTools]

Allowing a negative start locator to gain extra space at the beginning of a sequence part is theoretically a good solution, but i think it's not very practical either as then new notes can be drawn in the negative time area, and i think that's too abstract/confusing for many users, also because whe you have to calc positions, the math becomes a bit more unusual, e.g. "-5 + 3 = euh -2" which is less usual than e.g. "2 + 3 = 5".

So i went for another solution: In the above case, the start locator of all shared parts will be updated so the situation stays the same.