Bug:- If 'Notation: Display notes that are more than three ledger lines off the staff' is set to 'off', then any notes on a piano (treble + bass) bass clef below E do not show
Couple of visual things. I've mentioned the dots being difficult to see before and you can see note heads are offset from the stave. The dotted quaver in the high voice seemed more obviously dotted here because of the contrast with its neighbour, but there's still a legibility issue.
Bug:- If 'Notation: Display notes that are more than three ledger lines off the staff' is set to 'off', then any notes on a piano (treble + bass) bass clef below E do not show
confirmed on new project in 13a
... but fixed in pre14 (and so is the hiding of 8va notes I reported in pre13a)
In general, REAPER uses the rhythm pattern set by the user to decide where to divide beams and tie notes. You can set the rhythm pattern by right-clicking at the start of a measure (or using the time signature/tempo marker dialog), and you can change the rhythm pattern without changing the time signature or tempo.
By default the pattern is always ABBBB... with as many Bs as there are beats in the time signature, so ABBB for 4/4, ABBBBB for 6/8, etc. In 4/4 if you set the rhythm pattern to ABAB, then beams will break at the middle of the measure. In 6/8 you can set up the rhythm pattern for either ABBABB or ABABAB, both of which are common.
We could change the default so that if the user doesn't set a pattern, we always break up the measure every 2 beats. You'd then lose the ability to choose *not* to break up a measure, if you wanted to beam all 6 beats of a 6/8 measure together. The benefit would probably outweigh the cost though, because the default behavior would be more as expected.
Hi Schwa - yes, that definitely does help in that the "invisible bar line" between beats two and three is respected. However sixteenth notes still seem to be allowed eight on a beam in 4/4 under this system whereas best practice is to break the beam at the end of each beat for ease of identifying the beat. Sibelius's approach to this, for example is to allow you specify groupings, i.e. 9/8 (2,2,2,3) or 9/8 (3,3,3) per time change, and by default 4,4,4,4 for a bar of 4/4. See attached beaming example - MIDI file exported from Reaper, imported into Sibelius at default values.
Quote:
- for best practice, patterns containing sixteenth notes generally only beam within each beat for ease of reading (i.e. the maximum number of sixteenth notes allowable on a beam [EDIT: IN 4/4 TIME] is also [EDIT: GENERALLY EXCEPT FOR SPECIAL CASES] four)
- the reason for this is that musicians generally practice "cells" of rhythms - all possible permutations of sixteenth notes within a beat...
Sorry for repeating, but it would be cool and very useful make something like as in Finale (visual example in attached picture), the feature with editable smart shape, editable slur tool (phrasing) and breaking/joining note beams (as option) for visual comfortability...
This is may be FR. Is it possible?
The bug shippo is referring to is low notes not being displayed on the bass clef of the grand staff when the option is enabled -- notes are improperly hidden if they are more than 3 ledger lines off the treble clef. The bug is fixed for the next build.
Besides giving an enormous amount of thanks for all the work on the notation editor, I´d like to suggest something that I think it´s neither exotic at all nor superfluous; to cover a broader range of note values (not to say the entire range, ideally), as illustrated, for example, in this wikipedia article (I know there are better sources, but this was at hand and it´s fine for this purpose) : https://en.wikipedia.org/wiki/Maxima_%28music%29
If I had to transcribe them, I wouldn´t be able with a palette ranging from sixty-fourth to whole notes (and we´re talking about Beethoven´s Pathetique Sonata, a core work of piano literature). Unless I´m missing some setting, I don´t seem to be able to write a hundred twenty-eigth note, as found in the second example above...
And then there is not only the early music repertoire, but to give an example, I have a work in 4/2 that makes plenty of use of double whole notes, in a way similar to this excerpt :
I can see that we can already get to a double whole note by resizing the length with the handle; anyway, it would be better if we could reach these kind of values with specific actions.
I can also recommend to extend the written dynamic range from pppp to ffff, at least. There is a not inconsiderable amount of examples of written works that make use of these extreme dynamics (Besides, for MIDI use - when we reach the stage where symbols will affect MIDI performance - it would also be useful).
Another thing that I can´t seem to find right now is the ability to write custom tuplets. Again, we could quote lots and lots of excerpts from western literature where they´re used, but for now I think it´s enough to quote again the excerpts from Beethoven, posted above, with 9 & 7 tuplets.
While I know that most probably a minority of users work with things such as these on Reaper, I dare to mention them because I think it´s something basic, nevertheless, to be able to write anything, taking into account that there is such a vast amount of written music that makes use of these resources (orchestral composers, at least, will surely agree, hopefully).
Well, these are my two cents...
Thanks again for all you´re doing, Schwa, this has a great future!
Last edited by Soli Deo Gloria; 03-02-2016 at 04:22 AM.
@SDG: if you set display to 1/64 and minimum note value to half of display quantize you can see 1/128th notes.
Thanks for the tip, snooks, but , do you effectively see those note values on the score editor with that option? If I turn it on and set the grid to 64 or 128 , the minimum value I see is 64, no matter what I do. Even if I set note length to 128, it appears as 64... If it can be done somehow, anyway, I think it would be much practical to have these basic notation resources available in the palette with their corresponding actions.
Yes, if you open the MIDI Editor actions windows there are options for display quantization and minimum note length. Make sure these options are set:
Notation: Set display quantize to 1/64
Notation: Set minimum note length to half of display quantization
... and you'll see 1/128th notes and rests (and be able to write them with snap set to 1/128 or less (or off)).
I agree that the options should be more open, in terms of being able to apply them per track and per section of track, per clef and even per note. Or similar. But they live in the actions window in this form at the moment.
It is possible to draw 1/128 notes now. Doing so does show up a couple of bugs with beamed notes, though, that we'll fix.
Probably the grid dropdown should not show any divisions smaller than the current display quantization. We can add an option for the minimum note length to be 1/4 of the display quantization, which will help with pieces like the Beethoven.
We'll need to think about ways to make the quantization more flexible without making it overly complex.
Here's the first half of the Beethoven measure. It's certainly not readable, because of the grid vs musical spacing, and I had to cut the measure in half to make it work at all.
But, it is possible to represent the music, and readability improvements will come with time. The rest, as they say, is an implementation detail
I'm not so sure this is necessary, because as it is the visual beaming and metronome will correlate.
It's only in the cases Kerry was mentioning of that the metronome and beaming may need to be de-correlated. How important is that, and is it important enough to warrant another layer of complexity over the system?
I also think it would be helpful if the beaming pattern could be divorced from the metronome pattern. Instead, the beaming pattern could be implemented similar to the key signature, as a setting that can differ among tracks, and that can be specified for each track individually. (And that can of course be changed at the beginning of any measure.)
If the beaming pattern is track-specific, it would allow easy and readable notation of various syncopations and polyrhythms. For example, users could notate a 3+3+2 pattern in a rhythm guitar track, together with a 2+2+2+2 pattern in the drum tracks.
Last edited by juliansader; 03-02-2016 at 08:13 AM.
Thank you both, Snooks and Schwa, for the feedback! Now I see what you mean.
Some things about these topics :
- Couldn´t grid, note length and display quantization have all possible values from 1/256 to 8 available both on dropdowns and actions? There are some consistency issues, i.e. : the grid dropdown only shows up to 128, but you can set it to 256 via action. If I set note lengths to grid (with 256), the maximum value seems to be 128, though. As Schwa says, a 1/4 of display quantization option for note lengths would probably solve this, but all of this still seems to be unncessary complex to achieve, am I wrong?
- Another consistency issue : while 4 is a valid value both on grid and note length dropdowns, double whole note (breve) seems to be the maximum value available, if I am not missing something... Again, wouldn´t it be simpler to have all values available in all categories?
Besides, is it now possible to write tuplets with odd numerators such as 7 or 9 (as found in Beethoven´s examples)? If not, custom tuplets would come to the rescue, I think... - for example, many fast passages from Chopin or Liszt have numerators such as 21 and such -.
Summarizing, if we have all possible values clearly available in all categories (including dynamics, as I said above), I think it would bring much more flexibility without adding unnecesary layers of complexity; I mean, you have all options at hand... With the current way, you have to calculate with the display quantization for certain values to appear on the score (while some rather basic ones cannot be reproduced at all), and I personally don´t see it as an easy approach.
Last edited by Soli Deo Gloria; 03-02-2016 at 08:26 AM.
a 1/4 of display quantization option for note lengths would probably solve this, but all of this still seems to be unncessary complex to achieve, am I wrong?
There are some complexities. For example, suppose you have display quantization set to 1/32, but want to enter a 128th note. It's easy enough to support this, but what then happens to a (presumably live-played) note that is 3/128 long? Should it be notated as a dotted 64th (or tied 64th+128th if it crosses the beat)?
Maybe a compromise solution would be to support arbitrarily tiny notes regardless of the display quantization, but do not tie or dot these notes unless they are longer than the display quantization setting. So with display quantization set to 1/32, you can enter any tiny note like 128th, 64th, etc, but not a dotted 64th note or dotted anything smaller than 1/32. Once the note is longer than 1/32 it can be dotted or tied.
Sometimes, the quote feature of this forum doesn´t seem to work (as now), so I´ll quote you manually : "Should it be notated as a dotted 64th (or tied 64th+128th if it crosses the beat)?"
I´d have to try out the compromise solution in Reaper itself to give a solid opinion, but dotted 64th seems to me a little bit more convenient, if I have to give a quick answer - but I could probably be wrong -. The difficulties arise with the topic of display quantization, I think, because of being writing in a DAW environment. Maybe an option for different display quantizations to be applied on a global/selection/measure basis could help to decide which is better on each case?
Another issue : say you have a fast scale with 256th notes and display quantization is set to 64...what do you do with 256th notes? You show them as a chord in a 64th note? You just show the first as a 64th one? You hide them all? And we´re talking about small values, but extremely long ones also present a good deal of difficulties.
And if this wasn´t enough, note overlaps are used with many instruments to play not only legatos but also glissandi. With this last case, the extension of the overlap defines the effect of glissandi, so, you need many times considerable overlaps to achieve what you want. How do you deal with that in the notation editor? Again, maybe display quantization on a selection basis would help in this regard...
Thinking about it, maybe display quantization could even be applied on a note basis (selecting it in notation or piano roll view). So, for example, you could just quantize overlapped notes in the score that play legato or glissandi phrases, but leave any other value available for notation... If you select, i.e., a single 256th note and you set it to display quantize value 64, the previous note would simply extend its length to occupy its place (allright, I know this opens 1000 cans of worms, but it´s just an sketched idea). Indicators on the staves for this functionality should be clear enough to allow recognizing quantized notes/measures/passages at first glance...
I mean, there should be a way to combine flexibility to organize the score presentation with a comprehensive availability of basic notation resources.
Last edited by Soli Deo Gloria; 03-02-2016 at 09:21 AM.
It's only in the cases Kerry was mentioning of that the metronome and beaming may need to be de-correlated. How important is that, and is it important enough to warrant another layer of complexity over the system?
Yeah, these are going to be the questions to be wrestled with.
I'd suggest that as the beaming it produces under the current schema is not standard (in current practice, sixteenth notes generally shouldn't be beamed across beats in 4/4 time) we should probably think about it the other way around - it's got to first produce standard behaviour by default and special, non-standard cases should be handled separately as time and resources permit. This is probably going to have to involve allowing the metronome to be decoupled from the beaming as there doesn't seem to be a way to reconcile desired metronome behaviour in 4/4 (ONE-two-three-four) with desired beaming behaviour (1d&a 2d&a 3d&a 4d&a). This is much less a specialized case for power users like the proper display of 256ths and much more a daily use question for the vast bulk of potential score users (http://www.musictheory.net/lessons/11).
There are some complexities. For example, suppose you have display quantization set to 1/32, but want to enter a 128th note.
I understand wanting to preserve the underlying MIDI as much as possible, but I think putting the questions in the context of a variable display quantize eliminates a bunch of what ifs and other recursive thought patterns. So global/track just equals best fit and should be expected to change stuff here and there.
In that example, allow drawing a 1/128th note, but have it displayed as a 1/32. If you want 1/128th notes then change the display quantize setting. Remembering that for live played stuff 1/128th will probably push a bunch of other notes around. Also when playing with pedals, a 1/128th length could mean a note that should be written as pretty much any other length.
Re overlaps and display quantize, "Product C" has variable quantize settings that are Notes/Rests and the following on/off settings Syncopation/No overlap/16th subgroups/Consolidate Rests. So you can put different rules in all the way through something, or just for the odd bit.
This is probably going to have to involve allowing the metronome to be decoupled from the beaming as there doesn't seem to be a way to reconcile desired metronome behaviour in 4/4 (ONE-two-three-four) with desired beaming behaviour (1d&a 2d&a 3d&a 4d&a).
That's what I'm thinking too. There were a couple of people who hailed the idea as brilliant, but in retrospect I think that it may need to be 'decoupled' as you say.
Adding more tokens or keys into the metronome system to operate on beaming really doesn't seem a good way to go. Although I'd love to be proven wrong
I think we're back to the current "working view" with the excellent MIDI note overlay, proportional note-spacing, etc, and the to come "presentation view" with conventional spacing, where you get to put in your title, etc, and pdf it, print it, whatever...
Put it in as best we can live with it and accept some compromises based on the above?
Small point... assigning notes to a specific clef could do with a single switch clef action being added that would work with notes in either clef going in either direction.
Put it in as best we can live with it and accept some compromises based on the above?
My own feeling, and I'd guess probably Schwa's too, is I'd rather have it be right and feature-incomplete rather than generate improper notation. Proper beaming is pretty core; first and foremost, correct in its core functions, and we can let features evolve after that. My $.02.
I hate that my first post on the forum is a bug report, but here goes:
It appears that the Key Signature Meta Data in the version 5.20pre14 MIDI export is incorrect.
The File > Export MIDI option was used to export with Entire Project, All, Multitrack MIDI file, and Embed tempo map enabled. The project contains a total of 17 MIDI tracks which were entered using the new Notation view. 16 of the tracks contain Key Signature assignments.
Importing the file into Sonar resulted in the first note of each track with a Key Signature containing a zero velocity and a zero duration. Loading the export into MuseScore resulted in none of the original Key Signatures being displayed
I viewed the file using a Hex editor and determined that the Key Signature Meta data was in the form:
FF 59 03 02 sf mi (sf = # of sharps or flats, mi = major or minor key)
Example: FF 59 03 02 01 00
The MIDI specification states that the data should be in the form:
FF 59 02 sf mi
I used the Hex editor to remove the "03" from each Key Signature event and reduced the MTrk Header length data by one byte for each track. The edited file now loads correctly in Sonar. In addition, I loaded the edited file into MuseScore and the Key Signatures displayed correctly for all tracks.
The original MIDI file export and the edited version are attached.
I want to add that IMHO the work done so far in the Notation view is an outstanding accomplishment and highly appreciated.
Thanks,
Ron
Last edited by SquireBum; 03-04-2016 at 11:09 AM.
Reason: changed spec format and added kudos
I think we're back to the current "working view" with the excellent MIDI note overlay, proportional note-spacing, etc, and the to come "presentation view" with conventional spacing, where you get to put in your title, etc, and pdf it, print it, whatever...
>
Agreed. Let's get the working with midi as notation thing working first. Printing was reported as coming later. The important part now imo is to be able to do something as simple as a tuplet with confidence that it will work - and even such a thing is not yet bug free. You could get all the performance notes in the world in there, but if you can't input notes properly then what's the point?
I hate that my first post on the forum is a bug report, but here goes:
It appears that the Key Signature Meta Data in the version 5.20pre14 MIDI export is incorrect.
The File > Export MIDI option was used to export with Entire Project, All, Multitrack MIDI file, and Embed tempo map enabled. The project contains a total of 17 MIDI tracks which were entered using the new Notation view. 16 of the tracks contain Key Signature assignments.
Importing the file into Sonar resulted in the first note of each track with a Key Signature containing a zero velocity and a zero duration. Loading the export into MuseScore resulted in none of the original Key Signatures being displayed
I viewed the file using a Hex editor and determined that the Key Signature Meta data was in the form:
FF 59 03 02 sf mi (sf = # of sharps or flats, mi = major or minor key)
Example: FF 59 03 02 01 00
The MIDI specification states that the data should be in the form:
FF 59 02 sf mi
I used the Hex editor to remove the "03" from each Key Signature event and reduced the MTrk Header length data by one byte for each track. The edited file now loads correctly in Sonar. In addition, I loaded the edited file into MuseScore and the Key Signatures displayed correctly for all tracks.
The original MIDI file export and the edited version are attached.
I want to add that IMHO the work done so far in the Notation view is an outstanding accomplishment and highly appreciated.
Agreed. Let's get the working with midi as notation thing working first. Printing was reported as coming later. The important part now imo is to be able to do something as simple as a tuplet with confidence that it will work - and even such a thing is not yet bug free. You could get all the performance notes in the world in there, but if you can't input notes properly then what's the point?
As I said before - I'd rather have it be right and feature-incomplete, and "right" definitely includes this!
The original MIDI file export and the edited version are attached.
I want to add that IMHO the work done so far in the Notation view is an outstanding accomplishment and highly appreciated.
Thanks,
Ron
Great detective work - thanks! Yeah - the Notation Editor is a pretty stunning achievement already and I have a feeling great things are ahead. major kudos to the devs - particularly Schwa - for making it a reality.
I'm more than happy to have some options that are not available in other programs that may have tiny quirks here and there. they can always be improved later. options are awesome.
I tried new Reaper notation. I must say, I like how add and working with notes.
I have some questions and ideas:
1. Will be there cleff change? I know there is possible to change cleff, but I want change clef for example in bar 2. and bar 10 go back in to original clef.
2. I like there are articulations, dynamic signs and legato. Will be this signs able to change midi notes in future? For example staccato change note in to half duration, legato add more duration to note and marcato add little more velocity, dynamics to midi cc and everything will be customizable. Idealy through rules.
3. Zoom is strange, If I have 4 midi tracks displayed as one staff for each track (treble, treble, treble and bass), in some point, I can not zoom verticaly, only horizntal. And if I zoom horizontal it zoom sometimes in both direction.
4. Please, allow display notes for all channels, if midi channel 2 - 16 is selected.
5. Maybe some options to not move notes by semitones in notationn view, but by notation grid or key. For example if I have C key, I can move note by mouse only to notes C-D-E-F-G-A-B-C... and with hold some shortcut key, I can move through all # (C#, D#, etc..) or b (Cb, Db ...) notes.
I am sorry if there was some questions or ideas before. Topic have lots of pages and I dont read all.
I am sorry if there was some questions or ideas before. Topic have lots of pages and I dont read all.
I think you should read through them all you will find answers to all your questions and you will see how the notation editor is progressing - yes it takes time to read through but not as much time as you think, you'll soon see where you can skip a bunch of posts that you're not interested in.
The very first page of this thread has a list of almost all the feature requests so far.
__________________ http://librewave.com - Freedom respecting instruments and effects http://xtant-audio.com/ - Purveyor of fine sample libraries (and Kontakt scripting tutorials)
-when only entering the high voice or low voice, no rests are displayed for the low voice or high voice. Default behavior would be, show rests for the low voice when entering only the high voice and vice versa, also if, what brings me to the next point, we are using 4 voices. Hiding the low voice rests should be optional.
-when entering high voice the first half bar, then low voice the second half bar as in the pic attached, high voice got no rest but this must be.
about 4 voices: as stated before, the only logical way to implement notation properly is having 4 voices per staff, bass,tenor,alto and sopran. Should be not too complicated once the implementation of the high and low voices is getting stable, but it is essential to us composers.
about staff layout: currently the staff spacing is not beeing adjusted when entering low or high notes above the system, alot of collison is happening here.
another tiny feature request: different note heads, like triangle and cross but also small note heads would be very interesting though it is not that essential at the moment.
as always thank you for the works you've done, looking forward what's coming next
Bass clef notes not showing
(and so is the hiding of 8va notes I reported in pre13a)
Linear Mode
