[Doggiebox] Design challenges with beat-level editing
Carl Edlund Anderson
cea at carlaz.com
Fri Feb 11 05:43:17 EST 2005
On 10-Feb-2005 20:27, Ben Kennedy wrote:
> For example, say you have a 4|4 bar expanded such that there are 8 total
> beat subdivisions visible (two per beat). In the current builds, you can
> select one of these beat subdivisions by clicking in the header with the
> "triangle" cursor. The question is, what should happen if you then
> perform a Cut?
IMO, the intuitive thing to happen there is for the various hits (if
any) to be removed from the beat subdivision and placed in the
clipboard. Are you thinking of an alternate behavior in which Cutting
takes the beat subdivision out of the bar (i.e. the bar loses a beat,
going from 8 to 7)? That doesn't make sense to me. If I select a
character in my word processor and Cut it, the page size doesn't change.
I can see that someone might want to shorten a bar, but that kind of
operation doesn't seem like the way of going about it.
Maybe it's more like dealing with tables in a word processor or layout
program. Cutting and pasting cells (or rows and columns) works a little
differently than cutting and pasting characters within them. In
Framemaker, for example, you are usually offered the option when Cutting
either to take the contents of the cells but leave the cells themselves,
or to take both the cell contents and cells. Pasting is similar, where
you are given the option to replace existing cells or to insert.
> Setting that aside for a moment, say you instead select two adjacent beat
> subdivisions which account for one whole beat of the bar. Conceivably,
> performing a cut could remove the beat, turning it into a 3|4 bar. The
> copied beat could then be pasted anywhere else, say into another 4|4 bar,
> causing it to become a 5|4 bar. No problem.
Being given the option to replace or insert would take take care of that
quandry. Though that said, if I was pasting into selected beat
subdivisions, I would expect my selection to be replaced by the
clipboard material. If I was pasting from a blinking cursor, I woulld
expect an insert.
> Another is to change the semantics of the Cut behaviour so that instead
> of actually removing beats, it merely removes the drums that exist in the
> selected space (preserving the structure/time characteristics of the
> bar). Paste would then similarly "paste into the space" without adding
> any new time or beats to the bar(s) under the cursor. We would create
> separate commands for adding/removing beats.
If I had to go with one option, this seems the most intuitive.
> To me, it seems that while each of these approaches has its benefits
> neither fully cuts the mustard by itself. For example, with the latter
> design, it would no longer be possible to delete a bar without using a
> secondary command. Perhaps a third approach would be to have two sets of
> editing commands, Copy/Paste Beats and Copy/Paste Drums, which would
> behave each of these ways respectively. This strikes me as dangerously
> obscure however.
> Whaddyall think? Ideas, feedback?
I think modelling the behavior on the kind of behavior already found in
word-processor/layout table editing would come pretty close to a
reasonably flexible solution. I'm not sure how far that analogy can be
taken in practice, but it's the first thing that comes to mind! I think
the idea of a choice between copying/cutting/pasting either a container
(beats) or a container and its contents (beats + plus drum hits) would
not necessarily be that confusing.
Carl Edlund Anderson
More information about the Doggiebox