The demo fines: insights into common user mistakes

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

The demo fines: insights into common user mistakes

David Bolton-2
As I made copy edits to the demo files recently, the most common mistake
was not having the special end bar on the last measure of the piece.
Most score writers take care of the end bar automatically. It means one
less thing for the user to worry about.

In the demo file "Inventio 1" slurs were used several times rather than
the intended ties. Every score writer I've used makes a distinction
between slurs and ties, but it is a common user mistake because they
both look the same on the score. I think there is an argument for
removing the burden of this distinction from the user to the software.
For details see the "Slurs vs. ties" heading at
http://davidbolton.info/articles/notation_interface_design.html

--
David Bolton
http://davidbolton.info



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: The demo fines: insights into common user mistakes

wschweer
Administrator
Experience says that when a program tries to guess what a user means a
lot of special cases are created which must be coded, tested and maintained.
For a user it gets complicated when the program guesses wrong or shows an
unexpected behaviour. At first look a special automatic behaviour may be
simple but often it turns out to be more complex.
This said in general to explain why i am overly cautious in implementing
such things.

A special end bar line should be automatically created by the "new wizard".
I am not sure what should be happen if i append a measure to the score.
Maybe the end bar line should be moved to the end of the appended measure.
But what if the end bar line is a reapeat end? Things are getting more complex
then.

Slurs and ties are implemented as separate objects in mscore because of
different playback behaviour and possibly slightly different layout rules.
One special about ties is that a note accidental is omitted on the
second note when the note is in the next measure.

I was not aware of the rule that a slur between two notes of equal
pitch is always a tie.

Automatic selection between slur and tie cannot be implemented in a sane way
with the current internal structure. Escpecially its not possible for an
element to change type during editing.
After all i think it can be implemented but whould require invasive changes
to the code.

On Montag 02 Juni 2008, David Bolton wrote:

> As I made copy edits to the demo files recently, the most common mistake
> was not having the special end bar on the last measure of the piece.
> Most score writers take care of the end bar automatically. It means one
> less thing for the user to worry about.
>
> In the demo file "Inventio 1" slurs were used several times rather than
> the intended ties. Every score writer I've used makes a distinction
> between slurs and ties, but it is a common user mistake because they
> both look the same on the score. I think there is an argument for
> removing the burden of this distinction from the user to the software.
> For details see the "Slurs vs. ties" heading at
> http://davidbolton.info/articles/notation_interface_design.html
>




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: The demo fines: insights into common user mistakes

David Bolton-2
Werner Schweer wrote:
> Experience says that when a program tries to guess what a user means a
> lot of special cases are created which must be coded, tested and maintained.
> For a user it gets complicated when the program guesses wrong or shows an
> unexpected behaviour. At first look a special automatic behaviour may be
> simple but often it turns out to be more complex.
> This said in general to explain why i am overly cautious in implementing
> such things.
>  
I am sympathetic to your caution. Microsoft Word comes to mind when you
mention unexpected, automatic behavior. However most users would
probably expect to see an end bar at the end rather than a normal barline.

> A special end bar line should be automatically created by the "new wizard".
> I am not sure what should be happen if i append a measure to the score.
> Maybe the end bar line should be moved to the end of the appended measure.
>  
Yes, moving the end bar line to the appended measure is the expected
behavior.

> But what if the end bar line is a reapeat end? Things are getting more complex
> then.
>
>  
Finale and Sibelius have slightly different implementations for
appending measures. Either one is acceptable. They differ only on step 3.

Append bar algorithm in Finale:
(1) If the last measure has an end bar then change it to normal barline,
otherwise do not change it
(2) Append measure(s)
(3) Add end bar to the last appended measure

Append bar algorithm in Sibelius:
(1) If the last measure has an end bar change it to normal barline,
otherwise do not change it
(2) Append measures(s)
(3) If the measure in step 1 was an end bar then add end bar to the last
appended measure, otherwise leave it as a normal barline

I thought it deserved mention after editing the demo files but I
recognize this behavior adds some complexity to the program and only a
small benefit to the user. Finale has be around for years but only
implemented this behavior around 2005.

--
David Bolton
http://davidbolton.info


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: The demo fines: insights into common user mistakes

wschweer
Administrator
On Donnerstag 05 Juni 2008, David Bolton wrote:
...

> Finale and Sibelius have slightly different implementations for
> appending measures. Either one is acceptable. They differ only on step 3.
>
> Append bar algorithm in Finale:
> (1) If the last measure has an end bar then change it to normal barline,
> otherwise do not change it
> (2) Append measure(s)
> (3) Add end bar to the last appended measure
>
> Append bar algorithm in Sibelius:
> (1) If the last measure has an end bar change it to normal barline,
> otherwise do not change it
> (2) Append measures(s)
> (3) If the measure in step 1 was an end bar then add end bar to the last
> appended measure, otherwise leave it as a normal barline
>
> I thought it deserved mention after editing the demo files but I
> recognize this behavior adds some complexity to the program and only a
> small benefit to the user. Finale has be around for years but only
> implemented this behavior around 2005.

ok, looks simple. I implemented the sibelius variant in revision 999.




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|

Re: The demo fines: insights into common user mistakes

David Bolton-2
Werner,

I forgot about the second half of the end bar implementation: deleting
measures from the end of the score. Below are the two algorithms by
Finale and Sibelius. I like how Finale only changes normal bar lines to
end bars, but either implementation is acceptable.

Finale algorithm:
(1) Delete measures
(2) If the new last measure of the piece is a normal bar line change it
to an end bar otherwise do not change it

Sibelius algorithm:
(1) Remember if last measure is has end bar
(2) Delete measures
(3) If the measure in step one was an end bar change the new last
measure to an end bar regardless of its previous bar type

Note:
In the current version of MuseScore there is a bug that affects
multi-measure deletes. If you delete several measures at once the last
of the selected measures remains on the score. I mention this because it
may give you otherwise unexpected results when you test this.

David


Werner Schweer wrote:

> On Donnerstag 05 Juni 2008, David Bolton wrote:
> ...
>  
>> Finale and Sibelius have slightly different implementations for
>> appending measures. Either one is acceptable. They differ only on step 3.
>>
>> Append bar algorithm in Finale:
>> (1) If the last measure has an end bar then change it to normal barline,
>> otherwise do not change it
>> (2) Append measure(s)
>> (3) Add end bar to the last appended measure
>>
>> Append bar algorithm in Sibelius:
>> (1) If the last measure has an end bar change it to normal barline,
>> otherwise do not change it
>> (2) Append measures(s)
>> (3) If the measure in step 1 was an end bar then add end bar to the last
>> appended measure, otherwise leave it as a normal barline
>>
>> I thought it deserved mention after editing the demo files but I
>> recognize this behavior adds some complexity to the program and only a
>> small benefit to the user. Finale has be around for years but only
>> implemented this behavior around 2005.
>>    
>
> ok, looks simple. I implemented the sibelius variant in revision 999.
>  

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer