Design challenges with beat-level editing
Folks, I have been mulling over some design issues for some time now and I would like your feedback. As you can tell from the latest builds, the UI is getting to the point where it is possible to select beats and sub-beats, as well as entire bars or parts thereof, for editing operations. In Doggiebox 1.2 it is only possible to copy and paste whole bars; in this next version the goal is for copying to be possible on a more granular level. However, I am now faced with how to devise a UI that best works to achieve what we want, and there are a few subtle problems that need to be solved. Copying and pasting whole bars is trivial because any given bar either exists or it doesn't, and they can be shuffled around or removed and created like tiles on a tabletop. But once you get to manipulating beats WITHIN those bars, some challenges arise. 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? 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. The conundrum is with sub-beat portions. In the first scenario, removing that subdivision would effectively pull an eighth note from the bar; should the 4|4 turn into a 7|8? Maybe... but what if, instead of being zoomed to two subdivisions per beat, we were zoomed in one more level so as to show triplets for each beat? The concept of removing one such subdivsion now becomes more complicated. 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. Whaddyall think? Ideas, feedback? -ben -- Ben Kennedy, chief magician zygoat creative technical services 613-228-3392 | 1-866-466-4628 http://www.zygoat.ca
Personally, I think the ease of use of db is one of its major attractions and have not felt the need for the kind of sophisticated editing you describe, Ben. I'm usually happy to position the cursor and Insert a bar, copy a bar into that new space and and edit. Alternatively, if necessary, create a new Section, write it from scratch and move it into place on the Playlist. The Pasting question you raise is usually addressed in sequencing software by Insert, Add or Overwrite options, where the first creates a gap at the Insert point of the same length as the new section, the second simply puts the extra notes into an equivalent space on the same track and the third replaces whatever's already there. Again, not sure if I'd particularly want it. If it ain't broke, don't fix it, IMO! Adrian PS Any chance of 96 divisions? .----- Original Message ----- From: "Ben Kennedy" <ben@zygoat.ca> To: "Doggiebox List" <doggiebox@lists.zygoat.ca> Sent: Thursday, February 10, 2005 8:27 PM Subject: [Doggiebox] Design challenges with beat-level editing
Folks,
I have been mulling over some design issues for some time now and I would like your feedback.
As you can tell from the latest builds, the UI is getting to the point where it is possible to select beats and sub-beats, as well as entire bars or parts thereof, for editing operations. In Doggiebox 1.2 it is only possible to copy and paste whole bars; in this next version the goal is for copying to be possible on a more granular level.
However, I am now faced with how to devise a UI that best works to achieve what we want, and there are a few subtle problems that need to be solved.
Copying and pasting whole bars is trivial because any given bar either exists or it doesn't, and they can be shuffled around or removed and created like tiles on a tabletop. But once you get to manipulating beats WITHIN those bars, some challenges arise.
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?
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.
The conundrum is with sub-beat portions. In the first scenario, removing that subdivision would effectively pull an eighth note from the bar; should the 4|4 turn into a 7|8? Maybe... but what if, instead of being zoomed to two subdivisions per beat, we were zoomed in one more level so as to show triplets for each beat? The concept of removing one such subdivsion now becomes more complicated.
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.
Whaddyall think? Ideas, feedback?
-ben
-- Ben Kennedy, chief magician zygoat creative technical services 613-228-3392 | 1-866-466-4628 http://www.zygoat.ca
------------------------------------------------------------------------- Zygoat Doggiebox discussion list - <http://www.doggiebox.com> To unsubscribe, view archives or change your options: <http://lists.zygoat.ca/mailman/listinfo/doggiebox>
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. Cheers, Carl -- Carl Edlund Anderson http://www.carlaz.com/
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.
participants (4)
-
adrian.delsoï¼ btopenworld.com -
Ben Kennedy -
Carl Edlund Anderson -
Mike