Conceptual work on MIDI editing

Bussman: thank you!
Sure, a list editor is good to have. But graphical editing takes priority and GSoC time is limited.

that would work pretty well actually. i think it will take a bit of getting used to, but should be very efficient. left click to create and mmb+drag to move around would be very fast indeed.

looking forward to these developments even more now… i work in a school (do the network maintenance etc) and have just had a discussion with a music industry ‘guru’ teacher who is wanting us to order protools gear, since the kids need to learn protools or they will be DOOMED in the industry with their completely useless knowledge on anything but protools protools protools gear… grrrr i am sick of that belief still hanging on these days… hopefully one day people will wake up :slight_smile:

sorry, end rant.

porl

controller data

Porl, sysex is useful, but could it be that you were thinking of continuous controller data, which is more commonly used in sequencing?

Bezier-like curves with handles are a nice way to go for creating such data, though they’re not much use for editing pre-existing/imported MIDI CC data.

Thorwil,
Your mockups look fantasic! I am donating to ardour asap!

R

oops, you are right, sorry :slight_smile:

Heya, So I finally got around to reading the first article, and I have two comments.

4.2 Drums vs Piano

Many sequencers have special drum tracks / views.

A drum editor can do away with having rows represent notes in continuation and instead allow reordering and assigning ports and channels per row.

As note length tends to be of no concern for percussive instruments, symbols that denote a location but no duration are used, often a rhomb.

Drum and piano style editing could be combined by always allowing rows to be reordered, having optional per row port and channel settings and using both note bars and rhombs (or similar symbol,
understood as alias for notes of an adjustable equal length).

In most cases, this is true. however, there are times when a note needs to be choked for example when a hi-hat is closed. The Hydrogen team are addressing this with “Mute Groups” where by certain instruments are muted when a paired instrument or instrument type is played.

5.5.2 Quasimodes

Use modifiers and mouse buttons to have one main mode and everything else as quasimodes. One could even differentiate between modifier keys being pressed down before or after a drag is initiated,
as done in GIMP.

Could be very efficient after training, but hard to learn / memorize. Depends on documentation and users reading it . A way out could be status bar messages, but there’s not even a status bar and
all space is precious.

Perhaps use a translucent message next to the cursor that appears when a quasimode is enabled and disappears in normal mode? There's precedent for this, when moving punch loop ranges this very thing happens and is quite useful.
5.5.4 Keys instead of clicks

Use mouse for position and trigger actions with keys. Example: A to add notes.

Hard to learn. Difficult to find enough free and matching keys. Requires a one hand on mouse, one on keyboard approach for everything.

The pro here is that it’s VERY fast. I think this option should be considered as well, but not as the only option. So far with audio, Ardour has been very good about giving the user many ways of doing a task, from more basic and guided to more advanced and faster.

Referencing the second article, Pictures 2, 3 and 4 (stacked note velocities). Is colour reserved for something else (like pitch?) If not, colour could be use for velocity.

Even if colour is reserved for pitch, maybe On/Off Handle colour could be sued for velocity. This has the bonus of letting you see quickly which velocity handle is for which note. This would really only come into play for stacked notes, and ardour would be smart enough to know when that is.

This is really only necessary for big chords, but would be very helpful there (especially with 7 or more notes). In other cases, there would be no need to colour code.

Photo Sharing and Video Hosting at Photobucket

On IRC, thorwil suggests that the notes would lose visual coherence in such a scheme, I agree, but wonder if the benefits of easy visual access to these data outweigh such a loss, especially if it’s only used in specialized scenarios

As for the third article, underlay is just plain helpful. for visual learners like me, with maybe less music theory under our belts, how the track looks means a lot for deciding where to place the next note.

for the snap to note thing, I like the top right example, but maybe with a bit less subtle colour change.

bennyp: I’m aware of mute or exclusion groups. They whole point is they work with trigger notes of whatever length, where the sound is played in its full length if no other trigger interrupts it. This is a matter for samplers / synthesizers, though.
My proposal to allow both notes and rhombs in one space would makes it a free choice in every single case.

Well, it looks great! I really very like the idea of having only one space for all editing tasks with minimal tool selection. Just an idea for editing CC’s:

*A drop down above/to the side of the note grid area allows a user to select an active controller number to edit.
*When holding down spacebar, the background of the note grid changes to show/reflect the CC values/panning etc… instead of note velocities (a bit like the small view underneath the note view in cubase but in the note view background).
*Panning and other stereo CC’s could have a line drawn in the center of the view so you know where the center is - better still, a grid could be drawn so that some idea of scale could be determined vertically for all CC’s (maybe a horizontal line drawn every 10 units up/down with a dark line for the center if necessary for the CC chosen).
*Also, when spacebar is held, the notes themselves are drawn as very transparent so they don’t get in the way (but you can still see them) and note editing is disabled.
*Alternatively - the user could press ctrl-spacebar to toggle the mode instead of having to hold it down continually for more involved editing.
*When the mode is toggled on with ctrl-spacebar or even if spacebar is held down, the other keys (such as letters) could be used to change between bezier/line/direct editing of CC values - unless a way of doing it using the mouse could be found that doesn’t require any tool selection (this would be ideal).

This way, all editing could be done within one view with no screen splits which I personally find very annoying. Also, there is no need of a list editor if the view takes up a large enough proportion of the screen as CC values in MIDI only range from 0~127 - most people have enough control to select these values precisely, directly using the mouse if the view is taking up a significant proportion of the screen (such as all of it). Additionally - the feature in cubase that shows what value the mouse is currently over in a small box beside the editing window could be stolen as it would be mandoratory if a user wants to be able to select the values exactly.
-zoops. :slight_smile:

haha… Well, there’s not much inspiration you can take from a box that shows a value - maybe make it a circle lol! :smiley:

As for the space thingy, you’re probably right there, but it was more a conceptual idea than a suggestion - I mean, space or no space, any other key could be used instead even if it was taken as such, space just happened to be the closest key to my face when I looked down at my keyboard lol, I’ll try turning it round next time ;)…

I’m uneasy about holding down space to do anything. It’s bound to play / pause, triggering on key down.

I know of one example - Maya - where tapping and holding space are used for different things. The later for bringing up the menu system, so it’s for a rather short duration. Unlike the time needed for any serious work on CCs.

Oh, and we don’t steal ideas. We take inspiration and only in the worst case copy something - I mean, they can keep it :wink:

is there any updates on this? i’d be very interested to know how things are progressing :slight_smile:

porl

porl: I’ve been working on other things while waiting for Dave to get to the point where we can talk about what can be implemented. That will likely happen on IRC.