From: Robert J. <spa...@gm...> - 2011-09-26 08:39:45
|
Hi Flo, > please, tim, look at my emails about this subject, try to understand what i > want to do, and tell me if there are any flaws. > > > multiple drum maps sound cool, but make problems when you move drum parts > across different tracks. the mapping may be very different. > > > and tell me your opinion (also all other devs!) about the following > compromise: > > - create a new MIDI track type, for example "FloDrums". this track type > is identical to MIDI (non-drum) tracks, except it launches a drum editor as > default instead of a piano roll. > - keep the "old drum track type". leave it, maybe declare it as > "obsolete, but still kept" > - change the drum editor's behaviour for "non-old-style-drum-tracks" > (and only for them; this means "MIDI tracks" and "floDrum-tracks"): > - do not use the global drum map, but always the "immediately after > muse started"-drummap (*) > - do not allow to change the out-note or to reorder that list > - the drum-map-entry-number (this is, height, or y-coordinate) of an > event is determined by the out-note, not by the in-note (this works, because > unchangeable out-notes can never be duplicate). changing the in-note does > NOT change any events. (it does for old-style-drum-tracks becaus ethe pitch > has to be adjusted) > - ignore or hide the "channel" and "port" columns in the drum list. > (as the track is treated like a normal MIDI track, all events on that track > are sent to the track's port/channel) > - extend the drum editor's functionality: > - when opening multiple tracks' parts in one drum edit, offer > options like "group by track", "group by channel/outport combination" or > "don't group, mix it up" (muse currently does "mix it up") > - even "mix it up" seperates "flo-drum-tracks" from "old-style-drum > tracks" (as they're fundamentally different things) > - allow for hiding drum list entries: "show all", "hide unused", > "only show selected" (some selection window would be necessary for this) > > > this can be summed up as "let my way and your way coexist". this does not > involve extra work for me (it actually saves me from some work, like > removing the old-style-drum-code and adding support for importing old > files), and extends muse's flexibility while not forcing users to change > their way they do drum tracks. i do understand that the old-style-way has > its benefits next to its disadvantages. > > > tim, robert, and all the others: please tell me what you thing about this > compromise. especially you, tim ;) > Doing a parallell implemention in a branch is a low risk solution. I'm with Geoff, just do it :) It is quite hard (for me) to get a good grip on what exactly you want to achieve without somekind of mockup or proof of concept. If you believe in your solution and it's not too much work I think you should do atleast parts of it. I tried to comment earlier on what I percieved as improvements in your solution, though as proven by Tim's comments this is a complex subject and in the end there are many requirements that need to be satisfied somehow. The current solution is working and quite extensive but I agree it's complexity makes it very hard to use for new users and there are some usability requirements that could be enhanced, like auditing sounds. And E-notes and A-notes, one of them should be enough imo. Etc. > and in case you all say "whow, these flo-drum-tracks really rock, we don't > need the old-style-drum-tracks any more", this can be easily done. just > remove them and write some import-old-files-code. > Right :) > and if you say "bah, these flo-drum-tracks really suck!", you can use muse > as you used to use it, and i can use it as i want to use it ;) > And Right :) Regards, Robert |