Notation pre-release thread (part 2)

[ijijn]

Originally Posted by EvilDragon

Yes, pedal markings are a must (both variants).

Regarding half-damping, I'd leave that to piano roll CC lanes, honestly.

In fact, I am not aware how is half-damping even handled in, say, Sibelius, or Finale?

They handle it appallingly.

I don't think they have anything available as standard, which is a specific example of the general problems experienced when trying to make recordings using (primarily) notation software.

I hear you regarding the CC lane, and that's certainly a useful place to go, but I do think fractional pedalling (if only on, off and half) should at least be considered for the notation view, if not for immediate implementation then for how it could be done later without breaking the system.

Here's what I imagine for tweaking the pedal values...

• double-click on the pedal ^ junction
• a box appears with two important values: minimum and maximum pedal values
  • the default is 0 and 127 for a full pedal change
  • you could specify 64 and 64 for a simple half pedal*, or perhaps
  • 16 and 80 for a custom result: a small amount of bleed from the previous pedal and a moderate amount of sustain for the ongoing pedal

As an optional extra, Reaper could display a small fractional 1/2 over the ^ whenever half pedalling (64|64) is active. That would give the others a wake-up call.

What I find especially nice about this is that it cleanly represents the quasi-binary off/on triggering nature of the pedal, whereas in my experience CC lanes are typically best for more continuous ebb-and-flow type changes.

* a couple of simple presets would be helpful

[juliansader]

[The following was getting a bit off-topic in the "Notation editor and special MIDI handling" thread, so I moved it here:]

Originally Posted by kerryg

I'm excited about the power these ideas could unleash, but I also want to inject a note of caution. The composers I've worked for would give the notation editor an initial five to ten minutes. If there's frustration at doing simple things they'll abandon it, and reaper, and not take another look for years - that's just how it is (can you tell I've seen this before with other software?). So these extraordinary abilities - huge channelization options, for example - *must* remain transparent; invisible until invoked.
...
So be careful - this stuff has to live "under the hood" by default so composers don't eg wind up having parts jump to different staves or voices and freak out and not know how to fix it.

I agree. I cannot speak for other users, but since I am personally more interested in sequencing workflow than in music publishing, I would prefer the notation view to be simple, straightforward, and closely corresponding to the layout and appearance of my arrange view and piano roll.

Most users use colors, folders and separator tracks to organize the arrange view. To what extent can this be carried over to the notation view, and would it be helpful?

- Colored notes (as in the piano roll) have already often been requested. It will help to orientate the user, especially when faced with a long list of similar-looking staves. Perhaps we can go even further and color the clefs, key signature and time signature with the track colors?

- Can separator tracks be depicted in the notation view? Perhaps some kind of horizontal colored line across the notation view?

Originally Posted by kerryg

One further bit of input: please avoid the use of braces or brackets to group staves by tracks; these symbols are reserved for the visual grouping of parts on a score. Their optimal use may - or may not - correspond to the optimal layout of MIDI tracks.

Fortunately, since we are not working with traditional notation on paper, we can use any other kind of (colored) symbol/line/squiggle that REAPER users would find easy to see and and easy to interpret.

[lolilol1975]

Originally Posted by kerryg

Exactly. I'll be switching all my class assignments (abt 100 students/year) from Musescore to Reaper as soon as the notation editor is in stable release. Won't take too many teachers doing that to make this a game changer in terms of exposing a new pool of potential licensees.

Warning ! Right now it's an advanced notation editor to enter notes only, *not* a full score editor.
And that's the problem. I can already see people bitching that this and this is missing because what they now expect, as you are doing right now, is a full score editor.
As you said yourself, the composers I've seen are not interested in a notation editor, they use full score editors or merely MIDI in DAWs, then export the MIDI to Sibelius/Finale. Not halfway, because they'll have to do the editing again in Sibelius.

[kerryg]

Originally Posted by lolilol1975

Warning ! Right now it's an advanced notation editor to enter notes only, *not* a full score editor.
And that's the problem. I can already see people bitching that this and this is missing because what they now expect, as you are doing right now, is a full score editor.
As you said yourself, the composers I've seen are not interested in a notation editor, they use full score editors or merely MIDI in DAWs, then export the MIDI to Sibelius/Finale. Not halfway, because they'll have to do the editing again in Sibelius.

I think the distinction between "notation editor" and "score editor" is arbitrary and has little relationship to the reality here.

The reality is that just as in every other feature in Reaper we will download prereleases, discuss them here in the prerelease forum, and propose bug fixes and tweaks and new features ranging from the trivial to the "blue sky". Schwa will assess the requests for general usefulness and sensibility vs available coding resources, and then he will either say "that's a lot of work for something only a tiny minority would use" or "that seems big but it's actually pretty easy to do", and then he will build what he builds. And then we'll propose more features; lather, rinse, repeat. The idea that a developer might say "oh my, I can't include that feature - it will only take me half an hour, but that's really only for full-featured score editors" would be ludicrous.

Afterwards folks are free to call it a notation editor or a score editor or, quite frankly, a turkey sandwich on sourdough for all I care. What it will in fact be is merely the sum total of that dynamic process and those decisions.

[juliansader]

Feature request: A notation display version of "Set note ends to start of next note".

There are two related problems that sometimes clutter up the notation display:
- When notes overlap (as they commonly do when sequencing legato phrases), the overlapping part is displayed.
- When the MIDI note is shorter than the intended 'notation note' (for example if the note is staccato or muted), there are often extraneous rests that cannot be removed by the global quantization settings.

I think these problems can both be solved by a notation display version of the "Set note ends to start of next note" Action.
- It will probably work best on a per-voice level.
- Also useful will an Action to toggle this 'legato' display.

Another request: A "Toggle display of hidden notes" Action, in addition to the existing "Unhide all notes". If a user has spent a lot of time hiding notes, the toggle will allow the user to temporarily see the hidden notes, without undoing all the work by "Unhide all notes".

[ijijn]

Originally Posted by juliansader

Feature request: A notation display version of "Set note ends to start of next note".

There are two related problems that sometimes clutter up the notation display:
- When notes overlap (as they commonly do when sequencing legato phrases), the overlapping part is displayed.
- When the MIDI note is shorter than the intended 'notation note' (for example if the note is staccato or muted), there are often extraneous rests that cannot be removed by the global quantization settings.

I think these problems can both be solved by a notation display version of the "Set note ends to start of next note" Action.
- It will probably work best on a per-voice level.
- Also useful will an Action to toggle this 'legato' display.

Another request: A "Toggle display of hidden notes" Action, in addition to the existing "Unhide all notes". If a user has spent a lot of time hiding notes, the toggle will allow the user to temporarily see the hidden notes, without undoing all the work by "Unhide all notes".

This all sounds good to me.

The first idea is great for tidying up scores that have overlaps and rests, especially imported midi or live dumps. I think that being able to do either or both would be ideal, because sometimes you would only want half of this functionality: extending or shrinking notes. Per voice makes sense to me. And I'm all for a destructive vs non-destructive way of doing this too: changing the midi directly or simply altering the view based on a toggle, depending on what you want.

Regarding hidden notes, Sibelius typically displays "hidden" content (when requested) in a faded grey, so you can still tell it's effectively hidden even when you "reveal" it. As you say, a "show hidden" feature helps to keep such events remembered as hidden (so you don't lose your work) but available to display when you want them.

[Kite]

There's a TON of feature requests, both here and in the "Notation editor and special MIDI handling" thread, and you can only ask so much of our wonderful devs.

So I propose a different, "open ended" approach, taking advantage or Reaper's programming languages. I haven't worked out all the details, just brainstorming here.

When a user adds a custom accidental or staff symbol, all Reaper does is insert a text event into the midi stream. What's the point of that, you ask? So that the community could create a JSFX script to do something when that text event is encountered.

A text event can be for a single note, for a single staff, or for a staff system (treble clef and bass clef).

For example, putting the letter "f" (forte) on the first staff adds this text event to the midi: "staff 1 f". Then someone can write a custom JSFX which upon receiving this text message, bumps up all the midi velocities, or something. Putting the crescendo symbol "<" on the 2nd staff makes a text message "staff 2 <" (or perhaps "staff 2 crescendo") which a JSFX might read and then adjust the volume CC.

Another example, attaching an accidental in the form of the letter "g" to D above middle C in the notation editor adds a text event: "note 62 g" where 62 is the midi note number. The companion JSFX then changes this note somehow. It could tune it up or down a few cents, making us microtonal folks very happy.

This could work for staccato marks, accent marks, etc. Also instrument-specific stuff like piano pedal markings, guitar hammer-ons, or fingering indicators. It would NOT work for tempo changes like a fermata, because a JSFX can't change the playback speed, AFAIK.

Some notations might produce 2 text events, like "slur start" and "slur end".

So all that's needed from the devs is a way to overlay text onto either a note, a staff, or a staff system, and a way to edit or delete that text.

This takes a lot of the burden off the devs and puts it on the community. If we want a feature to be added to the notation editor, we can create it ourselves!

*BUT* there's a problem, it doesn't seem that JSFX can read midi text events. Hopefully it would be easy to add this ability. Or perhaps EEL or LUA could do this? Otherwise we could use sysexes or NRPNs or something.

Another problem is how the JSFX would know which staff a note is on.

Thoughts?

[ijijn]

Originally Posted by Kite

There's a TON of feature requests, both here and in the "Notation editor and special MIDI handling" thread, and you can only ask so much of our wonderful devs.

So I propose a different, "open ended" approach, taking advantage or Reaper's programming languages. I haven't worked out all the details, just brainstorming here.

When a user adds a custom accidental or staff symbol, all Reaper does is insert a text event into the midi stream. What's the point of that, you ask? So that the community could create a JSFX script to do something when that text event is encountered.

A text event can be for a single note, for a single staff, or for a staff system (treble clef and bass clef).

For example, putting the letter "f" (forte) on the first staff adds this text event to the midi: "staff 1 f". Then someone can write a custom JSFX which upon receiving this text message, bumps up all the midi velocities, or something. Putting the crescendo symbol "<" on the 2nd staff makes a text message "staff 2 <" (or perhaps "staff 2 crescendo") which a JSFX might read and then adjust the volume CC.

Another example, attaching an accidental in the form of the letter "g" to D above middle C in the notation editor adds a text event: "note 62 g" where 62 is the midi note number. The companion JSFX then changes this note somehow. It could tune it up or down a few cents, making us microtonal folks very happy.

This could work for staccato marks, accent marks, etc. Also instrument-specific stuff like piano pedal markings, guitar hammer-ons, or fingering indicators. It would NOT work for tempo changes like a fermata, because a JSFX can't change the playback speed, AFAIK.

Some notations might produce 2 text events, like "slur start" and "slur end".

So all that's needed from the devs is a way to overlay text onto either a note, a staff, or a staff system, and a way to edit or delete that text.

This takes a lot of the burden off the devs and puts it on the community. If we want a feature to be added to the notation editor, we can create it ourselves!

*BUT* there's a problem, it doesn't seem that JSFX can read midi text events. Hopefully it would be easy to add this ability. Or perhaps EEL or LUA could do this? Otherwise we could use sysexes or NRPNs or something.

Another problem is how the JSFX would know which staff a note is on.

Thoughts?

Hi Kite. It appears we've been thinking along very similar lines. Have a look at this thread where I've been hashing out some related ideas. The more input the merrier!

We actually do have such text events already, and JSFX can read them just fine; just use midirecv_str or midirecv_buf to get access to those strings. If you'd like to examine the resulting text events, just look in the event list view: they're very usable as it stands. Check it out!

I'm already using voices and note head types to separate polyphony, as well as the dynamics to help shape note envelopes, although we're still waiting for channel/voice-aware text events that aren't tied to a specific note, and for a per-note snapping option for events that aren't primarily note-centric.

As for a tempo change or fermata, you could certainly fake it by delaying events, but as you say, I don't think we can actually do that while keeping the bar/beat structure intact. That would be pretty neat to have at some point though!

[JesterMusician]

Originally Posted by kerryg

The idea that a developer might say "oh my, I can't include that feature - it will only take me half an hour, but that's really only for full-featured score editors" would be ludicrous.

No, it really isn't. As a developer myself, I can attest to the existence of feature creep, which causes projects to go overtime or overbudget, or simply fail. Including features that are out of scope not only sets precedence, but also sets stakeholders' expectations. If they weren't planned very well, they may turn out to be buggy or difficult to maintain, or prompt for yet more features that definitely should not be included.

Separation of Concerns (SoC) is a design principle that helps prevent this. REAPER should do certain things very well, but others not. Using the mission statement as a guide, the development team can make executive decisions about each feature's inclusion. Unless REAPER intends to replace MuseScore as a notation program, certain features will be excluded (even if they seem trivial to implement).

[reddiesel41264]

Originally Posted by JesterMusician

No, it really isn't. As a developer myself, I can attest to the existence of feature creep, which causes projects to go overtime or overbudget, or simply fail. Including features that are out of scope not only sets precedence, but also sets stakeholders' expectations. If they weren't planned very well, they may turn out to be buggy or difficult to maintain, or prompt for yet more features that definitely should not be included.

I think Reaper is 99% feature creep

[paaltio]

Not sure if this was mentioned yet, can't find it with search at least. Just noticed that stretching items doesn't update in notation view like it does in the piano roll.

I know technically it's a playback rate change, so one could argue it's a level of abstraction above the contents. But since the piano roll already updates to correspond to the playback result, I think the notation should have the same result.

[kerryg]

Originally Posted by JesterMusician

No, it really isn't. As a developer myself, I can attest to the existence of feature creep, which causes projects to go overtime or overbudget, or simply fail. Including features that are out of scope not only sets precedence, but also sets stakeholders' expectations. If they weren't planned very well, they may turn out to be buggy or difficult to maintain, or prompt for yet more features that definitely should not be included.

Separation of Concerns (SoC) is a design principle that helps prevent this. REAPER should do certain things very well, but others not. Using the mission statement as a guide, the development team can make executive decisions about each feature's inclusion. Unless REAPER intends to replace MuseScore as a notation program, certain features will be excluded (even if they seem trivial to implement).

All quite correct observations but their applicability here would rest on assumptions that I don't feel are particularly valid.

The first would be the assumption that the overall scope of Reaper is already centrally predefined and limited; in fact Reaper's strength is its dynamic between the developers and community, and the "mission statement" here has continually been updated by that. Reaper now includes dozens of features, developed in back-and-forth dialogue with the community, that are far outside the scope of most other DAWs, like advanced scripting and skinning. Many people here argued strenuously for years that the very inclusion of notation at all was outside of the scope of a DAW (obviously people whose views of DAWs was limited to their own subset of experience with them since I've been using DAWs with notation like Logic since the early 90s). Reaper's scope isn't the exclusive purview of any particular group here to define. The vast bulk of users would probably agree that a coffee making attachment or the ability to turn a score into a dressmaking pattern would be out of scope (OK, we might get _some_ traction with the coffee maker), but any feature in a DAW that directly eases a composer's workflow is certainly arguable as fair game.

The second - and we're now talking about scope within the specific context of adding notation to a DAW, now a settled issue here - is that some have been arguing that our scope within that task should limit itself to "notation editor" versus "score editor". I don't think that's particularly well-thought out - it's based on what really boils down to categorical thinking based on the behavior of existing software on the market. For starters, at a glance this year's offerings might seem to break down to a choice (to take the polar extremes) between notation-only apps (MuseScore, Sibelius) or DAWs with notation added (one of the worst examples being ProTools, whose notation view is a severely dumbed down subset of Sibelius with few amenities).

But even within the category of "DAW with notation" that's already just an imaginary distinction. Let's take one existing direct competitor in our niche - Logic. The composer I study with showed us that as of its most recent score upgrade he was finally able to open a previous orchestral piece he'd written in Logic and print out an acceptable score and parts for the Vancouver Symphony Orchestra directly from it (I will attach the orchestra's specific submission guidelines separately; I want us to study them for feasibility and eventually hit them). The last time it was performed he'd had to export to Sibelius to get submittable output. So which is Logic under these categories? A "score editor" that couldn't print performable scores for the last twenty years? A "notation editor" that now can? Did that arbitrary distinction play any role at all in their decision making process? What does it imply for this way of thinking about those imaginary distinctions that I've been successfully printing out parts for smaller ensembles from Logic since it was Notator/Creator running on an Atari 1040 in the 1980s?

If folks want to talk about useful distinctions in focusing our aims to avoid "mission creep" here I'd argue there's a more useful functional distinction to be made: between "useful for print and subsequent performance" and "acceptable for publication". The former needs musically correct display and a small subset of formatting tools, sufficient to allow clear and correct parts to be printed, and would be used daily by people like me; the latter swerves into desktop publishing and a lot of nitpicky details about visual placement and advanced typography, and would only be needed infrequently and then only by a tiny subset of composers submitting pieces for direct publication without the intervention of a copyist or musical typesetter. I'd draw the line for my own expectations there instead - between "clean, legible printing quality" and "publishing quality", which we'll have MusicXML export to facilitate sending to Sibelius or a typesetter or copyist. That at least would be founded on a useful functional distinction that divided one task of coding from a second task containing a lot of unrelated visual elements (and one that would actually benefit few) rather than simply being founded on assumptions based on "what's out there now" (and actually getting that completely wrong too).

[G-Sun]

Originally Posted by JesterMusician

Separation of Concerns (SoC) is a design principle that helps prevent this. REAPER should do certain things very well, but others not.

Originally Posted by kerryg

I'd argue there's a more useful distinction to be made: between "useful for print and subsequent performance" and "acceptable for publication".

A very good discussion.
First, I was thinking, just basic notation (view, simple edit and export),
but then I see the scope of what schwa is doing,
and I don't want to limit the result.

I'd agree with kerryg with his line of SoC,
if schwa is willing to take it that far (and that's what it seems like )

btw: I've been using Notion quite a bit.
It's a notation tool that aims to go a long way in the daw-direction,
for giving the users good audio from their score.
Notable is vst, cc, velocity and rewire-support,
and some integration of score-expression to audio (like harpins).
However, by aiming for both, it gets mediocre at both.
And, in that sense I agree with JesterMusician that Cockos need to stay focused to what's important,
and what's not.

[kerryg]

Here for reference are the Major Orchestra Librarians' Association guidelines for scores submitted for orchestral performance: http://mola-inc.org/article/Music-Pr...tral-Music.pdf

Surprisingly very few of these would require any change in Reaper at all - in terms of satisfying the specific guidelines you could practically print a compliant score from the existing beta. Many guidelines are just things like specifications of type and weight of the paper, the use of "fold out" pages etc. A few would require minimal tweaks - specified staff sizes (around 7mm in scores, 8.5mm in parts with a bit of flexibility); the addition of a cover page with title and name of composer; the ability to add a page or two explaining anything unusual in the score's notation; a couple of pagination features, a couple of other details like that. It's not at all a hard target to aspire to, and once we've got that we've got a defensible place to rest.

What's most surprising about these guidelines is (once we get print ability) how close the prerelease version is to satisfying them already. Naturally the notation itself has to be nailed first, but we're doing that anyway. To decide to stop just shy of nailing these guidelines because one has some fixed idea about imaginary categories ("but that would make it a score editor!") would be crazy.

[michael diemer]

[QUOTE=kerryg;1659854

"...The vast bulk of users would probably agree that a coffee making attachment or the ability to turn a score into a dressmaking pattern would be out of scope (OK, we might get _some_ traction with the coffee maker), but any feature in a DAW that directly eases a composer's workflow is certainly arguable as fair game."

I really like this idea of a coffee maker. I can see it now: MR REAPER. You could hire John Williams to play the role of Joe DiMaggio. Star Wars music playing in the background. A work station cluttered with coffee cups, a score with mug stains on it. Mr. Williams looks up and says: "I used to get up five times a night to go to the kitchen to make coffee. With Mr Reaper, I can finish the most demanding projects on time." (Of course, you might need to package it with something called "Mr John." Although Mr Williams might object to calling it that.

[juliansader]

A few thoughts regarding key signatures:

1) Bug report: The key signatures for harmonic and melodic minor appear to be faulty. They are correct when the root is C or E, but most other roots give incorrect key sigs. For example, the A (root) harmonic minor key sig should simply be G#, but is given as Ab Bbb. The a melodic minor key sig is given as Bbb Ab Gb.

2) The key signature type that is currently named "pentatonic" could perhaps more accurately be named "major pentatonic".

3) Feature request: More key signatures to choose from, particularly for exotic scales

The existing range of key signatures is already wonderfully diverse. But there are some exotic scales such as the Hungarian Minor or Byzantine that are lacking.

Easy option, but perhaps less elegant: Simply add some additional key signatures to the existing list of 'types'.

Difficult option, but perhaps more elegant: A dialog box that allows the user to construct any custom key signature by selecting x, #, natural, b or bb for each scale note (as long as the resulting pitches do not overlap).

[schwa]

Originally Posted by juliansader

The key signatures for harmonic and melodic minor appear to be faulty.

Thanks, will fix. (It's actually notating the correct notes in the key signature, but choosing the wrong direction for the notation, flats instead of sharps in your example.)

Originally Posted by juliansader

Feature request: More key signatures to choose from, particularly for exotic scales

You can create whatever key signatures you want by creating a .ReaScale file. There should be a sample file in your App Data (or Library) REAPER/Data directory that you can use as a template. Attaching here, as well.

[kerryg]

Originally Posted by michael diemer

I really like this idea of a coffee maker. I can see it now: MR REAPER. You could hire John Williams to play the role of Joe DiMaggio. Star Wars music playing in the background. A work station cluttered with coffee cups, a score with mug stains on it. Mr. Williams looks up and says: "I used to get up five times a night to go to the kitchen to make coffee. With Mr Reaper, I can finish the most demanding projects on time." (Of course, you might need to package it with something called "Mr John." Although Mr Williams might object to calling it that.

At his age most folks just get up five times a night to pee. Talk about enhanced workflow.

[michael diemer]

Originally Posted by kerryg

At his age most folks just get up five times a night to pee. Talk about enhanced workflow.

I'm glad someone else found this humorous. I was worried that folks might have thought it was disrespectful to Mr Williams, the Emperor of Film Music.

[ReaDim]

- "CC selection follows note selection" - does it work in notation editor now?
- How to link staves with a Bracket or a Brace? is it possible?
Thanks!

[memyselfandus]

I wonder how many long standing feature requests for Sibelius are already implemented in reaper not that it's better or anything but it's interesting. For example Copy/Paste Tuplets. Isn't that already in reaper?

A lot of the feature requests here have been around forever and are really wanted by Sibelius users

http://sibelius.ideascale.com


These were added to Sibelius today

Re-spelling of notes in parts—It's now possible to have the same pitched note have a different accidental in a part versus the score.
Time signatures before repeat lines—By default, time signature changes now appear after the barline, but before repeat barlines.
Slide and move notes and rests—Notes and rests can now be moved horizontally in the score, with new keyboard shortcuts that simplify the process, eliminating time spent cutting and pasting music around staves.


I haven't tried to do this stuff in reaper yet but wouldn't be surprised if it's already possible


This is also a good resource for ideas

Most popular
http://sibelius.ideascale.com

Most recent
http://sibelius.ideascale.com/a/idea...-filter/active

[panicaftermath]

Sorry for the simple question: Where do I find notation? I'm using the latest pre (5.20pre30) and I'm not finding it in any of the default menus or in the action list. Thx.

[hamish]

You need a MIDI item on a track first. Then open in the MIDI editor, then go view > Mode: musical notation

[panicaftermath]

Thanks.

Ambitious undertaking....

[MCCY]

Hey, thanks, it's getting better and better!!!

It is a bit difficult to see the small blue line which shows, where the playing is... This is in principle a GREAT (necessary) feature for pupil, but it would be great, to make it better visible or is there an option to change colour?

[MCCY]

Just remembered, that there is an option for inline editing in Pianoroll editor.

How fantastic that would be, to have INLINE-NOTATION option!?! YEAH!

...

--- doing some more experiments: I often want to copy notes from early measures to later ones. This is difficult, because when I drag to later measures it just changes the pitch. Would be nice to add a shortcut key when holding one can copy in timeline vertical or horizontal direction, so I do not have to dopt zoom to see all measure I like to copy to in a line... Sorry for my bad english, hope it's understandable...

--- Would be great to have an option to identify chords per quarternote/half/..., not to have to select each single chord.

--- What about being able to set the smallest possible rest-length, not only smallest note length which counts for both?

[schwa]

Originally Posted by MCCY

Would be nice to add a shortcut key when holding one can copy in timeline vertical or horizontal direction

"Move note on one axis only" is shift+control+drag by default, you can change this or set a modifier for "move notes horizontally" in preferences/editing behavior mouse modifiers.

... oh, I see what you, mean, in page view you want to drag the notes to rows that are higher or lower on the staff. The early implementations did allow this, but was disorienting and too easy to accidentally move notes to the wrong row if they were already a number of ledger lines off the staff. I'll think about this though.

Originally Posted by MCCY

What about being able to set the smallest possible rest-length, not only smallest note length which counts for both?

MIDI editor view menu/notation view options/display quantization defines the shortest rest length, sort of. At the default settings of 1/16 display quantization and 1/64 minimum note length, the shortest rest will be 1/16, except surrounding very short notes.

[MCCY]

Ah, I see, thanks!

Dragging notes to higher or lower on the staff would be great to be solved!

THANK YOU!!!! This will be wonderfull! I find myself feeling so released, because I need notation everyday for school, but 'had to' use logic audio 5.5 PC all the time for that, because I simply get older and learning curve for me is not so fast anymore... Did not have the motivation to dig deep into another program, but as I use reaper for some years now I'm so motivated to get really deep now, because I now: REAPER is my go-to-program every day, since I even can use it for video-cutting with the pupils!!!!

[juliansader]

Originally Posted by schwa

MIDI editor view menu/notation view options/display quantization defines the shortest rest length, sort of. At the default settings of 1/16 display quantization and 1/64 minimum note length, the shortest rest will be 1/16, except surrounding very short notes.

The FR for a notation version of "Set note ends to start of next note" will hopefully help to minimize the occurrence of unintended short rests between non-legato notes.

BTW, I recently noticed that the existing version of the Action has some problems, and I reported it in the Casa De Nitpicks: http://forum.cockos.com/showthread.php?t=175067.

[MCCY]

Originally Posted by juliansader

The FR for a notation version of "Set note ends to start of next note" will hopefully help to minimize the occurrence of unintended short rests between non-legato notes.

BTW, I recently noticed that the existing version of the Action has some problems, and I reported it in the Casa De Nitpicks: http://forum.cockos.com/showthread.php?t=175067.

In some cases such rests make sense, but such an action would prevent the most serious problem in 'ontheflynotating' as I use it in most cases leading to easyer to read sheets...

Didn't try it so far, sounds great :-)

----

That action sometimes does nothing at all here.
+ would make sense to do it like "Set note ends to start of next note OR START OF NEXT MEASURE" Overlapping notes over measures makes reading more difficult.

+ This should be an option for VISUALISATION!! It may well be, that you want to hear shorter notes, but the notation would show rather a staccato point (which one could add then) than a rest & a short note...

[kerryg]

Originally Posted by MCCY

+ would make sense to do it like "Set note ends to start of next note OR START OF NEXT MEASURE" Overlapping notes over measures makes reading more difficult.

How could you notate the half of popular music that features "pushed" melodies or bass lines? Think of the melody of "Killing Me Softly" and count how many times it lands before the downbeat. Or for salsa, "tumbao" bass lines depend on landing before the bar line and tying over it for their rhythmic drive.

[MCCY]

Originally Posted by kerryg

How could you notate the half of popular music that features "pushed" melodies or bass lines? Think of the melody of "Killing Me Softly" and count how many times it lands before the downbeat. Or for salsa, "tumbao" bass lines depend on landing before the bar line and tying over it for their rhythmic drive.

That's not the point. I'm not talking about quantisation, I'm talking about making notation readable & avoiding too small rests.

If a melody goes beyond measure end (and it indeed goes quite often) you'd allready played it that way (because you want to hear it like that (if you do stepnotating you'd allready write it that way, so in both cases no problem arises), but when you play that melody and the note just releases a 16th before measureend, it makes no sense to have a rest there. If the next note then starts at the 2nd 8th of next measure, would it really make sense to make the length of the note before until the start of thatone (allthough it should not be played as long...?)...

Maybe I'm on the wrong track. Using the old logic audio 5.5 I'm used to a nearly perfect interpretation of what I play on keyboard, but maybe perfect means something else for me :-)

.. I'm just asking for options, to manipulate Scores for better readability. I don't want those options to be there in 1st place.

[kerryg]

Originally Posted by MCCY

That's not the point. I'm not talking about quantisation, I'm talking about making notation readable & avoiding too small rests.

If a melody goes beyond measure end (and it indeed goes quite often) you'd allready played it that way (because you want to hear it like that (if you do stepnotating you'd allready write it that way, so in both cases no problem arises), but when you play that melody and the note just releases a 16th before measureend, it makes no sense to have a rest there. If the next note then starts at the 2nd 8th of next measure, would it really make sense to make the length of the note before until the start of thatone (allthough it should not be played as long...?)...

Maybe I'm on the wrong track. Using the old logic audio 5.5 I'm used to a nearly perfect interpretation of what I play on keyboard, but maybe perfect means something else for me :-)

.. I'm just asking for options, to manipulate Scores for better readability. I don't want those options to be there in 1st place.

I do like the "set note end to start of next note", or as Logic would say, "note force legato", with options "selected/selected" or "selected/any". I used that constantly. Also "remove note overlaps (force monophonic)".

[semiquaver]

agree that a slight separation between notes need not result in a tiny rest.

I think the logic to use is that rests should be some minimum proportion of the length of the preceding and succeeding notes to make sense. ie in a passage of 16th notes a 32nd note rest may be called for. In a passage of quarter notes, never.

[Commala]

I was thinking about the FR I made to give the notation editor a dedicated midi note color map: http://forum.cockos.com/showpost.php...&postcount=255


and it occurred to me that the midi editor allows you to set a default color map that will override the one included in the theme. Perhaps the notation editor could do the same thing, but in parallel, giving it a default override color map exclusive to it.

I thought that extending functionality which is already implemented could be a simpler matter than what I had suggested before, although being able to include a second color map within a theme to do this automatically for the user would still be ideal.

[rluka]

I was browsing through the actions list and decided to build a toolbar for writing notation by using two of the actions in the list.



Before I finish the toolbar, which will be quite large because it would have all twelve notes (So far I only created 4 rows for 4 notes) I would like to know if this is the intended way for this to work or will there be other choices that might be more compact? Or: Is there a more efficient way of doing this right now?



Having music notation in Reaper is first class...THANKS for all the hard work putting this together
Ron L

[reddiesel41264]

Originally Posted by rluka

I was browsing through the actions list and decided to build a toolbar for writing notation by using two of the actions in the list.



Before I finish the toolbar, which will be quite large because it would have all twelve notes (So far I only created 4 rows for 4 notes) I would like to know if this is the intended way for this to work or will there be other choices that might be more compact? Or: Is there a more efficient way of doing this right now?



Having music notation in Reaper is first class...THANKS for all the hard work putting this together
Ron L

You don't need one action for each note for each duration, check out Sibelius or musescore to see some simpler methods. In Sibelius for example you first select a note length using the num pad keys, then you enter your note using the letter key for the note you want. You could create a similar setup with buttons but keyboard entry is a lot faster.

[rluka]

Originally Posted by reddiesel41264

You don't need one action for each note for each duration, check out Sibelius or musescore to see some simpler methods. In Sibelius for example you first select a note length using the num pad keys, then you enter your note using the letter key for the note you want. You could create a similar setup with buttons but keyboard entry is a lot faster.

Can this be done now?

Thanks for the response
Ron L

[memyselfandus]

Originally Posted by Commala

I was thinking about the FR I made to give the notation editor a dedicated midi note color map: http://forum.cockos.com/showpost.php...&postcount=255


and it occurred to me that the midi editor allows you to set a default color map that will override the one included in the theme. Perhaps the notation editor could do the same thing, but in parallel, giving it a default override color map exclusive to it.

I thought that extending functionality which is already implemented could be a simpler matter than what I had suggested before, although being able to include a second color map within a theme to do this automatically for the user would still be ideal.

But color the actual note heads and not a colored square around them.

[ReaDim]

Thanks for all new features in notation editor especially for:
- support percussion clef with one staff line
- context menu for transposing instruments
- custom note heads can be set per-note or per-pitch
- add option to bracket tracks by folder
Notation editor turns into a powerful tool!


FRs and some ideas:

- percussion clef with one staff line takes the same amount of space as with 5 lines. Please let it occupy less space (vertically) for more compact view.

I remind you my old FR with some updates influenced by new feature “add option to bracket tracks by folder” from v5.20pre29:
- Please let the triangle button “folder is compacted/expanded” in the “track list” works as “gather/separate” the content of children tracks into one staff (to display in notation view only).

- An option to link/unlink folder trees in MIDI editor (notation view only) and real track's folder tree in main view. Because now the "option to bracket tracks by folder" is directly related to track routing which sims to be not logical or obvious and are from different worlds. imho. This link is handy for piano roll view - no problems.

- If a folder in notation editor is in compacted states let all the stuff settings of the folder track (clef, transposing, key signature etc) work for this gathered stuff folder even if children tracks have different stuff settings.

- Let an option "bracket tracks by folder" works for staff folder in the same mode as it does for single track (folders inside folders). Using this feature I can bracket two or more stuff folders.

An example:
It would be useful when I use my 12 horns (virtual instruments by Sample Modeling) each horn on a separate track, two staves by 6 horns inside (stuff folders) connected with a bracket (inside one parent folder) divided into 4 voices by 3 horns (two voices in two staves - upper and lower voices). So I have one double stuff which contains 12 fully functional tracks (six times less score space). I can write/edit notes using "target for inserting notes" and write/edit detailed MIDI CC information using piano roll view - very handy and flexible. And also I can expand this stuff folder to view in depth the whole horn section or compact when I do not need this depth.

- Please let the folder track be under the bracket together with children or be not visible as soon as it turns into a folder - by default. May be by choice.

- Let the click on the button "folder is compacted/expanded" in track list do not hide children tracks in the track list area - let all tracks be always visible in track list. Because I want to see witch one track is "target for inserting events" inside an compacted staff folder. Because there is an option "choose which track appears in track list" in the track list. I think it is enough for hiding tracks.

- There are actions “Activate previous/next visible MIDI item”, please create an action “Activate previous/next visible MIDI track”. For I could easily switch between the tracks I edit even if there are many items in one track and also if there are some tracks hidden in notation view (I’m not going to edit them).

P. S. Sorry for my poor English.
I hope this post will be useful
Thank you very much for you effort!

Dmitriy.