GSOC Project Ideas

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GSOC Project Ideas

dmcneela
I have two potential project ideas for GSOC that I've been mulling over, and I'd like to get others' feedback. Please let me know if these are features that you would find valuable. Also, please let me know if anyone would be interested in mentoring such a project.

1. Most guitar and bass sheet music available online is distributed in tablature format using a simple, text-based notation. As far as I know, MuseScore does not currently have any facility for working with tabs contained in plain .txt files. I am interested in adding functionality that  would allow MuseScore to download tabs from popular tab websites such as ultimate-guitar.com or import tabs saved in .txt files. The imported or downloaded text would then be parsed and converted into MuseScore's native notational format to be displayed in MuseScore's standard staff and tab notation. The program would also generate guitar chord diagrams from the imported tab.

I would also implement a new feature that would allow tabs created in MuseScore to be exported as ASCII text files, with proper text tab notation, for sharing on tablature sites.

2. I am also interested in the OMR project listed on the ideas page. In addition to the desired features mention in the project description, I would be interested in implementing OCR capabilities for handwritten guitar tablature. As I understand it, OCR technology as it pertains to general music notation is rather unreliable at the present time due to the wide variability in symbols and styles used in general music notation. However, guitar tablature is significantly simpler than the general notational case in that it consists only of fret numbers and a few additional characters for indicating certain performance techniques. Since current OCR implementations already achieve very high accuracy in identifying handwritten numbers, applying OCR to guitar tablature should not be too significant a leap.

Please let me know your thoughts and suggestions!

Thanks,

Daniel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GSOC Project Ideas

AndreiTuicu
Hi, Daniel,

I have a question regarding your first project idea: how can you tell from a text-based tab what is the duration of each individual note when converting to MuseScore's format?

Thank you,
Andrei

2016-03-06 23:46 GMT+02:00 dmcneela <[hidden email]>:
I have two potential project ideas for GSOC that I've been mulling over, and
I'd like to get others' feedback. Please let me know if these are features
that you would find valuable. Also, please let me know if anyone would be
interested in mentoring such a project.

1. Most guitar and bass sheet music available online is distributed in
tablature format using a simple, text-based notation. As far as I know,
MuseScore does not currently have any facility for working with tabs
contained in plain .txt files. I am interested in adding functionality that
would allow MuseScore to download tabs from popular tab websites such as
ultimate-guitar.com or import tabs saved in .txt files. The imported or
downloaded text would then be parsed and converted into MuseScore's native
notational format to be displayed in MuseScore's standard staff and tab
notation. The program would also generate guitar chord diagrams from the
imported tab.

I would also implement a new feature that would allow tabs created in
MuseScore to be exported as ASCII text files, with proper text tab notation,
for sharing on tablature sites.

2. I am also interested in the OMR project listed on the ideas page. In
addition to the desired features mention in the project description, I would
be interested in implementing OCR capabilities for handwritten guitar
tablature. As I understand it, OCR technology as it pertains to general
music notation is rather unreliable at the present time due to the wide
variability in symbols and styles used in general music notation. However,
guitar tablature is significantly simpler than the general notational case
in that it consists only of fret numbers and a few additional characters for
indicating certain performance techniques. Since current OCR implementations
already achieve very high accuracy in identifying handwritten numbers,
applying OCR to guitar tablature should not be too significant a leap.

Please let me know your thoughts and suggestions!

Thanks,

Daniel



--
View this message in context: http://dev-list.musescore.org/GSOC-Project-Ideas-tp7579623.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------

_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GSOC Project Ideas

dmcneela
This post was updated on .
Hi Andrei,

Determining note duration is a common issue with text-based tabs, and in most cases it is left to the performer to infer note durations from recorded audio of the songs being tabbed.

That said, for the purposes of conversion, I think there is one good way to get a best approximation of note duration. In many cases, information can be gleaned about the duration of notes relative to one another from their spacing within a measure. Text tabs use '-' for spacing, and generally the insertion of more than one dash between subsequent notes indicates longer duration for the first note. For any given measure, determining duration should be a matter of counting the number of notes and dashes contained within that measure, and then using the spacing between notes to determine their relative durations. An initial guess will have to be computed for the duration represented by the standard single dash spacing, and this could be done by dividing the measure count by the total number of notes within the measure. An assumption will also have to be made about the key signature, and in most case I believe 4:4 would be appropriate.

I'll illustrate what I'm talking about with an example tab. The below tab is from Stairway to Heaven by Led Zeppelin.

E-------5-7-----7-|-8-----8-2-----2-|-0---------0-----|-----------------|
B-----5-----5-----|---5-------3-----|---1---1-----1---|-0-1-1-----------|
G---5---------5---|-----5-------2---|-----2---------2-|-0-2-2-----------|
D-7-------6-------|-5-------4-------|-3---------------|-----------------|
A-----------------|-----------------|-----------------|-2-0-0---0--/8-7-|
E-----------------|-----------------|-----------------|-----------------|

In the first two measures, the spacing is the same between each note. Therefore, I would just assume the measure length to be 4 beats, and then divide by the total number of notes in the measure (8) to arrive at the conclusion that each note should be rendered in MuseScore as an eighth note. This is actually the correct representation of the notes within those measures.

In measure 3, you can see that three dashes separate the second 1 on the second string, and the second 0 on the first string. In this case, there are two more dashes than normal, so the program would assume that the duration of the 1 should be twice that of the duration of the zero. (If there was one extra dash, it would be one and a half times the duration, i.e. a dotted note) Since the standard note for the measure is an eighth note the 1 would be converted into a quarter note, and the total duration for the measure would still be correct.

I should note that this process is definitely reliant on the person providing the tab to articulate the correct relative spacings, but I think it's the best that can be done given the source format. If there were any miscalculated durations, it would be up to the user to go in and fix them manually once the notation was generated.

I should also mention that this process is much easier in reverse, i.e. for the purposes of exporting, as the durations would already be keyed into MuseScore and the program could easily calculate the corrective relative spacings between notes to provide in the outputted text tab.

If I did put this forward as my official proposal, I'd make the algorithm explicit and create examples of text tabs and the desired outputs in MuseScore for further illustration. I hope this makes the general idea of the process clear though.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GSOC Project Ideas

lasconic
Administrator
Hi Daniel,

If you want user feedback on your proposals, I would suggest to post them on the Tech preview forum https://musescore.org/en/forum/687 in two different posts.
The developer mailing has a really limited audience of mainly developers.

Regarding ASCII tabs, TuxGuitar can import them. You could have a look to their code to see how they cope with rhythm. About export, you'd need to come up with a strategy for scores without tabs or score with tabs and standard notation. Note that MuseScore requires to have full measures in voice 1, so rhythm is important.

The OMR project has nothing to do with tabs or number recognition, so it's better to not call your proposal this way.
Realtime recognition of fret numbers is a cool idea has an alternative note entry mode. Rhythm might also be an issue here.

lasconic


2016-03-07 2:50 GMT+04:00 dmcneela <[hidden email]>:
Hi Andrei,

Determining note duration is a common issue with text-based tabs, and in
most cases it is left to the performer to infer note durations from recorded
audio of the songs being tabbed.

That said, for the purposes of conversion, I think there is one good way to
get a best approximation of note duration. In many cases, information can be
gleaned about the duration of notes relative to one another from their
spacing within a measure. Text tabs use '-' for spacing, and generally the
insertion of more than one dashe between subsequent notes indicates longer
duration for the first note. For any given measure, determining duration
should be a matter of counting the number of notes and dashes contained
within that measure, and then using the spacing between notes to determine
their relative durations. An initial guess will have to be computed for the
duration represented by the standard single dash spacing, and this could be
done by dividing the measure count by the total number of notes within the
measure. An assumption will also have to be made about the key signature,
and in most case I believe 4:4 would be appropriate.

I'll illustrate what I'm talking about with an example tab. The below tab is
from Stairway to Heaven by Led Zeppelin.



In the first two measures, the spacing is the same between each note.
Therefore, I would just assume the measure length to be 4 beats, and then
divide by the total number of notes in the measure (8) to arrive at the
conclusion that each note should be rendered in MuseScore as an eighth note.
This is actually the correct representation of the notes within those
measures.

In measure 3, you can see that three dashes separate the second 1 on the
second string, and the second 0 on the first string. In this case, there are
two more dashes than normal, so the program would assume that the duration
of the 1 should be twice that of the duration of the zero. (If there was one
extra dash, it would be one and a half times the duration, i.e. a dotted
note) Since the standard note for the measure is an eighth note the 1 would
be converted into a quarter note, and the total duration for the measure
would still be correct.

I should note that this process is definitely reliant on the person
providing the tab to articulate the correct relative spacings, but I think
it's the best that can be done given the source format. If there were any
miscalculated durations, it would be up to the user to go in and fix them
manually once the notation was generated.

I should also mention that this process is much easier in reverse, i.e. for
the purposes of exporting, as the durations would already be keyed into
MuseScore and the program could easily calculate the corrective relative
spacings between notes to provide in the outputted text tab.

If I did put this forward as my official proposal, I'd make the algorithm
explicit and create examples of text tabs and the desired outputs in
MuseScore for further illustration. I hope this makes the general idea of
the process clear though.



--
View this message in context: http://dev-list.musescore.org/GSOC-Project-Ideas-tp7579623p7579625.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
Loading...