Mrs Pudenda

1. /* // C Programming 101 – Mrs Pudenda – for loop assignment #2 */
2. #include <stdio.h>
3.  
4.  
5. #define DANGER_DIVIDE_BY_ZERO(o,b,g,y,n,k) enum
6. #define PLETHORA_MAX(l,m,n) int
7. #define TAIL_RECURSION else
8. #define case_switch(m) if(m)
9. #define on_screen(y) putchar(y)
10. #define TELEPORT(x) goto x
11. #define SAVOR return
12. #define FLAVOUR 0
13. #define CHERRIES main
14. #define CHOCOLATE_RASPBERRIES 74
15. #define WILL_ROBINSON foul_your_pets
16. #define HTML main
17. #define BODY {
18. #define BODY_END }
19. #define MY_EOL ;
20.  
21. DANGER_DIVIDE_BY_ZERO(‘w’,‘t’,‘f’,‘b’,‘b’,‘q’) WILL_ROBINSON
22. BODY
23.         LEGO_MY_EGGO = 0,
24.         WEIRDO,
25.         THE_TOASTER_IS_ON_FIRE = CHOCOLATE_RASPBERRIES,
26.         BAD_TOUCH
27. BODY_END MY_EOL
28.  
29. #define D(p) (LEGO_MY_EGGO + 108)
30. #define I(o) (LEGO_MY_EGGO + 111)
31. #define C(o) (THE_TOASTER_IS_ON_FIRE + 37)
32. #define K(p) (THE_TOASTER_IS_ON_FIRE – LEGO_MY_EGGO * 1 + 36 + 2)
33.  
34.  
35. int HTML(void)
36. BODY
37.         PLETHORA_MAX(‘a’,‘r’,’s’) loop_value_which_designates_increasing_or_decreasing_depending_on_your_loop_type;
38.  
39.         /* C++ compatibile comments */
40.         /* // Initialize loop_value_which_designates_increasing_or_decreasing_depending_on_your_loop_type */
41.         loop_value_which_designates_increasing_or_decreasing_depending_on_your_loop_type = LEGO_MY_EGGO MY_EOL
42.  
43.         /* // Set loop_value_which_designates_increasing_or_decreasing_depending_on_your_loop_type to the value, turn your cellphone off */
44.         loop_value_which_designates_increasing_or_decreasing_depending_on_your_loop_type = 4 MY_EOL
45.  
46. GOTO_HERE:
47.         /* // TODO: make into function */
48.         on_screen(D(‘p’))MY_EOL
49.         on_screen(I(‘o’))MY_EOL
50.         on_screen(C(‘o’))MY_EOL
51.         on_screen(K(‘p’))MY_EOL
52.  
53.         case_switch(–loop_value_which_designates_increasing_or_decreasing_depending_on_your_loop_type)
54.         BODY
55.                 TELEPORT(GOTO_HERE) MY_EOL
56.         BODY_END
57.         TAIL_RECURSION
58.         BODY
59.                 TELEPORT(GOTO_THERE) MY_EOL
60.         BODY_END
61.  
62. GOTO_THERE:
63.         /* // #C freenode, y this not print below????????? */
64.         /* // We are done. now. */
65.  
66.         SAVOR FLAVOUR MY_EOL
67. BODY_END

Master of Puppets and Alternate vs Sweep Picking

While trying to learn to play “Master of Puppets” (still a work in progress…) I had a hard time with the main riff of the song (which can be found at around 30 seconds). The riff looks like this:

sA:-----2-----3-----4-----3-----2-2-
sE:-0-1---0-1---0-1---0-1---0-1-----
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D-U-    Measure A
pS:-U-D-U-U-D-U-U-D-U-U-D-U-U-D-U-D-
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1
                      0 1 2 3 4 5 6

sA:-----2-----3-----4-----3----(2--)
sE:-0-1---0-1---0-1---0-1---0-1-----
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D---    Measure B
pS:-U-D-U-U-D-U-U-D-U-U-D-U-U-D-U---
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1
                    0 1 2 3 4 5

sA:-----2-----3-----4-----3-----2-2-
sE:-0-1---0-1---0-1---0-1---0-1-----
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D-U-    Measure C
pS:-U-D-U-U-D-U-U-D-U-U-D-U-U-D-U-D-
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1
                      0 1 2 3 4 5 6

sA:-----2-----3---------------------
sE:-0-1---0-1---1-0-3-2-0-3-2-0-3-2-
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D---    Measure D
pS:-U-D-U-U-D-U-U-D-D-U-D-U-D-U-D---
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1
                      0 1 2 3 4 5 6

sA = the string A
sE = the string E
pA = Alternate picking
pS = Sweep picking
ac = Accenting
bt = Beat number (of current measure)
nt = Note number (of current measure)

At first look, it seems very simple, but its very clever and powerful and smells “Metallica” all over it.

Riff anatomy

The riff consists of 4 almost identical measures of 4 beats each. Let’s call them A, B, C, D. All the notes are 16ths with the exception of the final note (15) of measure B which is an 8th. There is a repeating pattern of 3 notes: E,F,X, E and F being the constant notes of the pattern and X being the one that changes in each instance of the pattern. Let’s call the pattern “PAT”. PAT is not aligned with beats (one beat is four notes) and so each repetition sounds differently in terms of accenting from the previous one.

Measure A consists of 5 repetitions of PAT and adds a twist at the end. The final note (note 15) repeats once more and this effectively brings the 3 note “misfit” to an end for the current measure so the next measure can start off new. Its like a full stop ending a sentence.

Measure B ends with a similar twist. This time there is no full stop note, but instead the value of this note was added to the previews one (note 15 of measure B), which now lasts twice than the same note of measure A and the result is again the same.

The importance of the full stop note is that it resets the next measure of the riff and lets it start beat-aligned. Being beat-aligned is important because one of the key elements of the riff is the differentiation in accenting of successive repetitions of PAT. See the accenting in notes 1 to 3 (*-*) and the accenting in notes 4-6 (-*-). This differentiation is what gives the riff its own character.

Try repeatidly playing the riff without the “full stop note” (note 16) and you’ll see what I’m talking about. After 3 repetitions or so it will start imposing a different rhythm to your head (maybe 3/4) and lose all its character. Without this little twist the riff would have been a predictable repetition of nonsense. And certainly that is not what Metallica is about!

Measure B can be seen as a mutation of measure A. They are almost the same except from the double valued note 15.

The other half of the riff (measures C and D) can also be seen as a mutation of the first half (measures A and B), but this time the changes are  more drastic. After 2 repetitions of  PAT in the D measure, the E and F notes change place. This puts an end to the ascending motion of the previews notes of the riff. Then the remaining beats (3 and 4) of the D measure are totally different from these at measure B. The PAT is gone and its place was taken by another pattern: a 3-note repetition of G, F# E,  again a decending motion  The rule of PAT is gone and so is the predictability of the riff. You stop expecting to listen to any more PAT repetitions, anymore. But there comes the next repetition of the whole riff (and a whole lot of PAT repetitions inside it) to prove you wrong!

The next repetition of the riff (say measures E, F, G and H) is also a mutation of the first repetition (measures A, B, C, D). Measure H is exactly like measure D but now it has grown two beats larger! (Ok, technically the measure did not mutate. Technically measure H is the same as D and another one measure of two beats was added after it, but we can still say that the musical phrase was mutated and that the mutation was an “insertion”). Those extra two beats are simply a repetition of beats 3 and 4 of measure H.

Another way to look at these extra beats is that they are not extra at all. Maybe they form a complete measure together with beats 3 and 4 of so-called “measure H”. Maybe the story told so far with the PATs and the mutations was not the one aligned with measures and from now on the alignment is going to be correct. Time to tell the true story. Time to go to the verse section of the song!

Application of sweep picking

When I started writing down the tablature for this post I thought I was only going to write about my little trick for playing the riff faster and with less effort. I could not resist the temptation of writing some of my thoughts about it though, not only because it kicks ass, but also because its structure conveys that the creator of the riff (Kirk?) followed some kind of methodology and put an awful lot of work in tweaking the parameters of the system until it was perfect.

I could continue sharing my thoughts on this riff for many pages, for example I could say that it sounds good enough even when you ignore notes on one of the two strings (ignore string A and you get a kick ass rhythm, ignore string E and you get a decent musical phrase), or I could say how this structure reminds me of evolution and how this brings a sense of “life” to the riff. But I’m definitely not going to say these things! Let’s see that tab again:

sA:-----2-----3-----4-----3-----2-2-
sE:-0-1---0-1---0-1---0-1---0-1-----
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D-U-    Measure A
pS:-U-D-U-U-D-U-U-D-U-U-D-U-U-D-U-D-
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1
                      0 1 2 3 4 5 6

sA:-----2-----3-----4-----3----(2--)
sE:-0-1---0-1---0-1---0-1---0-1-----
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D---    Measure B
pS:-U-D-U-U-D-U-U-D-U-U-D-U-U-D-U---
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1
                    0 1 2 3 4 5

sA:-----2-----3-----4-----3-----2-2-
sE:-0-1---0-1---0-1---0-1---0-1-----
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D-U-    Measure C
pS:-U-D-U-U-D-U-U-D-U-U-D-U-U-D-U-D-
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1
                      0 1 2 3 4 5 6

sA:-----2-----3---------------------
sE:-0-1---0-1---1-0-3-2-0-3-2-0-3-2-
pA:-D-U-D-U-D-U-D-U-D-U-D-U-D-U-D---    Measure D
pS:-U-D-U-U-D-U-U-D-D-U-D-U-D-U-D---
ac: *   *   *   *   *   *   *   *
bt: 1       2       3       4
nt: 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1
                      0 1 2 3 4 5 6

sA = the string A
sE = the string E
pA = Alternate picking
pS = Sweep picking
ac = Accenting
bt = Beat number (of current measure)
nt = Note number (of current measure)

So my first approach to learning how to play it was alternate picking. I sat with the metronome and started really slow, but at some point as I was increasing the speed I caught myself using another pattern which came to me more naturally than alternate picking. I tried to slow it down again to analyze what I was doing and I was amazed to see that I was actually sweep picking the riff (because I had never done any sweep picking exercises before). This approach has its pros and cons, but it definitely had me playing the riff at a decent speed in no time!

Look at the tablature to see how to do it: U stands for upstroke and D stands for downstroke. Basically you start the riff with an upstroke and when you have to play the string A and then the string E you play them both with a single sweep.

Pros

+ Speed: In the sweep picking version you just need 12 movements per measure instead of 16.
+ consistency: Your hand’s motion is aligned with the 3 note pattern “PAT” and not with the beat (the latter being the case with alternate picking). This way if you miss a note you don’t get lost and you can continue playing the riff as if nothing happened. Try the same with alternate picking.

Cons

- It won’t make you a better guitarist: This trick is not reusable. It applies only to this specific riff. Alternate picking on the other hand can be used everywhere and its a good habit to use it even when it does not feel so comfortable.
- Non automatic accenting: With alternate picking you let your hand do the accenting (accent downstrokes and don’t accent upstrokes). On the other hand (!) with sweep picking you must accent the notes when they really need to be accented, not when your hands think so. It’s a little more tricky to get right.

Considering all these I think it was worth the effort: I learned the riff a lot easier and when the time comes to play it live I won’t screw it up in case I miss a single note. Even if it happens to be the full stop.

Qurashee makes you bad!

Some words have a very interesting history. One of my favourites, the greek word “μοχθηρός” (mohthiros) has indeed a very interesting etyomolgy. The word comes from “μόχθος” (mohthos – tiredness) and literally means “One who gets (physically) tired” (or a hard worker) but over the years its meaning has changed and its current meaning in modern Greek is “malicius“.

The same thing has happened to the word “πονηρός” (poniros). The word comes from “πόνος” (ponos – physical pain), its literal meaning is “one who receives (physical) pain” (mostly meaning again a very hard worker), and its current meaning is “cunning / tricky” (person).

The history of these words implies that hard workers eventually become evil, because of the difficulties they had in their lives, so the moral of the story is: “Take a break every now and then or you may end up a bad person”!

I’d better go back to work now to catch that deadline

Using custom I/O callbacks with ffmpeg

Video playback in Conspiracies 2 is based on ffmpeg, which is a very fast and easy to use library. I got better results than using DirectShow with less effort and not to mention my video playback code is going to compile everywhere!

Following this tutorial got me started immediately. After an afternoon of coding I had a decent video player running. This tutorial shows you how to play videos from a file in the filesystem. What I needed was a little bit different though. All the assets of the game (including videos) exist in a “virtual file system” in archives. So I need to provide my own I/O functions for reading them. ffmpeg provides this functionality but it is a little bit tricky to figure out, so I thought I’d write this guide here for future reference. Thanks to the kind people at libav-user mailing list who helped me sort this out!

Implementing the I/O routines.

There are 3 routines you need to impement:

int ReadFunc(void *opaque, uint8_t *buf, int buf_size);

This function must read “buf_size” number of bytes from your file handle (which is the “opaque” parameter) and store the data into “buf”. The return value is the number of bytes actually read from your file handle. If the function fails you must return <0.

int WriteFunc(void *opaque, uint8_t *buf, int buf_size);

This is optional and behaves like the ReadFunc.

int64_t SeekFunc(void *opaque, int64_t offset, int whence) ;

This function is like the fseek() C stdio function. “whence” can be either one of the standard C values (SEEK_SET, SEEK_CUR, SEEK_END) or one more value: AVSEEK_SIZE.

When “whence” has this value, your seek function must not seek but return the size of your file handle in bytes. This is also optional and if you don’t implement it you must return <0.

Otherwise you must return the current position of your stream  in bytes (that is, after the seeking is performed). If the seek has failed you must return <0.

Opening your custom stream.

So when you need to open a custom stream for reading you must do the following:

• Allocate a buffer for I/O operations with your custom stream. The buffer’s size must be (n + FF_INPUT_BUFFER_PADDING_SIZE), where n is the actual useful buffer size.

• Allocate a new ByteIOContext object and initialize it by calling init_put_byte():

  int init_put_byte	(	ByteIOContext *	s,
  		unsigned char *	buffer,
  		int	buffer_size,
  		int	write_flag,
  		void *	opaque,
  		int(*)(void *opaque, uint8_t *buf, int buf_size)	read_packet,
  		int(*)(void *opaque, uint8_t *buf, int buf_size)	write_packet,
  		int64_t(*)(void *opaque, int64_t offset, int whence)	seek
  	)

  s is a pointer to your ByteIOContext object.
  buffer is a pointer to your allocated buffer
  buffer_size is “n” (the useful portion of your allocated buffer)
  write_flag must be zero if your stream does not support writing
  opaque is a pointer to your custom file stream. This is going to be passed to your custom routines.
  read_packet, write_packet and seek are pointers to your custom routines. write_packet is optional (it can be NULL)

• Use av_open_input_stream() instead of av_open_input_file() to open your stream:
  

  int av_open_input_stream	(	AVFormatContext **	ic_ptr,
  		ByteIOContext *	pb,
  		const char *	filename,
  		AVInputFormat *	fmt,
  		AVFormatParameters *	ap
  	)

  ic_ptr, filename, fmt and ap are the same parameters you use with av_open_input_file().
  pb is your initialized ByteIOContext object.

Closing your custom stream.

• When you are done with the stream call av_close_input_stream() instead of av_close input_file().
• Deallocate your ByteIOContext object.
• Deallocate your buffer.

That’s it! Everything else is the same as with av_open_input_file().

Changed vcache license to MIT

I thought that GPL v3 was too restricting for such a small piece of code, so I changed the license to MIT hoping that more people are going to use it.

Vertex Cache Optimisation Library

While working hard to make sure Conspiracies 2 is ready in time, I could not resist the temptation to tweak and optimize rendering a little more. This time I experimented with vertex cache optimizations and came up with a small piece of code that I thought it would be nice to share with the coders out there, since it is self-contained and easy to use.

The library consists of a single header file that -at least in theory- can be used with any C++ compiler, though it was only tested with visual studio. It implements the algorithm descibed at:

http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html

Its usage is extremely simple: just initialize a VertexCacheOptimizer object and call the member function “Optimize”, passing your index buffer and triangle count.

Download the code from:

http://code.google.com/p/vcacne/

The downloadable archive contains documentation and a small test-benchmark program.

My results for optimizing generated plane meshes are very consistent (my CPU is a Athlon 64 x2 4400+ running at 2.22 GHz):

• 143 nanoseconds per triangle
• resulting ACMR of ~0.63 (0.63 cache misses per triangle)

The algorithm indeed runs in linear time. I always got 143 nper triangle no matter how large or small meshes I used.

Have some fun with it. Any kind of feedback is welcome. I am particularly interested in your benhmarking results and/or comparisons with other vertex cache optimizers.

Multipass Rendering #2

After thinking about it for a while, there is also another aspect about multipass lighting I always feared, and its really trivial to handle, just like fog.

Transparent objects are rendered the same way as fogged objects: the final shaded pixel is linearly interpolated with a color, just like fog, but this time the color comes from the destination pixel. If you do the math,or if you take a look at my previews post, it becomes clear that transparent objects can easily be multiopass lit. Both techniques can also be combined as well.

In the case of both transparent and fogged objects the final color is calculated like this:

final_color = lerp(dest_color, fogged_shaded_color, alpha)
<==>
final_color = dest_color * (1-alpha) + fogged_shaded_color * alpha (1)

Let A = dest_color * (1-alpha), (1) becomes:

final_color = A + fogged_shaded_color * alpha (2)

where:

fogged_shaded_color = lerp(fog_color, P1 + … + Pn, fog_factor)  (P1 = first pass shaded color, Pn = nth pass)
<==>
fogged_shaded_color = fog_color * (1 – fog_factor) + ( P1 + … + Pn) * fog_factor (3)

Let F = fog_color * (1 – fog_factor), (3) becomes:

fogged_shaded_color = F + ( P1 + … + Pn) * fog_factor (4)

Combine (2) with (4):

final_color = A + (F + ( P1 + … + Pn) * fog_factor) * alpha
<==>
final_color = A + F * alpha + ( P1 + … + Pn) * fog_factor * alpha
<==>
final_color = A + F * alpha +  P1*fog_factor*alpha + … + Pn*fog_factor*alpha

Substitute A and F again:

final_color = dest_color * (1-alpha) + ( fog_color * (1 – fog_factor) +  P1*fog_factor) * alpha + … + Pn*fog_factor*alpha
<==>
final_color = lerp(dest_color, lerp(fog_color, P1, fog_factor), alpha) + … + Pn*fog_factor*alpha

“lerp(dest_color, lerp(fog_color, P1, fog_factor), alpha)” is a normal pass with fog and dest_color terms intact (not zeroed). So the first pass is performed normally.

Now let’s see what happens with the subsequent passes. They are of the form:

additive_pass_n = Pn * fog_factor * alpha

which is equivalent to:

additive_pass_n = lerp(ZERO, Pn, fog_factor) * alpha

Which is a little different pass, with fog_color = black as we already saw, the dst blend factor set to GL_ONE, as usually is the case with additive passes, but the src blend factor set to GL_SRC_ALPHA instead of the typical GL_ONE, because we want our shaded result multiplied by the alpha value.

So in short:

1. Multipass fogging is as easy as setting the fog color to black after the first normal pass.
2. Multipass alpha blending is done in essentially the same way, just do the first pass normally, and then do the subsequent passes with src blend factor set to GL_SRC_ALPHA and dst blend factor set to GL_ONE.
3. Both techniques can be combined together.

So after all multipass lighting is not so difficult to program! Actually it is easier than trying to add all the lights affecting an object to the same shader. The latter aproach may be more optimized but it’s very troublesome to manage (or generate?) the combinational explosion of shaders having 1, 2 ,3 or more lights where each of the lights can be of any type.

PS: You can use these techniques even with what I call “semi-multipass” lighting, when 2 or more lights are rendered at the same pass. If you don’t believe me, just do the math

Handling fog with multipass lighting

The thought of fog problems with multipass lighting has prevented me from using multipass in my renderers for too long. Today I decided to stop and think about it for a minute, and the solution is very simple!

Fog is implemented as a linear interpolation between the shaded color of the pixel and the fog color, using a fog factor. In my case the fog factor is calculated like this:

float fog_factor = exp2(-abs(view_dist * fog density));

and here is the cg code for calculating the final color:

final_color = lerp(fog_color, final_color, fog_factor);

which is equivalent to:

final_color = fog_color * (1.0 – fog_factor) + final_color * fog_factor;

when multipass lighting is used, fog should be applied to the final color (the sum of all passes):

final_color = fog_color * (1.0 – fog_factor) + (pass1_color + … + passn_color) * fog_factor;

or:

final_color = fog_color * (1.0 – fog_factor) + pass1_color * fog_factor + … + passn_color * fog_factor;

or:

final_color = lerp(fog_color, final_color, fog_factor) + pass2_color * fog_factor + … + passn_color * fog_factor;

So the first pass is rendered normally, as in single pass rendering, but the next passes are drawn without adding “fog_color * (1.0 – fog_factor)” each time. We have two options to implement this:

• Write separate shaders for the first and for the subsequent passes, or
• Make the term “fog_color * (1.0 – fog_factor)” be equal to zero in all passes except the first.

The first option might seem a little more oprimized at first, because it eliminates one or two instructions, but in fact it isn’t. The cg manual states that it’s better to use standard library functions, like “lerp”, than coding them on your own, because they are more optimized.

On top of being more optimized, the second option is also more convenient, because you don’t need to maintain separate shaders with no fog term. You just zero the fog term

So how can we zero the fog term? If you are reading this I think I don’t need to tell you (in fact I shouldn’t have even argued about why the second approach is better …).

Ok, ok ….

Short answer: Do the first pass normally, and the rest of the passes with fog enabled and set the fog color to black.

Hello, World!

This is the first post of my blog.

About me

My name is Michael Georgoulopoulos and I live in Athens, Greece. My interests involve Coding, Music and Biology. I work as a Game Programmer and play the guitar. At the same time I study Biology at the National and Kapodistrian University of Athens. Despite my involvement in so many subjects, I always try to ensure that the knowledge I gain out of them, as well as the use of it are -to some extent- perfect. I don’t consider any of my occupations a hobby, so inevitably each one gets its own share of my time and holds back the others.

But that’s not necessarily bad!

Procrastination

I am a procrastinator. I very much enjoy starting new projects and I do so with excitement. But there comes a time when the project starts becoming boring and repetitive, so I quickly lose my interest and procrastinate.

Here, the concept of the many interests fits very well. When I get bored doing one thing, the other two come to the rescue and I handle them with renewed excitement. This way, procrastination becomes a tool, not a problem!

So my progress with Coding, Music and Biology takes place at my slow-but-steady pace, and despite the fact that I procrastinate, I don’t lose a second of my time. I have come to the conclusion that you can’t cure procrastination, but you can get around it.

Try Googling “Constructive Procrastination”!

Why this Blog?

So many times I happen to have an “Outstanding New Idea” about something. Most of the times it has to do with one of my interests, or a combination of them. For example “Use your electric guitar as a computer keyboard”! As you can see, many times my ideas don’t try to solve some practical everyday problem! Other times they do. The thing is that most of the times I just forget them. I have tried to write them down in a notebook, but I ended up having many notebooks where the first page contains an “Outstanding New Idea”, and the rest of them were used for more practical reasons (like shopping lists!).

So I decided from now on, to write them all here, in the hopes that they will become inspirational to someone (or even me). Sure thing is I will not use this blog for my shopping lists. It doesn’t even make sense!

Organization

My posts will be organized in categories : “Coding”, “Music”, “Biology” will be the categories which will accommodate my thoughts about the specific subjects, only when they have to do with everyday problems and solutions. “Qurashee” will be the category under which I am going to post 100% useless stuff, like the “electric guitar as a computer keyboard”, which besides not trying to solve a particular problem (most likely they will create new ones, like the need for a replacement sound card!), have the value that someone took the time and got tired to implement them, with no reason at all. “Qurashee” is the pronunciation of the Greek word “Κούραση” (=tiredness). It means exactly this : someone got very tired with no obvious reason, and he is trying to get other people tired too!

So if you feel like getting a little tired, come this way!