Re: [Finale] Re: Scan and Default doc

[Johannes Gebauer]

I think part of the problem is that Fin98 output out of the box was not 
very suitable for scanning, too thin lines.

However, don't expect too much from scanning. If you really want to dive 
into it you should look at SharpEye, which I am told works much better.

On the other hand scanning has improved a lot in the last couple of 
versions in Finale.

Johannes
A-NO-NE Music wrote:
I have some questions from my experience last night.
The original was MacFinale98 output, scanned in 300dpi.  The archived
printout was very clean, and nothing was too tight or anything.  Yet I
after all felt I should had created from the scratch instead of scan.
- Missed a lot of measures here and there, one or two measures at a time,
while inserted empty measures where totally unrelated spots from missed
measures.  I was unable to see how SmartScore misunderstood like this.
- All the triprets became two 8th with double-sharp attached.
- All the tied notes, if not the beginning of the tie, and if accidental
is attached, became natural but cancellation of the accidentals were
invisible... strange.
- Missed a lot of ties even though the original was rather obvious.
The scanned image's x-y was straighten in Photoshop prior to SmartScan. 
I assume 300dpi is good enough.  What else I could had tried to make
SmartScan better?

--
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de
___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

Re: [Finale] Re: Scan and Default doc

[A-NO-NE Music]

Michael Good / 05.1.17 / 00:13 PM wrote:

>Hi Hiro,
>
>First, thanks for the beautiful music you shared with us at the
>holidays!

Thank you so much!
Appreciate it.

>The developers of the SmartScore import feature would benefit from it.
>It is much easier to develop an importer of any type for Finale if you
>can control what the default document looks like. A large part of our
>MusicXML software is devoted to *not* making assumptions about the
>default file, and instead just using what is there. We would make our
>development work simpler by just using a hard-coded default file, but it
>wouldn't work as well for plug-in users.

Ahh, I understand.  I was not familiar with Scan feature since I haven't
needed it that much.

I have some questions from my experience last night.
The original was MacFinale98 output, scanned in 300dpi.  The archived
printout was very clean, and nothing was too tight or anything.  Yet I
after all felt I should had created from the scratch instead of scan.

- Missed a lot of measures here and there, one or two measures at a time,
while inserted empty measures where totally unrelated spots from missed
measures.  I was unable to see how SmartScore misunderstood like this.
- All the triprets became two 8th with double-sharp attached.
- All the tied notes, if not the beginning of the tie, and if accidental
is attached, became natural but cancellation of the accidentals were
invisible... strange.
- Missed a lot of ties even though the original was rather obvious.

The scanned image's x-y was straighten in Photoshop prior to SmartScan. 
I assume 300dpi is good enough.  What else I could had tried to make
SmartScan better?

-- 

- Hiro

Hiroaki Honshuku, A-NO-NE Music, Boston, MA
 


___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale

[Finale] Re: Scan and Default doc

[Michael Good]

Hi Hiro,

First, thanks for the beautiful music you shared with us at the
holidays!

> Do you not think it is strange Finale has a separate default for
> SmartScan?  I wonder what scenario anyone would benefit from it...

The developers of the SmartScore import feature would benefit from it.
It is much easier to develop an importer of any type for Finale if you
can control what the default document looks like. A large part of our
MusicXML software is devoted to *not* making assumptions about the
default file, and instead just using what is there. We would make our
development work simpler by just using a hard-coded default file, but it
wouldn't work as well for plug-in users.

Best regards,

Michael Good
Recordare LLC
www.recordare.com



___
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale