Managment: We need a unicorn, how long will it take to make one?
Artist: I’ve never drawn a unicorn before, I…
Management: Nevermind that, I need a number. Give me a breakdown of how long it will take to draw each body part.
Artist: Uhh…okay. Two days for the head, one day for the body, 0.25 days for each of the limbs, I guess.
Management: Okay! I have you scheduled to draw four limbs before end of day. Tomorrow you can draw the head and finish off the week attaching the body to both.
Later that week…
Management: Shit, we forgot the tail. We should fix the alignment issues between the head and body but we’ve run out of time. Meh. Ship it.
In the process of trying to get an OpenGL snapshot working, I got this, which I thought was quite beautiful.
Starting to explore textured brushes in my drawing app. First attempt:
simpl started as a Unity prototype before it became a minimalist endeavour.
From time to time, Jack winces at the thought, “Jack of all trades, master of none.”
A love of learning keeps Jack motivated. A lot of shiny toys make it hard to hold Jack’s attention for long. Jack accrues skills over time, revisiting points of interest in an iterative fashion. Given enough time Jack should become a master in all fields, but time and progress wait for no man.
At times, the sheer amount of stuff to learn makes Jack depressed. During such times a little voice in the back of Jack’s mind whispers, “focus”. “Specialization is dangerous,” he argues, “look at the Panda bear! Look at the Cheetah! Specialization is great for short-term gains. Over the long-term, it’s detrimental.” “Yes”, whispers the voice, “but your life is half over. You will never be a success unless you focus on the one”. Jack resists, Jack is stubborn.
Eventually, Jack submits, “But what to focus on? How can I commit to just one thing? What if I choose to eat nothing but Bamboo and I’m faced with deforestation? What if I choose to run fast and prey can still outpace me?” The voice whispers back, “Jack of all trades, master of one.”
I hear the following statement from time to time: “Live drummers sound better than drum machines.” And I have to agree, a live drummer certainly has a feeling that isn’t easily replicated. However, I also realize that machines will eventually outperform humans in every endeavour.
So why do live drummers currently sound better than drum machines? Is it because they’re slightly off-time? If this were true, I think a lot more people would sound like world-class drummers. Professional drummers spend countless hours training muscle memory for millisecond accuracy. Of course, nothing is perfect and professional drummers are, on occasion, slightly off. So, it wouldn’t hurt if drum machines were slightly off as well. For example, one could using the following algorithm:
- First, determine if a note should be slightly off-time by generating a random number between 0 and 1. If the variable is greater than a user-defined value (ie. 0.95) the note’s timing will be slightly off.
- If the note’s timing is going to be slightly off, will it be pushed forward or back? Have another user-defined setting with three possible values:
- How far will the note be pushed? Once again, a user-defined setting. This one defines an upper limit or the maximum distance that a note can be pushed off time without sounding bad. The sequencer will then choose a random distance between the upper bound and it’s original placement (where the user entered the note value in the first place).
I don’t think being off-time is highly desirable and has only a minor impact on imparting feel. I believe the real difference between live drummers and drum machines are frequency dynamics. For example, a number of things happen every time a live drummer taps a ride cymbal or hits a drum:
- Change in velocity.
- Most beginners enter all note values at 127. Only later do they discover the impact of accents and fluctuating velocities. However, adjusting velocities can be tedious work and few users take the time to really sculpt velocity nuances.
- A drum machine could have a list of velocity templates or curves (one per pitch) that users could apply to the entire sequence. At the very least it’s a starting point for further refinement. Perhaps it’s even possible to:
- offset a template or curve by entering a phase value, which results in a change of note accents
- layer templates or curves and perform simple operations on them like intersection, addition, or subtraction.
- Changes in volume are not enough. Each drum sound must be multisampled, so that a change in velocity results in a subtle change of the sound.
- Change in physical location.
- Hitting a drum in a different location results in a different sound. Physical modeling or multisampling can be used to accomplish this to various degrees.
- Change in frequency.
- A previous hit affects the current hit. For example, tapping a ride cymbal that is already vibrating is going to give you a slightly different sound.
- Drum kit components are in constant fluctuation – causing constructive and destructive interference patterns – which provide you with a rich dynamic texture. On the other hand, most drum machines use static samples – there’s no change in sound from one hit to the next.
Again, I think frequency dynamics and subtle variations in performance are what really differentiate live drummers from drum machines. If drum machines want to compete, they need to become less rigid.
I broke my robots arm today. How? I set him down on his belly with the power on. He was in a one arm push-up for a moment before I toggled the power off. Apparently there was enough weight on the servo to break two threads on a cog wheel. Each cog wheel is made of plastic, not metal.
I’ll be evaluating internal components for practical load requirements with my next purchase – lesson learned.
Programming is a basic skill, like reading and writing. It’s something you should possess if you’re going to successfully navigate the information age. I can’t imagine living in a world of computers and not knowing how to program – it’s absurd. Programming is sheer power and with it you can implement your ideas.
To some, programming is perceived as purely technical, there’s no art to writing a program. Of course, nothing could be further from the truth. Programmers create software by designing (and implementing) architectures of interweaving patterns of abstract concepts. However, before you get to that level of skill, you first have to master the technical. And like any other discipline, be it painter or craftsman, mastery of the technical can take years before you are able to express yourself.
In forums you frequently see flame wars over OpenGL vs. DirectX or C++ vs. C#. The language or API in question is irrelevant. These threads are typically started by n00bs trying to decide which one to learn. Although most of these threads are quickly shutdown, it remains a legitimate question.
API consideration is important because nobody wants to make a serious investment in time and resources pursuing a language or API that is destined for obsolescence. A common occurence in ”versus threads” is a post about how it doesn’t matter which language/API you use because you can accomplish the same result with either one. It suggests they are equal and such statements are misleading. Common functionality between languages/APIs is not equivalence.
Common functionality between a language/API isn’t suprising because both are attempting solutions for the same problem domain. Yes, both APIs can render a triangle just like two audio APIs can play a sound. Even if both APIs have equivalent functionality they would still be unequal. Why? Design. Each API approaches the problem with a different solution. Both are valid solutions and both expose their solutions to the client. However, one solution is better than the other if it has better design. In other words, how complicated is it to render a triangle or play a sound? Is it client friendly? Modular? Extensible? Flexible?
So which language/API is better? It’s up to each developer to do a quantitave and qualitattive assessment. The set of tests are determined by your goals. They’re individual, customizable, and ultimately arbitrary. Once you”ve made your decision you make a vote by using a given language/API in the development of your application. Not all votes are equal. Its strength depends on the success of your application in the marketplace and/or participation in the community.
Few programming books offer substance. Most are re-hashed documentation. They are filled with tables detailing API methods, parameters, bit flags, and so forth. It’s an exercise in tedium to wade through such material. Perhaps the marketing department demands that books be of a certain size and weight. A customer is not going to spend $40 to $100 dollars on a thin book. Every fool knows a books value is proportional to its weight.