[Doggiebox] Design challenges with beat-level editing

Mike mcarlyle at charter.net
Fri Feb 11 08:36:42 EST 2005

I feel like I'm at the voting booth. This is my chance to decide on
something and if I keep quiet, I won't be able to complain in the future.

Ben... This does not seem to be a technology problem. You've indicated you
could go any of several different ways on this. I believe the decision
you're about to make has to do with your concept of the Doggiebox user more
so than the product itself. You must have a picture in your mind of the
perfect product. You probably also have a pretty good feel for customer
expectations based on the input from this list.

Have you read the book "Raving Fans"? It talks mostly about customer
service, but it could be interpreted to cover product development as well.
Several "secrets" to providing the ultimate product include "Decide what YOU
want", followed by "know what your CUSTOMER wants", and "deliver 100% plus
one" on whatever your model turns out to be. It's philosophical mumbo-jumbo,
but it's extremely relevant to your problem.

The more you try to make Doggiebox all things to all people, the more
complicated it will become. Power-users will relish the products depth and
won't worry about choosing between options. Novices who dabble in Garage
Band looping once in a while may be turned off by a product that seems to

Maybe you need to spin off a Doggiebox Basic and a Doggiebox Pro?

As to my personal opinion, I'm with Carl on this one. I don't expect the CUT
operation to remove anything except the drums. It could become frustrating
to deal with beats being removed unexpectedly.

I've never even considered the concept of a "beat subdivision". I suppose I
deal with them everytime I use DB, but I'm not even really sure what this

On 2/10/05 3:27 PM, "Ben Kennedy" <ben at zygoat.ca> wrote:

> I can see two approaches to this problem.
> One would be to restrict beat-level selection to whole beats only, rather
> than any arbitrary subdivisions as is possible in current builds.  This
> would eliminate the geometry issue but would forego a lot of flexibility,
> kind of defeating part of the whole goal of more versatile editing.
> 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.
> 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.

More information about the Doggiebox mailing list