Main menu
You are here
Easy articulation
After adding music to a track via MIDI keyboard, the material of course needs editing. Changing the "velocity" of individual notes to give a better shape to phrases is easy, and the result is easily tested.
What is much more difficult, I find, is adjusting the length of notes to produce a convincing legato or articulated effect. Although qtractor has a marvellous array of tools for editing midi tracks, it doesn't seem to have an easy way to to do this.
What I have in mind is a tool which would allow one to select 2 or more notes, and then adjust the end time of each of them (apart from the last) to coincide with the start of the next note, producing a legato effect. Alternatively, one could specify the amount of time there should be between each Note_off event and the following Note_on, to produce different sorts of articulation.
It is quite possible that this facility already exists in qtractor and I have just not managed to find it. But if not, is it perhaps something that could be considered for a future release?
David
re. Easy articulation (3rd impl. w/gap quantization)
Sorry to be awkward, but it isn't the same. The problem with the current implementation is that since the size of each gap, before quantization, is proportional to the time between each pair of notes' NoteOn events, then quantization will only give us equal gaps where the notes are approximately evenly spaced, e.g. all the notes are minims (half-notes).
In a case like the one I mentioned - a 4-beat note followed by 2 or more ½-beat notes, then without quantization we get a first gap which is exactly 8 times the size of the others. So far as I can see, quantization will not alter that significantly, and this is certainly what I find by actually using the tool.
If the percentage applied to the length of a beat, rather than to the length of each individual note, then we would get consistent gaps, which is what we want. Quantization would not then be necessary or useful, so far as I can see.
re. Easy articulation (3rd impl. w/gap quantization)
ok. so we're looking for a 4th implementation perhaps...
let me put it this way: the percentage parameter is replaced by a 3-choice drop-down list with the following items:
1 = Gap => positive gap; similar to <100% but with a fixed gap duration given by the (snap-to-)beat/fraction parameter (formerly the quantize value);
2 = Over(lap) => negative gap; same as of >100% but with a fixed overlap duration (beat/fraction);
deal?
re. Easy articulation (3rd impl. w/gap quantization)
Sounds good to me, if I have understood it correctly. Is the beat/fraction the actual length of the gap/overlap?
For example, if we select notes placed on beats 1, 3 and 4 of a bar, and use this tool with 'gap' and beat/10 selected, then the first 2 notes will finish at 2.9 and 3.9. The final note remains unaltered. Is that correct?
Suppose our notes are not accurately on the beat (mine never are!) If our 2nd note is not exactly on beat 3, but is at position 3.04, where will the first note end? Will it be at 2.94 (which would be correct), or 2.90? If the latter, then it means that the gaps could vary from the requested size by +/- 50%; in other words, some gaps could be 3 times the size of others, which is obviously not what is wanted.
re. Easy articulation (3rd impl. w/gap quantization)
For example, if we select notes placed on beats 1, 3 and 4 of a bar, and use this tool with 'gap' and beat/10 selected, then the first 2 notes will finish at 2.9 and 3.9. The final note remains unaltered. Is that correct?
correct.
the gaps/overlaps will have fixed duration, or fixed length given by the beat/fraction setting.
is it better now?
re. Easy articulation (3rd impl. w/gap quantization)
That definitely sounds right to me! I look forward to testing it out.
Thanks as always.
How about trim(-right)?
Greetings and thank you for this discussion. I have been following it closely, mostly in theory. To say my piece: Like "resize" and its choices, would an operation possibly called "trim" (or trim-right) being able to be used with a parameter in time(seconds)/frames/etc. (possibly also with a lowest threshold, for not making a note very thin or disappear) make sense for the toolbox? On its own or as a legato sub-operation (the difference being only for the last note, for the same selection of notes - the legato last note would not be trimmed right). Long story short, trim-right would move all NoteOff events and a positive value means to shorten the note moving each NoteOff event to the left. Trim left (if necessary) would work on NoteOn events the same way, although its use would be questionable. I think that trimming (right) with a time parameter in seconds is easier to think and reason about, on its own or as a sub-operation of legato.
On fourth thought, to overcome semantics for positive and negative values of a by-name semantically defined operation like trimming (or extending), an operation like "offset" for certain events (NoteOff for sure) could possibly be of value. Or not. Thank you for this discussion, again. To the lurk-mobile!
re. Easy articulation (4th. impl.)
hi, you may have a point here, being english not my mother's tongue, (I do) have some trouble over the correct term to display there...
0 = None = No gap, nor overlap; no trim, nor extend; coincide(nt) or else? (please help me out!:)
1 = Gap <=> Trim ? (ie. David's "positive gap")
2 = Overlap <=> Extend ? ("negative gap")
which one is best?
ps. decided with Normal, Trim and Extend resp. in qtractor >= 0.9.36.14git.730883, please test and tell :)
Hi, Rui. First of all, thank
Hi, Rui. First of all, thank you on behalf of your userbase (or fanbase)! I am sorry for this delay (and the next one), I fell in a rabbit hole. Initially because of not using "git clone --recursive git@github.com:rncbc/qtractor.git" to clone qtractor (the operative token here being "--recursive"), then because of https://github.com/KXStudio/Repository/issues/303 and my having the kxstudio repositories enabled and, hence, `lv2-dev/focal,now 6:1.18.10-1kxstudio2 amd64 [installed]`. I then tried the legato. It works wonderfully, although David's experience and observations are much more important. Regarding some observations, please allow me to get back to you, after I think about it some more (this is the main part of the rabbit hole). As indicated by terminology issues, MIDI editing balances between music composition and graphic design. Anyway, I can gather some observations, for brief or lengthier consideration or even just for reference.
PS. Just for clarification, are the following correct, regarding the legato implementation, or am I missing something?
Mono: Sort notes by "NoteOn time". For each note make "NoteOff time" = "next note's NoteOn time".
Poly: Sort notes by "NoteOn time". For each note make "NoteOff time" = "next note's NoteOn time", only if "next note's NoteOn time" is larger. [Like "Mono" with "No shortening"]
re. legato implementation
hi, the difference between "Mono" and "Poly" modes, is exactly as you say, you're not missing anything!
but perhaps it would be interesting to read a few pages back in comments here, specially the infamous rule 4. which stands for the "Poly" mode and is simply overruled on the "Mono" mode.
cheers
re. legato implementation
After much consideration, these are my thoughts on the matter. I tried to reason about my intuition and interpret David's experience.
In general I would consider the "legato-operation-et-al" not as a single operation to achieve any kind of legato out-of-the-box, but as a toolbox enhancement to assist with legato-related issues. I think I have approached the task more from the side of graphic design, definitely having the music application in mind. In this regard, I would not use "legato" and "mono/poly" as terms (but more about this below). I would use terms that describe what happens (or does not happen) to the boxes that represent notes. Again, these are my views, I believe they provide some insight, but can be safely disregarded. It was a fun intellectual exercise anyway.
In the following, "value-textbox" and "unit-dropdown" are supposed to be exactly like "Duration"'s (or at least the "Time" functionality is provided). All the following operations indirectly set the selected notes' durations (they indeed resize), by defining complementary durations (length of space/gap to insert and length to trim or extend). I therefore believe it makes sense to provide the "Duration"'s choices for these. I find the time in seconds especially important, since in an ADSR envelope the release time (the release being initiated by the NoteOff event) is commonly expressed/measured/felt in seconds. Additionally, what if the release time is bigger than a beat, the highest value currently allowed?
The following textual mockup presents a suggested incremental approach to enhance the "Resize" tab of the "MIDI Tools" towards assisting with legato. The "Resize" tab is definitely perfect for anything assisting with legato. In a dropdown, the first choice would be the default one. In a checkbox, the default state is unchecked.
----
Spacing: value-textbox, unit-dropdown, Right/Left-dropdown [resizing direction - optional if only the right side of each box is considered], "No shortening"-checkbox [mono/poly equivalent - questionable (see below)]
Trim: value-textbox, unit-dropdown, Right/Left-dropdown [trimming side - optional if only right-trimming is considered]
Extend: value-textbox, unit-dropdown, Right/Left-dropdown [extending side - optional if only right-extending is considered]
----
General notes:
Spacing: "Spacing" under the "Resize" category will... resize! A value of zero in the textbox would correspond to the current "normal" legato. Higher values insert equal spaces/gaps. Negative spaces can either be disallowed or silently allowed (I am not 100% sure what I mean here, but I have negative margins in CSS in mind, which somehow work but are not advertized). I try to apply the general design philosophy to make the common case simple and intuitive. Validation by users (David?) is definitely needed. If a user wants legato with extending over the next note (outlier case in my book), they could apply zero space, then deselect the last note and apply "extend" (see below). Or hack their way using a negative space (if allowed).
Trim: Not essential for assisting with legato (if you define spacing correctly, nothing else is needed), but I believe it would be nice to have for the MIDI toolbox, for fine-tuning durations of notes of various lengths.
Extend: If negative spacing is disallowed, this would be the required additional step for the "Mantovani strings" (in my book this would be an additional step for an uncommon case), if I understood David's mention correctly. This would just require deselecting the last note before applying. In general, also nice to have for the toolbox, for fine-tuning durations of various lengths.
As a final remark, the "No shortening"-checkbox (or something equivalent) would not be needed, if we suppose that the user knows what will happen, and just takes care to deselect the notes that would otherwise be affected. (Edit: This is wrong. Deselecting a note that overlaps with the next one (or touches the next one and a non-zero space is now specified, or a smaller space between the two notes already exists than the new space specified), to keep it unaffected before applying a possibly shortening operation, would eventually connect the previous note to the next one. Not the desired outcome.) It is time for me to get out of the rabbit hole, so I will leave that thought be for now.
Terminology issues: Shortening or shrinking? Spacing sounds nice, or not?
These are my two Euro-cents. Rui and David, you have a fuller picture, combined.
re. legato implementation
I think I've said more than enough already. I like the current implementation of the legato/articulation. For me it works well. Whether a newcomer to qtractor would readily discover its usefulness is questionable, but that applies to all sorts of aspects of qtractor. Without a thoroughly comprehensive and up-to-date manual, there are all sorts of things that users might not discover - but then again, such a manual would be so vast that probably nobody would ever read it all in any case.
Thank you for explaining to me what "poly" and "mono" mean in this context. I had no idea what poly was, and now that you have explained it I can see no possible use for it. But hey, that's just me, and other users working on different types of project might find it a god-send, for all I know.
I do agree that giving spacing in seconds rather than as fractions of a midi beat might be a little easier for users. However, expressing the gap/overlap in beats at least makes the user realize that if (s)he changes the tempo, the gaps will change accordingly. Perhaps it's a bit of a pain for people who don't go around changing tempi all the time as I do!
re. Easy articulation (4th. impl.)
I have just tried the new version out, and it is very good indeed. For instance, I have one violin phrase consisting of various note values from a quaver (eighth) up to a 2½ beat note (in 4/4 time). The phrase contains 3 slurs and some unslurred notes as well.
I was able to get an extremely good result by selecting the whole phrase and applying a gap ( I tried beat/6, but that was far too big, so I did it again with beat/16). Then I separately selected the 2 or 3 notes under each of the slurs in turn, and applied legato to them. The result is excellent, and only took a matter of seconds!
Thank you so much for this. It will be extremely useful to me, and I hope for some other users too.
David
Pages
Add new comment