Gregorian chant

• Jun 14, 2011 - 17:31
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Status
active
Regression
No
Workaround
No
Project

Is it possible to implement a gregorian chant style in MuseScore? There would be a 4-lines staff with no time, squared notes, gregorian clefs and a tool that recognizes neumas. Also a gothic font should be included for big first letters.

Federico


Comments

ok it's a good stuff but actually it doesn't have a gui, but it uses xml to write gregorian music. So why don't we implement it in MuseScore? Gregorio is released under GPL so you can freely use it if you write credit Gregorio for the way of write gregorian. Is it possible?

I finished ttf font. It needs some corrects, (If you want to try it in WORD or another text editor, set line spacing to min. 1,5 line); Name of the font in programs: "Untitled 2".

Zip contains source file from FontForge .

Attachment Size
grecialae.zip 376.2 KB

Thank you so much for providing the font!

I am not an expert of plainsong, but I suspect that this font cannot be used in the way it is currently organized: I believe that pre-composed ligaturae are not suitable; rather they have to be created on the fly by the program from individual elements; at least, this is how the program works now for beams, stems and linear elements in general.

This is doable for neumes like clivis, pes, etc. but porrectus and the like might be a problem. Also probably a way has to be found to indicate neume boundaries (five descending notes are 1 clivis + 1 climacus or viceversa?).

In practice, the font is one important piece, but a lot of programming is also required and, unless someone comes forth with a decent working knowledge of both plainsong and C++, the idea risks a lot to remain just a wish!
____________

About the font itself, I noticed a few things:

- Several glyphs are encoded in the range 0x0000 - 0x001F, which is highly problematic.

- No glyph is assigned a Unicode point or a name.

- Glyphs are probably too small; MuseScore expect glyphs to suit a defined scale (note heads should fill 1/4 of the em size).

- A number of glyphs are repeated (for instance, two C clefs and two F clefs right at the beginning): is this intentional? is there some difference betwen them?

- Bar lines are not needed; MuseScore already supports partial bar lines; the same is probably true also for episema (via "Lines palette").

So, the font is a solid and encouraging start point, but the font designer will probably need to work a fair deal together with coder to match and help the code implementation.
____________________

Now, the BIG question is: who's going to do it?

Thanks,

M.

I have an idea of way of writing neumes into score editor:
The base are syllabes of text. Each syllabe has own editable "box" on the staff. Inside it you just click on the proper line or space - the punctum quadratums will be change to scandicus / torculus / porrectus etc... You can also choose another neume (like now you can choose full-, half-, quarter-note), like punctum quadratum, punctum inclinatum, virga, strophicus...

I hope you understood my mind.
Really sory for my bad english. :(
----------------

To font that I uploaded:
I just copied and pasted glyphs from POST1 files to TTF.

In zip file are all POST1 files (two or three styles of neumes, and one file with ornaments and special letters), which may be edited using FontForge.

Attachment Size
grecialae_font.zip 1.22 MB
greogirio_font.zip 1 MB
parmesan.zip 1.22 MB
gresym.zip 32.19 KB

@ SirPL:

I think I have understood your idea, at least at a general level. You will understand that you are proposing at least an entirely new UI and an entirely different approach to basic internal data structure like measures, beats and so on. Other ideas are possible, but I suspect they will amount to a comparable amount of changes, as plainsong notation IS inherently different from mensural notation.

I think the whole idea is sensible, relevant and interesting and, a such, is worth approaching seriously.

It should be clear that this involves rather large programming/debugging/testing/documenting tasks; the result may be worth the effort, but I doubt that the current develoment team has the resources to cope with it. As nothing of this will be done by itself and someone has to do it, the BIG question remains on the table: who's going to do it?.

I believe that, probably, those seriously interested in having this notation area implemented in MuseScore have to lobby in order to:

1) estimate the effort involved (approximately but with some reliability);

2) sollicit a decision whether it makes sense to include this effort into MuseScore, evaluating the pros (wider field of application and greater audience) and the cons (impact on release time frames, impact on existing code functionality and reliability, existing specialized alternatives);

3) collect resources to back this effort, by finding motivated individuals with the necessary knowledge and/or by raising funds to pay for it and/or (...add your option here...).

Potentially, a specific project could be started under the MuseScore umbrella (Goggle Summer of Code ?) and carried forth by an interest group.

Thanks,

M.

I'm aware of amount of work needed to make this idea "alive".
And as you said, it needs programmers, who also knows greogrian chant... It may be the biggest challenge.

I don't see another good programm which offer editing gregorian chant, is easy to install and free (or very cheap).

In my opinion this project should be started. Even if the costs (time, people) are big.

I may be over-optimistic, but I am not so concerned by costs in term of money: from one side, if time tables are relaxed, volunteers may be found; on the other side, if funds for the OpenGoldberg project have been collected relatively quickly, the same might be possible for such a project, with a clearly defined goal and udience base (perhaps small but I believe rather reliable).

I am more concerned by three other points:

1) Finding the proper combination of knowledge.

2) Impact on existing code: as this new feature will inevitably re-use and possibly generalize existing routines (not ALL wheels need to be re-invented), there is a real risk of introducing new bugs and instabilities in the existing functions and features and this would affect the whole MuseScore project.

3) Opening some can of works. I know very little of plainsong, but I understand that there are grey areas and debated issues, some of them not so marginal. If the graphic reproduction of neumes is rather well defined, as soon as, for instance, playback will be involved, I expect arguments.

I still believe this to be a project worth the effort, particularly if users with a competence in the field lament the lack of convenient tools.

However, a word on this topic from the core devlopment team could be useful for helping setting priorities, timing scales and similar.

Thanks,

M.

Status (old) active postponed

My personal opinion: It's too much.

MuseScore has still a lot of missing features/bugs for conventional music notation/tablature. I wouldn't want MuseScore to loose itself in a project used by a very small group of people. If something different from conventional music notation would be implemented, I would prefer Jianpu over Gregorian chant. And still...

In term of timeline, we are only a few developers who knows the codebase. We worked hard to add new features in MuseScore 2.0. It's time to polish them and put them in front of users. We will talk about new features later.

I put this issue on postponed.

I agree with this Nicolas.

It is unrealistic to try to get this into MuseScore 2, which is already long overdue.

I personally think it is something that could be thought about for version 3.

Thanks to lasconic for taking a stance.

Ultimately I agree with him too, as my posts have rather clearly hinted at.

However, I still think that having an interest group focused in plainsong -- for instance, collecting over time data and tools (like fonts or relevant samples), establishing priorities on styles to implement and so on -- would be helpfull. Maybe not now as it will likely loose momentum in the waiting, but after ver 2.0 is released and the work on the next release will begin.

M.

P.S.: It is not my intention to start a religion war, but I would not rate Jianpu priority over plainsong's. It is true that user base is probably larger (anything having to do with China easily has a larger user base than anything else), but I think it belongs to those types of "simplified" notation, ultimately expressing the same contents as 'standard' notation, but in a reduced way to suit the lack of more evolved tools; with the cheap and easy availability of such tools -- thanks also to MuseScore -- I see less and less reasons to support them.

Plainsong, however, transmits contents which cannot be faithfully rendered in 'standard' notation and witnesses by itself a long and rather rich tradition not covered by other notations.

But of course, these are very subjective considerations.

Maybe the way forward for the future is to have a plugin which will convert standard notation to neumes, and then allow fine-tuning of the result by the addition of the more exotic neume forms - eg porrectus and scandicus?

I would certainly be willing to offer my expertise, although I am mainly interpreting the other way round - Ie neumes to standard notation.

I just installed and started using musescore last night. I love it!

I like this post, too.

I was just thinking one way to simplify some of the workload might be to simply make it so that the -

1 - Time signature could be altered for a customizeable number of notes. This way you could get as many notes as you need per measure.
and/or
2 - If the time signature could be turned off. So, if you set it to like 1200 notes, then you wouldn't see the ridiculously 1000/4 in the time signature.
and/or
3 - A way to turn off bar lines. There is already an option to alter bar lines. Why not just leave a blank option?

These suggestions - of course - are not everything one would need to write Gregorian Chants, but they would provide some simplistic solutions to common problems I have experienced when trying to adapt Gregorian music to modern notation.

Thank you for this great application!

wm

There are actually features in MuseScore 2 which go a long way to address some of your ideas.

There is the facility to split and join measures (bars) , suppress the display of the time signature, and the styles of barline required for plainsong notation are all available.

Although still at the pre-release stage, MuseScore 2 is stable enough for a lot of things, and will coexist quite happily with your 1.3 installation.

It's available from the very bottom of the download page.

It's already more than a year ago that there was a post. I recently (re)discovered Musescore and I am impressed by it. But I also want to be able to create Gregorian scores for our translated liturgy. I am trying Gregorio, but that is really not the thing I am looking for. I really need a wysiwyg tool. I hope there will be a plugin or tool for Musescore. The current features are not suitable for my goals.
Fr. Victor

Sorry ChurchOrganist, I missed your mementum.

I would love to see this project to progress; all its complexities still lie on the table, tough.

Would it not be the case to form -- publicly, if not formally -- a sort of MuseScore Plainchant Interest Group (MusPIG?) to act as a reference point/hub for ideas, proposals and coding efforts?

@Miwarre Re: Plainchant Interest Group.
That could only work if it attracted people with the right skills. As you yourself said above, implementing this feature requires a person to be skilled with C++, fonts and plainchant (not to mention familiar with the existing MuseScore codebase). My fear would be that an "interest group" would attract lots of would-be users, but no actual programmers. Worse still, the interest group could give the impression that the feature was actually being implemented, when there is no guarantee of this, leading to disappointment if it didn't happen.

Instead, perhaps we should create a "Developers need help with..." page where we list feature requests that are good ideas (like plainchant) but that none of the current developers have the skills/time/interest to implement. This way we would target potential developers rather than potential users, and thereby actually make some progress implementing the features.

Ultimately, MuseScore is open-source software and the features that get implemented are those that are of interest to the developers, not necessarily the users. There is no obligation to implement features based on how popular they might be. (This might sound harsh, but remember that conventional software only implements features that make money for the developers, which might even be the opposite of what the users want - e.g. DRM). If someone wants a new feature the only way to guarantee it gets implemented is if they implement it themself.

@Miwarre - I know you know all of this already. I just thought it was worth explaining for the sake of newcomers in case they were under the impression that they could "vote" for a feature.