Ideas

If design is a process which bring out the value of an idea, then what is an idea to begin with?

Wiktionary offers some definitions, among them this one: "The transcript, image, or picture of a visible object that is formed by the mind; also, a similar image of any object whatever, whether sensible or spiritual."

Which appears a bit cumbersome. I will yet again create my own definition to serve my own purpose.

- An idea is a collection of information with undetermined value.

This is a bit rough, but its enough to hook it up together with my definition of design. What yo can do with an idea is what is interesting. There are two main techniques for determining the value of an idea. You refine the idea either through creating artifacts around it which can transfer the idea to more brains, or you construct something that is the embodiment of the idea to see what happens. These two techniques are quite different.

Drumming up value

So Tricklock is busy drumming away at an experimental space ballad as performed by Spaceforce. It runs at 90 bpm and tries to convey a bit of what goes on inside robots as they travel through space towards unknown alien civilisations. Having decided that Tricklock is not going to complain at his sound I can use him as a kind of infrastructure on which the rest of the song is built.

There are some problems which reduce productivity towards a useful result and they are hidden beneath the ability to change the arrangement around when need arise. I end up doing a lot of something I will call "backwards sequencing" which means that I realize the result will be better if I go back and shuffle the rythmic infrastructure to satisfy the needs of the other band members, mainly Schmooth who is the keyboard player.

This makes me think that I will need to work on Schmooth next so I can determine which parts of Schmooth and Tricklock needs to be in agreement on how the song infrastructure really operates before any large amount of work is sunk into details that require rearrangement of the core structure. I am expecting Schmooth to have 4 roles to fill with varying impact on core structure. Having a steady drummer who can tell the keyboard player how things should work will hopefully make this upcoming job a lot easier than creating the drummer was. If that is true then Tricklock already prove some type of value.

A Flawless Piece

Now I spent the weekend finishing and testing Tricklock.

This means that I will from now on accept any remaining defects within the construction of Tricklock as a part of his "personality" rather than try to fix it. I think this is a relevant insight to all kinds of production. Included within the piece of Tricklock came various prototype implementations of the other band members.

I could claim that the other band members are implemented to a functional cheap implementation. From here I have the option to use the "maintain multiple options" and actually make a production based on the prototypes which would sound reasonably decent. I have on the other hand identified the need to formalize the data set behind the other band members into modules which I can load easily to reproduce them.

To create these modules I will need to invest much time in infrastructure, and since I always aim to balance all effort against user value I will also add some time to refining the content of the modules for an even better result.

I wonder if I can uplaod sound files to this blog for the documentation of this process...

Tricklock - The Drummer Robot

Tricklock is a very ambitious drummer robot. He is built on 32 triggers, with an average of three samples per trigger which in turn are velocity sensitive leading to roughly 90 or so samples in total. The 90 samples are then sent to 8 separate stereo channels for mixing purposes.

Kick, Toms, Overheads, HiHat, Snare, Perc, Shaker and WierdSFX

The main drum channels except for the WierdSFX and Shaker channel are sent to a Drum Submix for an overall level control so the whole package can be automated on its own. The Drum sub is also sent to a drumroom reverb for some ambience. We can expect that Tricklock will be doing all kinds of wierd processing on this setup eventually, but his bones are now in place.

The samples range across a mix of more or less natural samples, the idea is that Tricklock will be able to electronically play most of the genres I might consider for the Spaceforce band later on, from light ambient kinds of things, pop, rock and electronic.

Considering my ambition to follow the idea of a Flawless first Piece for Spaceforce I will probably keep on tweaking some details of Tricklock for a day or two before I feel satisfied with his final setup. So now Tricklock and I will start playing around with random grooves.

Defining a motive

I am very much driven by the need to have a motive. This reflects strongly on my hobby projects and when I do things aimlessly the result tend to be reduced to a conceptual effort without value.

To do something about this I need to create a reason for putting up with an effort. For hobby projects there is a good lot of slack on the side of communication. There is no need for anyone except myself to really understand the motive. To make a different type of thing I will try document this incomprehensible process here, you might not be able to follow it well. But I'll try make it readable.

I need a motive for making some sci-fi music, for a larger scale hobby project which is a bit under the radar and hopefully will deserve proper mention later on. What are my options?

1 - Make something that I want to have for my own pleasure.

2 - Make something I think others will like.

3 - Make something for the fun of it.

Ok, so I pick the fun, thats #3 in the list.

So what is fun?

Fun is learning something by using skills which I can develop during the creative process. This is the reason for picking option 3.

If I were to go for #1 I know I will personally dislike the result until my highly picky ears are willing to accept the output on an emotional level. This will require something I expect to be close to an infinite number of iterations. SinceI am somewhat reluctant to invest the rest of my life in this hobby project I will abondon this option.

If I were to go for #2 I would expect to need to work so hard that I will never finish, if I aim at pleasing an external audience my probability of success is limited by my inability to measure my progress against a target audience so this one is out.

Going for #3 I'll start with identifying which skills I want to develop. Thats relatively easy. Production methodology, guitar playing, mixing, rigging, storytelling and some other random stuff not worthy of mention. I will conciously abandon the skills of designing up value, I'll move outside that concept by pretending that I dont care about it in this particular case. The work involved with design in this case would also not be within my means to execute.

Now I have the basic idea, so how to I create the motive from here?

Last piece I made defined pieces of a motive I will use and I'll call this an informal vision.

The informal vision

Setting: Sci-fi (Technology has made changes to the world and the idea is to use the context of the changes to present a message about something which may be more or less deeply hidden in a story or fantstic context. What the technology is will be part of the vision of the effort.)

Method: Roleplay (I'll pretend to be some entity within the context and define details of this entity partly during the development process starting up. This entity will be a band, which is a part of the technology in question.)

Background: A Story

The story in short:

A political party, The Network Party, created a new ideology based on mathematical proof of optimized average and total life value of all humans in the world. This was such a powerful ideology that the political party spread its rule to cover the world and save the planet earth from destruction by consumeralism and economic competition for resources. As the party gained strength it became obvious that mathematically proven principles are well managed by computers. This led to the ideology being implemented in code and thereby further optimized, the implementation was known as The Network of Organized Democracy, usually called The Network or "TN" as shortened by l33tspeeking people.

Humankind was now living an awesome life happily together and they decided to journey towards the stars. A few million years later humankind has spread across the vastness of space. To establish new colonies they sent robots which are connected to The Network. These robots spread propaganda for The Netowrk to alien worlds in preparation for the arrival of human tourists and adventurers.

The Network developed several series of propaganda robots, one of the successful brands travel through space in the form of musicians. They bring the glory of The Network through galaxies by playing songs which they modify iteratively towards fitting whichever alien species they encounter. They can also defend themselves if attacked, but they generally are peaceful. Humans can also purchase these robots directly from The Network by spending a decent lot of their consumption allowance on each robot.

Anyhow... the setting for the work in question is to create odd iterations of the robots propaganda music. This leaves me without any reason to worry about making anything which either attempts to sound real, natural or great. I can focus on the skills I think I can hone through the work.

The details is to roleplay the robots. And the robot band is known as:

Spaceforce

Vocals: All 4 robots participate in singing

Guitar: Roxxor

Drums: Tricklock

Keyboard: Schmooth

Bass: Doppz

The first job in the process of creating the next song in their setlist is to define the sounds of Tricklock. This time I'll aim at the Make it Flawless principle, meaning that I'll spend a lot of effort on getting the drum sounds of Tricklock. I think Tricklock will get his own post before I am done with him. Now to setting up a whole lot of samples in the drum machine... time to start working.

Practicing Agile on Art

To practice the kinds of principle which are described by Lean I started with creating a piece of music. I like making music, it is meditative and it uses some of my usually dormant skills which when I fire them back up gives me a serious dose of pleasurable feedback chemicals in my brain. Anyhow, creating music is an example of a very well defined production system and I like making abstract generalizations from things I know well to things I know less well. On the whole I can claim to be quite an efficient music production team all on my own, something I have a hard time claiming for the art of making games. Games require so much wider skill sets to go from idea to fully implemented in the cases that I am interested in so I can’t make a micro experiment to test the concepts of Lean development on my own with the game medium, and I can’t program well enough to make anything useful.

One of the great advantages with creating music is that I have access to a relatively decent implicit iterative method which covers the full production pipeline. I can tell if the instruments are tuned poorly, if the arrangement is busted and such technicalities. I can even tell if playing the instrument in the recording is giving a result which pleases the musician. This means that I pretty much know when I am cheating the creative process by accepting less than flawless components in the production. I can also cheat and get some explicit feedback from various sources such as sending snippets to friends over the internet or check details with a spectrum analyzer etc.

I also know that the end result is the interaction between the components and that I will not really be able to know in advance if a production will be good or not. I can generally feel it growing if I keep working on something which keeps me motivated. Almost everything which I ever finish is based on a mashup of old prototype songs. This mashup process is something similar to stage gate portfolio management which defines little pieces but without the information of how the pieces should interact to deliver an impression. This is also poorly managed by me with various references in my brain and plenty of broken snippets of recordings which I usually forget about. To bring this mess of components to life as something which I can claim to be something I finished I have to work through what my limited experience would label as a large process. I don’t like using samples, when I try I tend to get bogged down in editing the samples so its more efficient for me to just go straight at making the whole arrangements and tweaking the hell out the individual instruments.

The way I make music is fundamentally iterative. The goal is a mix of creation and refinery towards reaching greatness. Greatness is a state of perfect fit, “the goose bump factor”, an implementation which creates unique emotional response of some kind. This is hard work, I am rarely motivated enough to not give up and leave the effort as a part of the busted stage gate portfolio. It happens sometimes that I keep on going and the finished results are what I can use to run production technique experiment.

Writing this I sense that I will not be able to combine the whole argument in one big post. I will have to dig at details another time if I get there but I got some direct references at this point.

1 – Make it Flawless; applies to music production. This is a well known oldskool audio engineering principle which says that: “Make quality recordings of sounds; you can not make bad sounds good by tweaking them.” You can also not effectively engineer up a poor performance or a bad melody through creative editing, you can make it better yes, but you will be much less efficient than making the recording good in the first place. Compromising these early stages of the music production is like technical debt in software development, you can use them to move fast to a certain point but you will never reach greatness unless you go back at a later point and fix it. Such late fixes are often big risks as the new recording might interfere with the whole arrangement. This often leads to cascading failure of the whole production and all you get is yet another ambitious component of the stage gate portfolio.

2 – One piece Flow; this very much applies to music production. If you fail to follow it you will fail the Make it Flawless principle and learn to accept a poor result. The trick to one piece flow is to know your production method which is much easier in the world of music than when making games, especially for me since the process of making music in my case happily operates at a loss as long as I have fun with it. In the world of music production this goes through layers of development. You will benefit greatly from having the rough shape of the arrangement in place before starting to mix, you don’t start with the mix because then you will break the idea of one piece flow and en up with all pieces. The real question here is what the “one piece” is. In music the “one piece” is a multi dimensional argument. It can be used for an instrument, section, harmony, melody, mix, arrangement, lyrics and so on. The matter is the ability to identify the pieces and to learn how to be satisfied with one particular piece. This identification has its roots as a craftsmanship based on skills, theory and vision.

3 – Maintain multiple options; this is integrated with tools pipeline. In an ideal world I would call this “the mix” which is what you do last before sending the work to the ears of an audience. I am not sure if this is because I want the reference to fit or if it fits. The idea also carries through the arrangement by the theoretical structure of music theory. There is this huge set of lore which a master musician can use to apply multiple options to any given situation. I am not a master in this sense but I had an awesome Jazz teacher who showed me a few things about which doors can be opened to toss things around in a technically “legal” manner. It has been half a life time in my world since I had those lessons but their fundamental concept remains with me still. I’ll tell you the secret right here: All that theory is just a shortcut for connecting your ears to be the judge of what is good. It is a great shortcut and it is the key to collaboration and communication about the creative process of the medium. But it is nothing which resembles strict laws and the rules are there to be broken by the creator at will.

4 – Avoid Waste. This is a tricky beast, also very relevant to music. Defining what waste is in a music production is not that straight forward. Recording random things and putting them together is generally waste, sometimes it is a process which rapidly can fill up the stage gate with concepts. The real answer to the question of what waste is depends on the vision and goals of the production. If the goal is to increase the stage gate then an ambitious mix is waste, if the goal is to deliver on a vision then aimless noodling and random recording is waste. To know how to spot waste you need to be a well practiced craftsman of music creation.

My biggest problem for my music hobby is lack of vision. I like to blame this on the extremely efficient development method which gives me an extremely agile context. The studio software allows me to change anything at any time so I never feel like I have to spend any effort at creating a vision for the work. This makes it easy to get a false sense of progress towards greatness and the lack of vision rears its ugly head as technical debt within the whole arrangement which sends everything to the stage gate relatively often.

All of this stuff is generally applicable to most things in life. The biggest problem with implementing process optimizations toward value production is a lack of common grounds for communicating these kinds of ideas. Just as it is hard to make a band play good music without a fundamental common ground in music theory it becomes hard for a game developer to make good games without a common ground in development methodology and game design theory. Lack of common ground will require blind faith which is a rare human trait and it rarely lead to good results.

Quality Confusion

I find the concept of "quality" to be among the more abused components of game developmen and maybe even for artistic expression in general. The problem is that different people consider different things to be quality. The main stances towards quality which I am familiar with are something like this.

Engineering: Quality is when it works technically elegant.

Business: Quality is when it has obvious sellable features.

Art: Quality is making an impression.

Perfection: Quality is meeting established goals.

The more common among ordinary people is the perspective of business quality. People talk about the obvious sellable features when they talk about a product. They often and faulty equate a small number of features as a poor quality product. This flawed reasoning is the core motivator for me writing this post.

To start correcting the problem we have to change a little bit of what describes business quality. We have to replace the word “features” with “advantages”. After we have made this correction I will easily argue the stance that to reach high quality you have to nail all four of these perspectives.

Next problem is that the reasoning above really does not talk about quality the way I consider quality. I would call the above statements for “needs” which are base requirements for reaching ROI with anything. If losing money is desired then compromise on one or more of the perspectives.

Real quality is meeting all of the product needs without the existence of defects.

Quality is not a creation or induced by adding things, rather a result of a well balanced methodology. An arch enemy of quality is the misstake of associating ambition level with quality. This leads to the common problem of people claiming that small simple products are having “low quality” which is a fundamentally flawed argument. Those simple products are, when successful, rather reducing ambition for increasing quality.

Layers of iterative development process

All the layers in this image contain iterative process, of varying formal structure.

Note that each level also tend to be branched to different territories, at the bottom you have different types of experts or artists producing different types of work often through implicit iteration.

Goals

Straight from wikipedia: Goal Setting involves establishing specific, measurable and time targeted objectives.

This is a point of setting goals which which appear to be failed by teams that fail at agile development. A goal for a devlopment or I guess any business needs to be formulated in a manner which describes the state of things upon completion of the goal.

Following this principle is sometimes quite hard. Lots of the flak tossed at scrum lately can be aimed at the lack of useful goals.

Setting useful goals takes a whole lot of time and when a whole team is working on the problem together people often start showing signs of stress symptoms from feeling of wasting time. However having bad goals is worse than wasting time.