On 6/11/2014 1:20 PM, igevorse wrote: > Note: I do not propose realtime midi input as replacement for another input > methods! I do not insist that people should use this feature for creating > complex scores, it could be used for recording very simple melodies > when_user_does_really_need_it. Yes, I understood.
> About single-note instruments: while writing post I thought only about > keyboard or midi-guitar. > By your items: > 1. As I understand, midi can describe only accurate pitch, so it's a problem > of emitter of midi-message (wind instrument?). About playing exactly to beat Just to clarify, I was thinking of the user inputting notes for single-note instrument staves but actually using a MIDI keyboard (think orchestral scores, where the user inputs each staff with a MIDI keyboard). > 2. Exact length can be compensated by changing some settings (choosing the > minimal note length again?). I was actually thinking of the instances where the note lengths differed more than the quantization settings or minimum note length. For example a quarter note may be played as an 8th note or shorter (and held by the pedal while the fingers prepare for the next chord). > 3. What do you mean by note spelling? Drawing D# or E flat? I didn't write > (or I wrote?) in my post that before recording user should prepare an empty > track (staff) with time signatures and tempos. So, adding tonality > (accidentals) could be a solution. So, we could determine right spelling > using tonality. But, again, there could arise some problems (for example, > while using a phrygian, lydian, etc. mode. Also could be fixed by adding ALL > possible tonalities and modes in settings.) Yes, that is what I meant by note spelling (D sharp versus E flat based on context). But I wouldn't worry about it for now. The other issues are more significant and should be overcome first. > 4. See "Note" above. > > About multiple-note instruments and pedal. We can record note duration "as > is" and record PEDAL_ON/PEDAL_OFF messages. MuseScore would play this file > as you need - because synth, having information about pedal, would make note > duration larger. Or, the second way is to compute note length manually, > knowing that pedal is pressed. > I think the first way is better. I agree the first option is better. My point was that the pedal messages can't be relied on for note length, because occasionally it means the notes should be written with longer but usually it doesn't (and it would take a lot of analysis to determine which method is best from the context). If you are a keyboard/piano player, play through some pieces (such as 4-part hymns) using the real-time MIDI input in other software and I think you'll get a sense for what I mean. > About other options - I have two possible solutions. > > 1. Make a lot of checkboxes in settings like "Use slight arpeggio, not a > block chord", "Be ready for the shortened note length", and so on like > settings in midi import. With this settings you can adjust algorithm's > behaviour to your playing style. > > 2. My killer-feature: give user a choice! :) > Cases that you described have common property - information about note can > be processed differently. > Idea: allow user to choose one of variants of drawing notes. If algorithm > detected some strange situations which can be processed differently, it > gives a choice to user. > > Example: [0] > This gives an ability to make changes just in two clicks. Also, there are > could be 3, 4 or more local variants of part. > > > [0] https://lut.im/Z2ALUvBq/4wjJ23I2 > I like the presentation in option 2 since it shows the options in context using music notation (rather than overwhelming the user upfront with theoretical scenarios described with words and checkboxes). Option 2 probably needs to present the user with the choice to set the default. (Maybe something like "Stop automatically simplifying to block chords" (similar to Microsoft Word and its automatic formatting context menus). Of course, your "killer-feature" would require more time to code than option 1. David ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
