Rosegarden

Did my last reply to this get through at all?  I got a very
strange bounce which suggested that SourceForge's mailer was
trying to verify my existence before accepting the mail, by
contacting the MX for all-day-breakfast.com and pretending to
start sending something to me, but that my MX (operated by
Demon) was rejecting their attempt because they got some
syntax wrong.  Very weird indeed.  Anyhow:

Ron Kuris wrote:

 > Shouldn't deleting a note automatically collapse adjoining rests?

I'm inclined to think it probably shouldn't.  Leaving a rest there
in place of the note has some advantages: it makes it more obvious
that you've just deleted a note of that duration, and allows you to
immediately replace it with another note of the same duration if
you wish; it means that the subsequent relayout is likely to be
minimal, so the mouse pointer will stay at roughly the right place
in the piece; and our collapse code is not clever enough to do the
right thing with rests always anyway (it's not always musically
correct to collapse rests, when they fall on beat boundaries).

Also it's very easy to cause the collapse to happen if you want it
to -- just click again, to delete the rest that replaced the note.


Chris

Chris Cannam wrote:

> Did my last reply to this get through at all?

I got both of them.

> Ron Kuris wrote:
>
> > Shouldn't deleting a note automatically collapse adjoining rests?
>
> I'm inclined to think it probably shouldn't.  ... (it's not always 
> musically correct to collapse rests, when they fall on beat boundaries).

Perhaps there should be an option.  I think it looks much better when 
the rest disappears.  If I code a preference (we could discuss the 
default) would that be ok?

There are also some additional problems with the collapse code I'd like 
to look at.  If you create this sequence:

1/4 rest, 1/16 rest, 1/4 rest, 1/16 rest ...

the way the combine code "requires" the new rest to be a valid musical 
length prevents these from being combined.

Is there, musically speaking, any reason to have a 1/16 rest followed by 
a 1/4 rest?  Or can rests be "sorted" within the bar?

> Also it's very easy to cause the collapse to happen if you want it
> to -- just click again, to delete the rest that replaced the note.

Again, I think this is an advanced user option.

I guess why I'm passionate about this is that if Rosegarden is easy to 
use for first-timers, it is more likely to gain widespread acceptance.

Ron

On Wednesday 14 November 2001 16:26, Ron Kuris wrote:
> I guess why I'm passionate about this is that if Rosegarden is easy to
> use for first-timers, it is more likely to gain widespread acceptance.

That's not so obvious. Such "first timers" are most likely to be musicians 
already having previous experience with other sequencers. And by default (I 
don't know how configurable this is), neither Cubase or Logic collapse rests 
when you erase a note.

But I'm all for making this optional, though. A common trend in sequencers is 
that everything has loads of options behind it.

-- 
Guillaume
http://www.telegraph-road.org

On Wednesday 14 November 2001 13:06, Chris Cannam wrote:
> Also it's very easy to cause the collapse to happen if you want it
> to -- just click again, to delete the rest that replaced the note.

Alt/Ctrl/Double-click could delete and collapse...

-- 
Guillaume
http://www.telegraph-road.org

Ron Kuris wrote:

> If I code a preference (we could discuss the 
> default) would that be ok?


We could probably do with some GUI (and code framework) for setting
preferences, before we start coding up all sorts of hidden ones.
I assume KDE will help here.  Perhaps at the moment we should just
list the suggested preferences in a big file somewhere.

> If you create this sequence:
> 
> 1/4 rest, 1/16 rest, 1/4 rest, 1/16 rest ...
> 
> the way the combine code "requires" the new rest to be a valid musical 
> length prevents these from being combined.


Well, that's reasonable enough.  If you combined the first two or
the last two, or combined all four, you'd end up with something you
couldn't draw as a single note anyway.  You'd have to write it as a
tied minim and quaver, or something.  There'd be no point, surely?

Would you rather it merged them and then "rounded down" to a minim?
That would leave the bar an incomplete length, and could make it
difficult to fill it out with correct notes again.

> can rests be "sorted" within the bar?


In general, no.  Consider a 6/8 bar containing a crotchet rest,
quaver rest, crotchet rest, quaver rest.  If you sorted them into
two crotchets and two quavers you'd end up with rests on the off-
beats, which would be rather misleading to the reader as 6/8 is
supposed to have only two beats per bar, not three.

That sort-of illustrates the general point here: if we try to
cleverly merge rests whenever we can, we'll end up getting it
wrong quite a lot of the time, and if we make it _really_ clever
so that it gets the most likely set of "right" rests in the
"right" order, it'll only confuse beginners (for instance if you
delete a quaver next to a crotchet rest and it replaces them with
a crotchet rest followed by a quaver rest -- which could happen).

There is a function (TimeSignature::getDurationListForInterval)
that attempts to calculate the "best" series of rests to fill an
interval of a given duration starting at a given point in a bar
of a given time signature; it doesn't always get it right, but in
any case I wouldn't suggest using it in this instance.


> if Rosegarden is easy to 
> use for first-timers, it is more likely to gain widespread acceptance.

But for first-timers, consistency is as important as cleverness.
Doing what they mean is only good if it is actually what they
mean, and trying to be clever and getting it wrong is going to
put anyone off -- beginner or advanced user.


Chris

Guillaume Laurent wrote:

> Alt/Ctrl/Double-click could delete and collapse...

Arguably double-click already does.


Chris

Chris Cannam wrote:

> Perhaps at the moment we should just list the suggested preferences in a
> big file somewhere.

Yes, this is a good idea.  Even better would be a source-code comment
starting with
// PREFERENCE AUTO_COMBINE_RESTS
or maybe #ifdef PREFERNCE_AUTO_COMBINE_RESTS ?

I just hate keeping alternate files somewhere, when the source code will do
;-)

> > If you create this sequence:
> >
> > 1/4 rest, 1/16 rest, 1/4 rest, 1/16 rest ...
> >
> > the way the combine code "requires" the new rest to be a valid musical
> > length prevents these from being combined.
>
> Well, that's reasonable enough.  If you combined the first two or
> the last two, or combined all four, you'd end up with something you
> couldn't draw as a single note anyway.  You'd have to write it as a
> tied minim and quaver, or something.  There'd be no point, surely?

The trouble is, what if I want to turn this into a 1/2 rest and a 1/8 rest?
I have no way of doing that with the current UI, short of inserting some
extra notes to break up the 1/4 rest.

I'm not sure if cut and paste would solve this problem.

> Would you rather it merged them and then "rounded down" to a minim?
> That would leave the bar an incomplete length, and could make it
> difficult to fill it out with correct notes again.

I don't understand why it would be difficult to fill with the correct notes
again.

> > can rests be "sorted" within the bar?
>
> In general, no.  Consider a 6/8 bar containing a crotchet rest,
> quaver rest, crotchet rest, quaver rest.  ...as 6/8 is
> supposed to have only two beats per bar, not three.

Okay, thanks for the explanation!  I guess I haven't seen much of this.

> There is a function (TimeSignature::getDurationListForInterval)
> that attempts to calculate the "best" series of rests to fill an
> interval of a given duration starting at a given point in a bar
> of a given time signature; it doesn't always get it right, but in
> any case I wouldn't suggest using it in this instance.

I think a preference, combined with say an ALT keystroke, would be good:

How about the default eraser behavior is to erase only the current note, no
combining, unless you have ALT down, then it combines aggressively to the
left and right within the bar, leaving you with a sorted group of short
rests.

And the preference can switch the behavior of the ALT key.

> But for first-timers, consistency is as important as cleverness.
> Doing what they mean is only good if it is actually what they
> mean, and trying to be clever and getting it wrong is going to
> put anyone off -- beginner or advanced user.

Yes, this is true.  I guess it didn't do what I meant so I thought it should
be changed ;-)

Ron

On Wednesday 14 November 2001 19:44, Chris Cannam wrote:
> Guillaume Laurent wrote:
> > Alt/Ctrl/Double-click could delete and collapse...
>
> Arguably double-click already does.

No, because it's viewed by Qt as a different event, which we don't process 
(yet).

-- 
					Guillaume.
					http://www.telegraph-road.org

Guillaume Laurent wrote:

>>Guillaume Laurent wrote:
>>
>>>Alt/Ctrl/Double-click could delete and collapse...
>>>
>>Arguably double-click already does.
> 
> No, because it's viewed by Qt as a different event


Jeez, I know that.  That's why I said "arguably".

Still, making double-click do the delete-and-collapse looks like
a pretty good idea to me, because it's so neatly analogous with
what happens when you simply click twice now.


Chris

Ron Kuris wrote:

> what if I want to turn this into a 1/2 rest and a 1/8 rest?


You certainly have a point there.  I think for this general case
we could do with a menu function for it: you drag out a selection,
and then choose "Transforms | Merge Rests" if you want the most
aggressive legal merge, or "Transforms | Normalize Rests" if you
want Rosegarden to make the set of rests it thinks looks best.
The selection wouldn't have to contain only rests; the function
would act on every distinct group of rests within the selection.

(Not sure about "Transforms" as a name, but I've written it
provisionally into notation.rc anyway.)

I definitely favour making the editing actions work reasonably
predictably and then putting clever stuff into menus, except
where the clever stuff is really obviously worthwhile.

>>That would leave the bar an incomplete length, and could make it
>>difficult to fill it out with correct notes again.
> I don't understand why it would be difficult to fill with the correct notes
> again.


Well, we have a general problem at the moment that if a bar ends
up the wrong length for some reason it can be difficult (if not
impossible) to make it the right length again.  We need to give
that some thought anyway, I suspect.


Chris

Chris Cannam wrote:

> ...we could do with a menu function for it: you drag out a selection,
> and then choose "Transforms | Merge Rests" if you want the most
> aggressive legal merge, or "Transforms | Normalize Rests" if you
> want Rosegarden to make the set of rests it thinks looks best.
> The selection wouldn't have to contain only rests; the function
> would act on every distinct group of rests within the selection.

This sounds good to me, but I would want to do one of these all the time,
automatically, whenever I delete a note.  That should be a preference (since I am
the only one preferring it ;-).

> (Not sure about "Transforms" as a name, but I've written it
> provisionally into notation.rc anyway.)

It's fine, I think.

> I definitely favour making the editing actions work reasonably
> predictably and then putting clever stuff into menus, except
> where the clever stuff is really obviously worthwhile.

I think the distinction here is what is obviously worthwhile to one person
perhaps isn't so to another.

> >>That would leave the bar an incomplete length, and could make it
> >>difficult to fill it out with correct notes again.
> > I don't understand why it would be difficult to fill with the correct notes
> > again.
>
> Well, we have a general problem at the moment that if a bar ends
> up the wrong length for some reason it can be difficult (if not
> impossible) to make it the right length again.  We need to give
> that some thought anyway, I suspect.

I think it should be difficult (if not impossible) to make a bar end up the wrong
length ;-)  I would hate to write code to deal with what I would consider to be a
bug.  There should be no way to get the bar the wrong length.

Ron

On Wednesday 14 November 2001 21:30, Chris Cannam wrote:

> > No, because it's viewed by Qt as a different event
>
> Jeez, I know that.  That's why I said "arguably".

Well guess what, actually it isn't. :-) (viewed by Qt as a different event, 
that is).

When you double click on a widget it doesn't get a double click event. It 
gets a mouse press then a mouse release, then a mouse double click, then 
another mouse release. Which makes things quite a bit more complicated.

> Still, making double-click do the delete-and-collapse looks like
> a pretty good idea to me, because it's so neatly analogous with
> what happens when you simply click twice now.

Well I've committed code which could do that if it weren't for the mouse 
press being received before the double click. The fun part is that the redraw 
occurs so quickly that it doesn't really make a difference anyway, even if 
it's processed as two seperate clicks.

I suggest we use a modifier instead.

-- 
					Guillaume.
					http://www.telegraph-road.org

Guillaume Laurent wrote:

> The fun part is that the redraw 
> occurs so quickly that it doesn't really make a difference anyway, even if 
> it's processed as two seperate clicks.


So why not leave it the way it is, if it doesn't make any difference?
(I'd dispute that the redraw is that quick, but then my machine is
probably slower than yours.)


Chris

On Thursday 15 November 2001 12:10, Chris Cannam wrote:

> So why not leave it the way it is, if it doesn't make any difference?
> (I'd dispute that the redraw is that quick, but then my machine is
> probably slower than yours.)

Well, I've tried on a trivial 4 bars long, empty track, and you still see the 
intermediate rest being drawn before it's erased, so it would certainly make 
a difference on larger tracks.

Another thing is that we'll probably need to have a clear distinction between 
double and single clicks at the NotationView level in the future, so whatever 
hack is required to get it is welcome (some are described on the qt mailing 
list).

-- 
Guillaume
http://www.telegraph-road.org

On Thursday 15 November 2001 12:24, I wrote:
> Another thing is that we'll probably need to have a clear distinction
> between double and single clicks at the NotationView level in the future,
> so whatever hack is required to get it is welcome (some are described on
> the qt mailing list).

... but I've always made it a policy not to implement things just because "we 
might need them later", especially when there's a simpler alternative. So 
I'll go for the modifier instead, and possibly a toggleable option.

-- 
Guillaume
http://www.telegraph-road.org