Redesigning Edit Drumset interface

• Mar 14, 2012 - 16:21

When I tried editing a drumset, I thought some things in the interface were perhaps unnecessarily complex.

I wonder if it could be redesigned - does anyone have suggestions?


Comments

I agree, plenty of room for improvement here. When I was customizing the drum set for my own templates, I ended up editing the drumset file by hand half the time.

Overall, I'd say workflow is kind of backwards. I don't want to start from a long list of MIDI pitches - most of which don't mean anything to me - then start to tell MuseScore how I want that MIDI pitch displayed. I want to start by defining the display of the note, then tell MuseScore what sound I want it to have. That is, the first step in the interface should not be selecting a MIDI pitch, but rather, placing a note on the staff - and not using a drop down to select a staff line, but by clicking on the staff. I'd place the note, select a head, voice, and other attributes, then select the sound I wanted it to have. And the sound selection list should be prepopulated with standard GM names - not just for the selected few pitches already set up in the default MuseScore drumset, but the whole list. Perhaps organized into subgroups if there is a clean way to do that (eg, drums, cymbals, other).

In reply to by Nicolas

You could keep the existing editor, but have all the GM percussion note assignments filled in in the Name column.

I see you have made a start on this in 1.2.

It would be handy though to be able to import a non-standard list of names for those using custom Soundfonts where the percussion names don't necessarily match the GM standard, or extend it as in the XG and GS drumsets.

You could make the staff position definition graphical by dragging the note around - you already have a graphic display but would need to make it interactive rather than controlled by spin buttons.

Finally use a graphical selection of notehead rather than the current dropdown menu - radio buttons with the note head displayed on them would be one way of achieving that.

Hope that has given you some ideas. :)

In reply to by Nicolas

Well, I haven't thought the whole thing through, but in the type of scheme I was describing, I would expect to the editor to show a palette of the existing defined drums - graphically, just as they are shown in the main palette, with scroll bars as necessary. There would be an "Add" button that would add a new drum to the set, and I guess it is the behavior of this button I was actually describing. But you could also select an existing drum in the palette and hit "Edit", and that would take you to basically the same type of facility.

It needn't really be a "wizard" type of interface. It could be a single window in which the left side contained the palette of existing drums along with Add / Edit buttons (Delete too, I guess), and the right side contained the controls to edit a given drum. Those controls would start at the top with a graphic display of the note as defined (with a means to change where it appears on the staff - I said by clicking, but maybe there just need to be up/down buttons). Below that would be the controls to set head, stem direction, and voice.

All this is predicated on an assumption that might not really hold, though. I am thinking of a "drumset" not as an exhaustive list of how to display each and every possible MIDI pitch, but rather, as a list of the specific drums you've chosen to define. My own defined drumset might contain only a dozen or so drums. An open question would be if/how it would be possible to get sounds that you didn't define in your set. I would expect to enter a note and go to Note Properties to override the MIDI pitch of the note (again, via a drop list, not by requiring me to remember pitch numbers). That's also where I'd expect to override the notehead.

This is admittedly a bigger change than just providing a new drumset editor interface. And I don't actually do enough with drums to have a good feel for how this might really play out in practice. But I *think* something like this could work well.

It all looks a bit beyond me, but I think what has been suggested is what I'm thinking of - thanks everyone.

I have a few ideas:

Sound preview of the drum that's being edited:

I would be useful to have a reference.

Improvements when moving drums around on Drumset:

Sometimes it's not possible, or it's confusing. There's also no indication that the drums are being moved.

In reply to by chen lung

The existing interface is ok apart from two things.

1. A list of the available sounds for the drumset should be available - this can be read from the soundfont.

2. You should be able to audition the sounds by clicking on them.

The big drawback with Marc's interface is that it only shows one drum at a time which would become cumbersome if you were defining a completely new drumset from scratch.

In reply to by ChurchOrganist

Why woukd you think it would be harder to define a drum set from scratch? You'd still see a list of all available drum sonds when clicking the drop down for the "sounds" (or make it a popup window if that's easier). The point is, except when while you are activiely adding a new drum, you screen isn't cluttered with information about MIDI pitches you will never use.

In reply to by Marc Sabatella

Because it adds a second, unnecessary layer to the interface, thus increasing the number of mouse clicks required to operate it.

The workflow would go something like:

Hit add
Select drum from the list
Edit in window
Hit add - choose next drum from the list
Edit back in the window.

The present interface lays it all out for you to see in one window - much simpler, and if the tweaks I mentioned are introduced it would be just about perfect.

In reply to by ChurchOrganist

I suppose that's one way of looking at it. For me, the need to constantly scroll around the dozens of drums I have no intention of ever using just to see what drums I've defined is far worse than one extra click on the occasions when I add a drum.

But I guess this depends on whether one tends to define drums sets that include every possible drum anyhow, or if, like me, you prefer to define drum sets that only include the dozen or so drums you actually need. For me, having to look at a hundred or more items on a list to see which ones I've actually included in my drum set is extremely frustrating.

I managed to do some work on a score that required changes to the drumset (thanks to ChurchOrganist's tutorial ), so I have a slightly better understanding now.

I have a suggestion:

Have all drum names entered by default and feature tick boxes for each entry - the ticked notes will appear in the drum palette.

In reply to by chen lung

It would be far better for MuseScore to read the drumset information in from the SoundFont.

This would then cater for the use of non-GM drumkits, such as the Marching Percussion extension to TimGM6Mb.

The only problem with this is the possibility of it being broken by the user selecting a different drumkit set in the Mixer Window.

Possibly, therefore, we should remove the selection of drumkits from the Mixer Window, and automatically set them from the Create Instruments dialogue.

Your thoughts??

In reply to by ChurchOrganist

Which information? There is no much to get in the soundfont. The important info needs to be provided by the user, the line, the notehead, the voice etc... The link "GM number to instrument" is the same here than in the instruments.xml. As far as I know MuseScore doesn't support non GM soundfonts currently. If it happens to work, it's a (nice) side effect of a bug.

In reply to by Nicolas

The correlation of drumkit sound to MIDI note number

On checking in Viena this information is not in the Soundfont as I thought!

So any non GM standard drumsets will have to be individually configured in instruments.xml

Easy to do once you understand the system :)

As for not supporting nonGM Soundfonts - they play perfectly fine, but the instrument associations are out (of course).

Do you still have an unanswered question? Please log in first to post your question.