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 "pro-level". 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 means. On 2/10/05 3:27 PM, "Ben Kennedy" <ben@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.