A lot of the tips in this article ring very true. I hope someone finds it helpful.
At 19:35 02/07/2003, Michael Carlyle wrote:
A lot of the tips in this article ring very true. I hope someone finds it helpful. http://www.sospubs.co.uk/sos/mar98/articles/rythm.html
That's got some good ideas that I wouldn't have thought of, or had an idea of how to implement, on my own. I've been wondering whether there would be utility to put some sort of "auto-humanization" feature in Doggie that would sprinkle just a _little_ bit of irregularity in terms of timing and velocity through a selected section or song. I'm not quite sure how that would work, or whether it would, but it would be interesting to see.
The article's discussion of making up a "master pattern" from which to create variations brings to mind a way to organize a "pattern/fill pallette library" in Doggiebox. I am imagining a little pallette window showing a list of master patterns like "Rock Pattern A", "Slow Jazz Rhythm", "That Little Snare Fill I Like", "That Riff I Lifted from That Song My Kids Listen To". Then perhaps contextually clicking the name of a given master pattern would reveal variations on that pattern: "Rock Pattern A1", "Rock Pattern A2", "Rock Pattern A with ride instead of hi-hat", etc. That might make a convenient way of categorizing related patterns and fills. Of course, one could always ignore this feature if one only was interested in a few master patterns, or perhaps the sort of "open this drawer" approach could be used to categorize a collection of patterns and fills in different ways ....
Cheers, Carl
-- Carl Edlund Anderson mailto:cea@carlaz.com http://www.carlaz.com/
On 15 7 2003 at 5:35 am -0400, Carl Edlund Anderson wrote:
I've been wondering whether there would be utility to put some sort of "auto-humanization" feature in Doggie that would sprinkle just a _little_ bit of irregularity in terms of timing and velocity through a selected section or song.
I've been planning for about a year now to add something like this. Cool to see that others think it's a good idea too.
The article's discussion of making up a "master pattern" from which to create variations brings to mind a way to organize a "pattern/fill pallette library" in Doggiebox.
Yeah, again I've had similar ideas... a pattern palette would be quite useful wouldn't it.
Thanks for the suggestions; maybe these will move up the priority list a bit :)
-ben
For I guess a few months now I've been musing over how to put together a Doggiebox drum kit (or kits) to model a Latin-style percussion section. I've been thinking about the way the Doggiebox UI is organized, particularly as summed up in the manual: -----
The rationale behind our five-group drum arrangement hinges on two concepts:
- A human drummer, with two arms and two legs, is typically able to hit a maximum of only four distinct drums simultaneously.
- A huge grid providing slots for dozens of instruments quickly
becomes very unwieldy, although the grid paradigm itself is useful for visually sorting information. Consequently, the approach is to group the drum kit instruments into five general categories, like so (from top to bottom):
- accessory cymbals (crashes and other);
- rhythmic cymbals (hi hat and rides);
- secondary drums (tom-toms);
- principal drums (snare drum);
- foot-operated drums (kick drum).
-----
This works great for modeling a single drummer, but I'm thinking that perhaps the UI concept could be expanded to include the concept of a rhythm _section_. For an easily accessible example, the contemporary Santana band has a rock kit drummer, a congas/bongo/quinto/tumba percussionist, and a timbales percussionist (and probably they or someone is shaking a maraca or whacking some claves occasionally, too).
In theory, one could assemble a single, monster, Doggiebox kit with all these elements, though this would kind of violate the principles of the Doggiebox rationale (and I'm not sure how amongst the 5 categories I would want to sling all these extra drums anyway). In a sense, the Doggiebox rationale suggests that to put together a percussion section like this, one would really want to put together a percussion section: to load _3_ seperate drum kits -- a rock kit, a congas etc kit, and a timbales etc. kit -- which would appear simultaneously in the Drum Kit List pallette (though labeled and grouped seperately). Then one would proceed to compose your Doggiebox song as normal, but conducting a section rather than a single drummer/kit.
Would something like this be sensible/useful/feasible? The ability to load multiple kits would work let you get into things like modeling situtations like the Allman Bros or Grateful Dead where there are two or more drummers/percussionists. Heck, with the addition of the talked-about "humanization" feature to offset timing and velocity slightly from kit to kit, one could quickly imitate a marching band ;)
Cheers, Carl
-- Carl Edlund Anderson mailto:cea@carlaz.com http://www.carlaz.com/
On 17 7 2003 at 11:31 am -0400, Carl Edlund Anderson wrote:
In a sense, the Doggiebox rationale suggests that to put together a percussion section like this, one would really want to put together a percussion section: to load _3_ seperate drum kits -- a rock kit, a congas etc kit, and a timbales etc. kit -- which would appear simultaneously in the Drum Kit List pallette (though labeled and grouped seperately). Then one would proceed to compose your Doggiebox song as normal, but conducting a section rather than a single drummer/kit.
This is a great idea Carl, and a logical extension of the arrangement I feebly described in an earlier message (April 7th):
Here's a preview of one of my plans which I am going to try working up shortly:
a) remove the "5 position" grid limitation and make it so that there are a user-definable number of grid positions (editable in the drum kit). b) make it possible to adjust the relationship and ordering of all elements of the drum kit, insofar as what drums might share which grid positions and layout. c) create a toggle-able setting in the song editor for how the drum kit is presented, switching between three modes:
i) "show all", which lists the entire kit in the margin with each drum in its own grid position, a la Virtual Drummer ii) "show current", which is similar but hides all positions where there are no drums currently in use in the song. iii) "show condensed", equivalent to the way things currently work, where various drums may share the same grid position if they do not conflict.
In all three cases, there would be a direct visual alignment between the drum name/info and the gridline in the song editor which corresponds to it. (That's not currently the case, as the kit is presently shown in a scrolling list independent of the song editor.)
My thinking is that these view modes would provide flexibility between having an easy-to-navigate condensed score for people who like the current notation style, as well as a larger complete, grid-like layout for fuller control (and those who find the current "grouped" concept irritating).
Extending on this, we could then support an arbitrary number of kits in the song whose instruments you could hide/reveal with disclosure triangles or whatever.
-ben
At 22:06 22-07-03, Ben Kennedy wrote:
Here's a preview of one of my plans which I am going to try working up shortly: a) remove the "5 position" grid limitation and make it so that there are a user-definable number of grid positions (editable in the drum kit). b) make it possible to adjust the relationship and ordering of all elements of the drum kit, insofar as what drums might share which grid positions and layout.
This would be very cool, though I can see benefits to people trying to adhere to general "drum kit UI guidelines" in terms of what kinds of drums/sounds, generally, one might assign to different positions. That will ease swapping kits in and out.
c) create a toggle-able setting in the song editor for how the drum kit is presented, switching between three modes: i) "show all", which lists the entire kit in the margin with each drum in its own grid position, a la Virtual Drummer ii) "show current", which is similar but hides all positions where there are no drums currently in use in the song. iii) "show condensed", equivalent to the way things currently work, where various drums may share the same grid position if they do not
conflict.
In all three cases, there would be a direct visual alignment between the drum name/info and the gridline in the song editor which corresponds to it. [...]
Extending on this, we could then support an arbitrary number of kits in the song whose instruments you could hide/reveal with disclosure triangles or whatever.
Yes, that would be great, and very much along the lines I had been thinking :)
I had another idea which someone else may well have already suggested, and if so, I'll just add my voice in support :)
Would it be possible to have some way of selecting "horizontally"? (For example, selecting to copy the bass drum pattern from the lowest line in the editor, but leave all the rest of the higher lines alone? Similarly, would it be possible to introduce a means of selecting "vertically" within a bar (i.e. selecting everything in the 3rd and 4th beats of a 4/4 measure, but leaving the first two beats alone?)?
Cheers, Carl
-- Carl Edlund Anderson mailto:cea@carlaz.com http://www.carlaz.com/
On 01,08,03 at 12:26 pm -0400, Carl Edlund Anderson wrote:
Would it be possible to have some way of selecting "horizontally"? (For example, selecting to copy the bass drum pattern from the lowest line in the editor, but leave all the rest of the higher lines alone? Similarly, would it be possible to introduce a means of selecting "vertically" within a bar (i.e. selecting everything in the 3rd and 4th beats of a 4/4 measure, but leaving the first two beats alone?)?
These are both good ideas, and I know other people have hinted at the use for the same kind of thing as well. The big question is, how to implement the UI in a manner that provides that flexibility without adding to confusion for newbie users?
I am almost inclined to scrap the current mode whereby you have to press Cmd in order to have context-sensitive drum selection, and make that the default behaviour. Is there anyone on this list who does NOT use this, and instead prefers to mouse back and forth to the drum list each time to choose a new drum?
I originally designed it to make the functioning simple and obvious for new users, thinking that they would become confused to see the mouse cursor change as they moved over the patterns vertically. However, I suspect that after using the app for a few minutes, the intended use becomes natural. Is this true?
If we were to go this route (making context-sensitive the principal mode), then Cmd could become the method used to select individual regions within the patterns (as one might more naturally expect anyway, à la Finder icon selection).
-ben
At 23:28 03-08-03, Ben Kennedy wrote:
I am almost inclined to scrap the current mode whereby you have to press Cmd in order to have context-sensitive drum selection, and make that the default behaviour. Is there anyone on this list who does NOT use this, and instead prefers to mouse back and forth to the drum list each time to choose a new drum? I originally designed it to make the functioning simple and obvious for new users, thinking that they would become confused to see the mouse cursor change as they moved over the patterns vertically. However, I suspect that after using the app for a few minutes, the intended use becomes natural. Is this true?
I think this rapidly becomes true for a new user. I started by ignoring the context-sensitive stuff simply because I'm usually too lazy to do things like pressing the Cmd button while mousing, but quickly found I was even lazier to travel back and forth between the drumkit menu and pattern editor.
If we were to go this route (making context-sensitive the principal mode), then Cmd could become the method used to select individual regions within the patterns (as one might more naturally expect anyway, à la Finder icon selection).
This certainly has my vote. I think the functionality gain from being able to select individual regions within the patterns more than outweighs the risk of confusing a novice user with a context sensitive cursor (it seems to me that applications are increasingly making their cursors context sensitive anyway).
Cheers, Carl
-- Carl Edlund Anderson mailto:cea@carlaz.com http://www.carlaz.com/
-
Ben Kennedy -
Carl Edlund Anderson -
Michael Carlyle