Hi Maxim, Regarding your replies:
> I can't say exactly is it complex or not. It's not only about implementing > automation tracks as "window > with bezier curves linked to the score". We have to decide how to link > this new feature with existing > controls. Let me explain it: for example, we have dynamics that handles > volume change. We could make > an automation track for volume, but should it be linked to dynamic marks? > Should we re-make our bezier > curve? What if user changes bezier curve, should we add a new dynamic > marks to the score? Lets reason from scratch on this matter: why do sequencers need automation tracks? Sequencers, in general, don't provide dynamic/articulation markings capable of affecing playback as notation editors do. Therefore, they provide automation tracks to allow the user to manipulate playback by tweaking, or fine tuning, MIDI parameters/control changes in a faster, less "tedious" and more "continuous" way, right? Musescore is a notation editor, so all notation elements present on the score should take precedent over other MIDI editing methods. For example, one way to achieve a legato effect is to slighlty extend/overlap a previous note with the next one (this is the basic "sequencer way" of producing legato). So, lets say we write two quarter notes in the score and we want to achieve legato by tweaking the extension/overlapping amount in the piano roll window. A "smart" score should continue to show 2 quarter notes, although the first is slightly longer than the second. With other MIDI parameters/controls, it should be the same, in my opinion: they're only there for fine-tuning playback. For instance, if I place a "mp" mark on the score, that's because I intend to have a note Velocity (or MIDI CC11, preferably) around 64, according to a predefined dynamic markings to velocity level chart. This value could be locked in the automation tracka and showing a different color handle, for this particular marking (other values for other markings), making it a vertex. It should only be altered by changing it in the Inspector window. If I wish another dynamic instead, say "ff", then I place it on the score and a new locked value/vertex appears substituting 64. But what I may want to tweak, is the dynamic behaviour around the original "mp" marking. As you know, human playback performance is very subjective. So, lets say I wish to produce some slightly audible, but "invisible" crescendos/diminuendos prior to, or after, the "mp" marking. Thats where automation tracks would come handy. The same goes for string vibrato amount (seldomly showed explicitly in scores), or piano Pedal markings, which in many scores only appear explicitly on the first measure(s), although their effect is intended to apply to the remaining score. I think that, to start with, automation tracks might only allow linear and exp/log curves (lets say, with 10 curvature degrees each), instead of true bezier curves (much harder to program), since, in my opinion, most live performances would be well simulated by those simpler approaches. > Another situation with chorus and reverb: as I understand, developers want > to hide chorus and reverb > controls from mixer windows as redundant. So, to implement automation > tracks for these parameters we > should re-implement the base (controls has no effect on internal sequencer > now). So, automation tracks > should be linked with existing parameters and controls. I think that reverb and chorus automation tracks should also exist. See my reasons on the reply below. @Michael/ChurchOrganist > Just a word about chorus and reverb controls. IME these controllers are > usually set at the beginning of a > score and not altered in realtime. To me it would make sense to have these > controllers as part of > instrument setup. Once we have MuseScore 2 out I shall be doing more work > on my proposal to > incorporate the mixer in the Create instrument dialogue, but on a > temporary basis I am looking at greying > out Reverb and Chorus controls by default and enabling them if JACK is > selected as the output. I know > how to do this - I just need to work out where the relevant bits of code > need to go :) Regarding the use of Reverb/Chorus controls, I would like to leave my thoughts on the subject here. As you say, Reverb and Chorus are usually set at the beginning of the score and left untouched, because, in many live performances, the player seats in its place, within a given room, and doesn't move. But then, by logic, the same would apply to Volume and Panning. Also as Maxim, has pointed out some times to me, when using synthesizers and electroacoustic instruments, static MIDI controls aren't entirely desired, since in those the player may changed any MIDI parameter/control at his will, and Reverb and Chorus are just two of them. In addition, considering, for instance, the SSMN Musescore derived project, where players are expected to move around the room, one way to emulate the displacement effect with MIDI controls, would be through the careful variation of (at least) Reverb, Panning and Volume. This being said, I don't think that there is much need for Reverb and Chours to have their own knobs in a separate mixer, as long as Musescore maintains the hability to change Reverb and Chorus settings via Midi Actions/ automation tracks, or something alike. Best regards. -- View this message in context: http://dev-list.musescore.org/Improving-JACK-MIDI-Out-tp7578792p7579000.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
