Lmms: Some patterns in "Song-Editor" and "Beat+Bassline editor" are displayed larger than they are

[vlad0337187]

Hello.

Some patterns in RC4.96 are displayed larger than they are in Song-Editor.
In Piano roll they are displayed normally, also they are played normally.

Here is example:

Example with beat: https://github.com/LMMS/lmms/issues/3989#issuecomment-345537384

Why is it important ?
Because now it's very annoying resizing all placed beats / patterns in Song-Editor. If not to resize them - they overlay one extra button and to paste new beat / pattern there you need to paste them one button right, than move it.

Hope, it's not big problem and could be corrected to 1.2.0 release.

Best regards,
Vladislav

[vlad0337187]

Example with beat:

Here we see that some patterns are displayed in Beat+Bassline Editor and Song-Editor with extra fields.

Now we will open them in Piano-Roll:

• https://user-images.githubusercontent.com/12682937/32993872-4a179fea-cd67-11e7-9aa9-4a2da66978c9.png
• https://user-images.githubusercontent.com/12682937/32993873-4a340d24-cd67-11e7-87b6-c038cc482407.png
• https://user-images.githubusercontent.com/12682937/32993874-4a4f67ea-cd67-11e7-989c-afaa5ee31472.png

So we see, that in Piano-Roll all is well.

[zonkmachine]

I don't see this on my machine. If you open one of the patterns in the Piano Roll and zoom to 800% you may find that the last note is extending into the following pattern. If not, please upload a project that shows this issue.

[tresf]

Sounds similar to https://github.com/LMMS/lmms/issues/2660

[Mark-Agent003]

I've had this happen before also, although I could never figure out why.

[vlad0337187]

Yes, @zonkmachine is right. But I don't understand why was it happened.
I never changed quanting size of notes - it's 1 / 16, so it must be changed only in such diapason, never making that extra little size.
https://user-images.githubusercontent.com/12682937/32996167-eef8609c-cd87-11e7-908c-98570a115114.png

To change this I must make quanting size more large (to 1 / 192) and change note size.

Sorry, this is my mistake, I didn't thought about this because I didn't changed notes quanting size.

I think this issue could be closed.

[zonkmachine]

@vlad1777d

I didn't thought about this because I didn't changed notes quanting size.

Well. You could have slipped and made a <Shift> + <Alt> stretch which overrides the selected note length.
Then again, it could always be a bug in there... :)

Did you import this from 1.1.3 ?

[vlad0337187]

@zonkmachine , no, I started making beat from scratch.
Thanks for a tip. Now beats and patterns are needed width =)

[zonkmachine]

I think I know what happened here.

To replicate:

1. Add a note, 1/16 is a good length.
2. Hover over the right edge, press the left mouse button and drag it to the far left.
3. Let go of the mouse button.
4. Regret that move and drag it to the right and now you're slightly too long but it won't show at 100% zoom.
5. Since you have the setting to remember the last note length you're now set for a surprise.

@tresf I think maybe the note length should have the same minimum as it's quantization.
_Edit: For dragging to a smaller value we've already got the <Shift> + <Alt> override._

[vlad0337187]

@zonkmachine , yes, right, I did so, I minimized my a mistake some notes
(I wanted to make them lesser, but by a mistake I often make them minimum size).

[tresf]

I think maybe the note length should have the same minimum as it's quantization.

I'm not understanding this. Do you mean quantization snapping? Last note is exactly that... the last note, so I'm not sure what you're suggesting.

[vlad0337187]

@tresf , I think, that he means to make impossible resize note to size lesser, than amount of quantization.
For example, is quantization size is 1/16, than note must not be get lesser than 1/16 when you resize it.

[tresf]

@gi0e5b06 please stop deleting your messages on this tracker. They make it very difficult to reply in-context when you do that.

@tresf , I think, that he means to make impossible resize note to size lesser, than amount of quantization.
For example, is quantization size is 1/16, than note must not be get lesser than 1/16 when you resize it.

Yeah, I guess this makes sense, I just use this bug a lot when I'm producing, so I'm used to it. Perhaps I'm too biased to vote on this feature.

[musikBear]

OhUh careful -even though it looks as a good idea to not allow a 1/16 note to be sub-sized, enforcing that heuristic for all notes, would be really annoying for longer notes
Imo its up to user to make sure, no notes are overshooting, not lmms'

[gi0e5b06]

My post was not relevant to this issue. The problem here is different and appears in two steps:
1) there is a minimum length (and this is not 0)
2) the quantization applies to the length of the note and not to the end point.

Quantizazing the start, the length and the end of the note are three different things and I don't know what the expected behavior is. But setting a minimum length to one step would fix the problem. OTOH "bb hit" notes (idk their names) should be considered... (and displayed differently but this is another issue)

[tresf]

@gi0e5b06 thanks for the explanation. In the future if you feel the need to delete a message it helps others to simply edit it and explain why. The reason for this is that email notifications contain your messages and replies to those emails may be in response to your messages. Alternately, you may use strikeout. ~~i didn't mean to type this~~ = i didn't mean to type this.

[vlad0337187]

@musikBear , I didn't get it:

would be really annoying for longer notes

And about:

Imo its up to user to make sure, no notes are overshooting, not lmms

As for me, I would vote for this feature. Because I don't see any use-case for resizing notes lesser than quantizing size. And if such will appear - it's easy to change quantizing size.

And changing size of note to be not multiple to quantizing size (in our case - lesser than it and not multiple to it) contravenes to the essence of quantizing - making all things to be multiple to some other.

Also it's often practice when mouse or finger on touch-pad accidentally moves a bit left and makes bad thing, which, by logic, might not happen.

So I would vote for this suggestion.

@tresf,

I just use this bug a lot when I'm producing

which way may it help ?

[tresf]

@vlad1777d what I mean is, I take advantage of the bug that allows note size smaller than quantization when it should not. It's a convenience, but holding the modifier key to do so is OK too.

[Spekular]

I don't think the issue is with scaling a note to be smaller than the
current quantization. Scaling a note from 3/32 to 1/32 at 1/16 quantization
seems perfectly valid to me. The issue is when shortening the note by the
current quantization would result in a zero length note (instead we get a
really short note because a zero length note would be bad). The only
solution I can see to this problem is to disallow scaling down when the
Quant Size >= Note Length.

[musikBear]

disallow scaling down when the Quant Size >= Note Length.

Why should user not be able to modifier-drag f.i. a 1/4 note to <1/16 in a situation where Q is 1/16?
Or do you exclude modifier-drag from that rule?

[tresf]

Or do you exclude modifier-drag from that rule?

Correct, we're not talking about the modifier key.

[zonkmachine]

For example, is quantization size is 1/16, than note must not be get lesser than 1/16 when you resize it.

Precisely what I meant.

It's a convenience, but holding the modifier key to do so is OK too.

A quick fix. Proposed new way is limiting note length to quantization value. Use <Shift> key as usual to set smaller value and that value will stick as before when lengthening the note. If you let go of the note, grab it at the end and drag it to the quantized minimum once more this extra bit will once more be gone. I like it anyway. :)
The main rationale is that a random length of 'one' stuck to the end of the note isn't showing without zooming in. As the <Shift> key already is used to set the note length to an unquantized value we just go along with that.

https://github.com/LMMS/lmms/pull/3998

[Spekular]

@zonkmachine Am I misunderstanding or are you saying all notes will snap to
multiples of the current quantization? For example a 1/32nd note scaled up
at 1/16th Q snaps to 1/16th length rather than 3/32nds?

I know this solves this particular problem but think it's worse otherwise.

[zonkmachine]

Yeah, turns out it kind of sucks a bit...

[PhysSong]

In my opinion, the length change should be a multiple of the quantization unit. 3/32nd should shrink to 1/32nd and 1/4th should shrink to 1/16th at 1/16 Q.
I think I can fix this for normal resizing. However, I have no ideas for Shift + <drag> resizing. Any ideas?

[vlad0337187]

Why does note's length must change at all ?)
I think, that we must constrain only it's resizing...

[vlad0337187]

We need not to lose this PR: https://github.com/LMMS/lmms/pull/3998

What do I think, is there any use-case for zero-length notes ?
What it will do at all ?

I think, that just limiting reducing note's length to be lesser than quantizing size will solve all problems, or no ?

[Spekular]

Preventing it from going to less than the finest quantization (1/192) would
work just as well, no? Being able to resize a 3/32nds note to 1/32nd at
1/16th Q is useful, for example

On Fri, Mar 9, 2018, 16:43 Vladislav [e-mail] wrote:

We need not to lose this PR: #3998
https://github.com/LMMS/lmms/pull/3998

What do I think, is there any use-case for zero-length notes ?
What it will do at all ?

I think, that just limiting reducing note's length to be lesser than
quantizing size will solve all problems, or no ?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/LMMS/lmms/issues/3989#issuecomment-371849260, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIgVmlhccUrtmwDZv2FT_cggfzAYI6yVks5tcqMQgaJpZM4Qjeda
.

[zonkmachine]

I found this surprisingly confusing to hack around but I'm looking into it again.

[musikBear]

is there any use-case for zero-length notes ?

@vlad1777d
Its the concept 'zero-length notes' that makes this all murky. The first idea, was that these 'notes' should represent the initiation-point of a _sample_.
'zero-length' was meant to mean, that it was not the visual length of the 'note' that should determine the play-length, it was the _sample-length_ -Iow the whole sample should be played, each time a 'initiation-note' was met.
The wording 'zero-length notes' underlined the fact, that these notes could not me length-manipulated by user, and they had a different color (they dont in RC5).
This idea- fi. see #2255, was never implemented. 'zero-length notes' did not get the feature to play all of a sample.
But 'play full length' _was_ the usecase -once 😺

[vlad0337187]

@musikBear , thank you.

Maybe problem of playing all samples doesn't belong to Piano Roll, but to specific instrument ?

Maybe some MIDI CC (or GUI option with automatization), or some note (for example, like keys-switchers of playing style in V-Metal guitar (under Kontakt sampler)) shold do this ?

Because as I think, that Piano Roll must represent just notes itself, nothing more.
All other stuff could be done using automatization.
And note which has no length, has no playing time.

[musikBear]

Because as I think, that Piano Roll must represent just notes itself, nothing more.
All other stuff could be done using automatization.

@vlad1777d -i understand your point of view, but slide-notes would offer very exiting possibilities, and they are seriously better to work with, than automation. If lmms had sliders, i am in no way suggesting any limitation to current automation-slide, but current method is cumbersome. -but try slide-notes in fls, and i believe you will understand the power of that method :)

[vlad0337187]

@musikBear , I don't really know LMMS' codebase, but think, that "slide" notes could be marked with something like slide: True property on Note's class instance.

Than LMMS will send that notes as "slide" notes to those instrument plugins, which support it, ignoring plugins which don't support it.

And length - is a separate thing.
I think, notes should not be zero-length - it's extremely difficult to move them with mouse.
Also if they have 0 length, we should not see them all =)
Never seen on youtube notes with zero length in any DAW =)

[musikBear]

@vlad1777d Noo * 2
First 'zero-length-notes' was just a name, The graphical representation was 1/16, but distinctly different in color.

And no, 'sliders' should be a new type of notes. Look at this mock-up

User has chosen the new note sliders (pink) and inserted several. On the sliders he then drag out 'speed&positions' markers, and connect them to the normal notes, and all takes place in piano-roll! -No need for the automation-editor. That is how i visioning this

[vlad0337187]

@musikBear , well, I like the idea.

Than, as I understand, resizing notes could be limited to quantization size until it would be == quantization size.

If user will try to make it lesser, than it should be reduced to quantization size / 2, and etc.

And if user would increase that little note, it would be increased so (quantization size / 4, quantization size / 2, quantization size).
And after it would be == quantization size, than it would be increased on += quantization size.

Right ?

[musikBear]

@vlad1777d

Right ?

yikkk..d eh.. quantization size..?
Why is that an issue? I would allow any length of normal and 'pink-sliders'
But you specific write

Resizing notes

I think you is a step infront of me, here! You are thinking about how the behaviour of the sliders should be, if the normal-notes are resized(?)
That is interesting! Has to be solved.. 👍

[vlad0337187]

@musikBear ,

quantization size..?
Why is that an issue? I would allow any length of normal and 'pink-sliders'

I think, because quantization size specially was added to limit resizing notes to it =)

[musikBear]

@vlad1777d neh Q is a mean to ensure note-to-measure fitting. If you work with fixed note sizes, and use the available Q values, you should never have notes that over-shootes the measure-dividing. Quite often peeps complains like: "why do i have an empty bar in songeditor"
The explanation is a fraction of an overshoot into the next bar. They cant see that in 100% magnification, maby 400 or even 800 is needed.
free-Resize or forced-snap are a question of 'creative freedom'. Freely resizeable notes means for creativity, but also more possibility of trouble.
Imo, LMMS offers both, and in a predictable and controllable way

[zonkmachine]

I tested https://github.com/LMMS/lmms/pull/3998 again and it works well.

@zonkmachine Am I misunderstanding or are you saying all notes will snap to multiples of the current quantization? For example a 1/32nd note scaled up at 1/16th Q snaps to 1/16th length rather than 3/32nds?

I think we both misunderstood each other.
No. Se case 5 below. If I don't let go of the left mouse button when resizing it will remember its old length and the quantized value is added or retracted from it. This is the same today as with my patch. No difference. The difference is that by default there is a minimum note length set by the quantization value. You can resize it to a smaller or arbitrary length still by pressing down the key.

Some test cases. 1 - 4 are with stable 1.2.1 and 5 - 6 are with Proposed https://github.com/LMMS/lmms/pull/3998 I do the same test in all cases. Starting with a note I diminish it to minimum and then extend it out to a whole note.

stable-1.2.1
1 Start with a 1/4 note, resize it to a 1/192 note and then drag it out to a whole note. All this without lifting the left mouse button (lmb).

2 I now drag the note to a 1/192 note and let go of the lmb. I then resize it to a whole note and it now has an extra 1/192 note on the end.

3 I start with 3/32 length and repeat the action of 1. Even though the note is at minimal length it remembers its odd value and carries it with it when you resize it.

4 I start with 3/32 length and repeat the action of case 2 and end with the same result.

stable-1.2.1 with https://github.com/LMMS/lmms/pull/3998 applied.
5 Same as 3 but it stops at the quantization value. Since we don't let go of the lmb it still remembers its old length.

6 You leave it at the minimal length and can use the stop as a quick method to readjust odd length notes.

[zonkmachine]

PR reopened and updated. Binaries here: https://github.com/LMMS/lmms/pull/3998#issuecomment-626238605

[musikBear]

Starting with a note I diminish it to minimum

Yes, your PR @zonkmachine has better logic. With Q == 1/16 the note should not be dragged below that length, without using the drag-modifier key Alt+drag (that is still possible -right?

[zonkmachine]

_without_ using the drag-modifier key Alt+drag (that _is still_ possible -right?

Yes

[Spekular]

Close? With #5512 merged, you can't end up with "weird" note lengths unless you intentionally create one at some point. If you only use multiples of 1/2, the smallest length you can achieve is equal to the smallest quantization you've used (I think).

The same applies if you only use multiples of 1/3. Things get a bit less predictable if you mix and match, where you could create lengths like (1/2 - 1/3) or (1/3 - 1/4), but I don't think we can hand-hold too much regarding minimum note lengths without getting in the way.

[vlad0337187]

@Spekular , thank you very much ))

[SecondFlight]

you can't end up with "weird" note lengths unless you intentionally create one at some point

Closing as suggested. The UX part of this seems to have been resolved, i.e. you only get weird note lengths if you want them. Feel free to override this.