I have recently started working on a very low scale software synthesizer that, hopefully, will turn out quite nice. It has been some years since I last worked in the audio-field so my memory about the tedious details is quite rusty and needed heavy restoration.
The basic idea of my synthesizer is for it to be as small as possible in terms of compiled executable while still sounding good. It will all be compiled in C++, but without the use of inheritance and other language features that may add overhead to the final out come.
After only a couple of hours of hacking I have the basics up and running, i.e. I have a waveOut* wrapper that allows me to actually output the generated signal to the Wave Mapper of the current system. Also I have some basic oscilators, noise generators, reverb, quantifiers, envelopes and filters ready.
To give you guys a glimpse of what the code looks like I proudly present an exponential ADSR envelope that I made yesterday: http://pastebin.com/f4f84126d
Tuesday, July 10, 2007
Friday, July 6, 2007
Refactoring without Starting Over
Today I published a short article that I have been working on for a short period of time. It is being reviewed at Code Project and you may find the article using this link: Refactoring without Starting Over.
In the article I introduce a method of adding new features to your code base without having to refactor the majority of the existing code. The method makes use of the adapter design pattern and facade design pattern.
Read the article and let me know if you found it useful.
Friday, February 23, 2007
Yes, sir, I am certainly certifiable
Being a moden software developer means that one is periodically faced with the cruical facts of not having executed any of the planned post graduation examns. Following yet another follow-up meeting with my nearest manager I decided to work on becoming a Microsoft Certified Programmer; and voila today I took the test in 90 minutes (guestimated to take 180 minutes) and received a printed copy which states that I passed.
And what's the point of this rant? Well, I don't know; I guess I'm just in a good mood. My total incubation time from starting the prepation of the test till the final day was 5 working days with a total of 2 hours of study per day. The study consisted mainly of a Transcender test-cd (which is far more recommendable than those printed study guides out there!).
After the test I drove a colleague home and started a journey in the snow. A trip that normally takes ~40 minutes took my 150 minutes today -- all because of bad drivers (or the unexpected amounts of snow). When I got home I filmed this short clip with my cell phone:
Over and out,
Rasmus Kaae, Msc C.S. + MCP!
And what's the point of this rant? Well, I don't know; I guess I'm just in a good mood. My total incubation time from starting the prepation of the test till the final day was 5 working days with a total of 2 hours of study per day. The study consisted mainly of a Transcender test-cd (which is far more recommendable than those printed study guides out there!).
After the test I drove a colleague home and started a journey in the snow. A trip that normally takes ~40 minutes took my 150 minutes today -- all because of bad drivers (or the unexpected amounts of snow). When I got home I filmed this short clip with my cell phone:
Over and out,
Rasmus Kaae, Msc C.S. + MCP!
Wednesday, February 14, 2007
Review of "The Best Software Writing I: Selected and Introduced by Joel Spolsky"
Review of "The Best Software Writing I: Selected and Introduced by Joel Spolsky"
Last summer I had the pleasure of reading Joel Spolskys collection of great software writings found on the Internet. Joel Spolsky is the author of a very interestring blog covering many aspects ranging from code issues to management issues. A key word on Spolsky blog is good writing, thus this book.
The book I have is the first edition published back in June 2005, it has 328 pages and costs only $15,74 on amazon.com (now, that IS cheap!).
Why does articles covering software development written by developers for developers have to be boring, tedious and subsequently drown in unneccessary details? If you want to read an article about a new technology, method or similar it wouldn't hurt if the article wasn't dead boring. This is more or less covers the main motive of Joel Spolsky for generating the "Best Software Writing I" book. In his book Spolsky points out what he believes were the best 30 software development articles created in 2004-2005. The main source of the articles is the Internet, i.e. blogs, webpages or discussion boards. Selecting these articles has been done with great care and with an emphasis on the writing style rather than the actual content (to put it out loud).
In the introduction Joel Spolsky writes:
“The software development world desperately needs better writing. If I have to read another 2000 page book about some class library written by 16 separate people in broken ESL, I’m going to flip out. If I see another hardback book about object oriented models written with dense faux-academic pretentiousness, I’m not going to shelve it any more in the Fog Creek library: it’s going right in the recycle bin. If I have to read another spirited attack on Microsoft’s buggy code by an enthusiastic nine year old Trekkie on Slashdot, I might just poke my eyes out with a sharpened pencil. Stop it, stop it, stop it!”
Having this book as a reference guide on how to write interesting new articles on software development is key to new writers. Using this book (one can hope) that over time the quality of new articles published e.g. on Internet will rise. New writers will find their favorite Internet-celebrity in this book and may follow his example and be inspired by the writing styles applied. Among these Internet-celebrities we find Raymond Chen (Microsoft guru and developer), Ken Arnold (SUN Java developer), Adam Bosworth (Google guru) etc. whom all are known to have very good and interesting blogs on Internet. In addition to the Internet-celebrities the book also contains a range of articles written by either anonymous authors or simply unfamous authors.
My personal evaluation of the book is that it was very a very good read. Given the nature of the book, it contains articles of varying quality, however the quality of the good articles clearly over shaddow the (few) poor articles in the book. My personal favorites are from Raymond Chen, Eric Sink and Paul Graham. Their articles covers interesting subjects and the authors are very good at writing in a non-borring style.
Below is a list of articles from the book (more or less the table of contents) -- if you don't feel like buying the book a simple Google-search might find them for you:
Ken Arnold - Style Is Substance
Leon Bambrick - Award for the Silliest User Interface: Windows Search
Michael Bean - The Pitfalls of Outsourcing Programmers
Rory Blyth - Excel as a Database
Adam Bosworth - ICSOC04 Talk
danah boyd - Autistic Social Software
Raymond Chen - Why Not Just Block the Apps That Rely on Undocumented Behavior?
Kevin Cheng and Tom Chi - Kicking the Llama
Cory Doctorow - Save Canada's Internet from WIPO
ea_spouse - EA: The Human Story
Bruce Eckel - Strong Typing vs. Strong Testing
Paul Ford - Processing Processing
Paul Graham - Great Hackers
John Gruber - The Location Field is the New Command Line
Gregor Hohpe - Starbucks Does Not Use Two-Phase Commit
Ron Jeffries - Passion
Eric Johnson - C++ -- The Forgotten Trojan Horse
Eric Lippert - How Many Microsoft Employees Does it Take to Change a Lightbulb?
Michael "Rands" Lopp - What to do when you're screwed
Larry Osterman - Larry's Rules of Software Engineering #2: Measuring Testers by Test Metrics Doesn't
Mary Poppendieck - Team Compensation
Rick Schaut - Mac Word 6.0
Clay Shirky - A Group is its Own Worst Enemy
Clay Shirky - Group as User: Flaming and the Design of Social Software
Eric Sink - Closing the Gap
Eric Sink - Hazards of Hiring
Aaron Swartz - PowerPoint Remix
why the lucky stiff - A Quick (and Hopefully Painless) Ride Through Ruby (with Cartoon Foxes)
Sunday, February 4, 2007
Respharing game engines with design patterns - Prelude
Back in the days of naitivity and plenty of freetime I wrote an article on how to build a framework for a game engine based on well known design patterns. The article centers around a few basic design patterns and some very fundamental C++ code. Some years have gone by (read: 6) and many-many lessons learned has made me re-evaluate the whole concept. I will in the following update the basic concepts and modernise it all by showing code samples in C#.
In order to read the articles it is advised to have basic knowledge of C#, design patterns and general theoretical knowledge of abstract data types.
Design patterns are well known patterns that may help the programmer in the initial phase of a
programming project. They can be used as a guideline on how to fragment and divide the functions of a program into smaller fragments. I will discuss my point of view on how to
structure a game engine, using available design patterns. My knowledge mainly comes from
personal experiences and from my study at the computer science department of Aarhus University. There are many different design patterns and they all have different purposes and useability.
Looking at a game engine there are a multitude of aspects to take in consideration. A major factor is performance and efficiency of the code, another important factor is maintainability and knowledge sharing. The latter is especially important when working in a team. My approach is centered around a handful of essential design patterns that all shine at whatever abstraction level they are reflected at.
In order to read the articles it is advised to have basic knowledge of C#, design patterns and general theoretical knowledge of abstract data types.
Design patterns are well known patterns that may help the programmer in the initial phase of a
programming project. They can be used as a guideline on how to fragment and divide the functions of a program into smaller fragments. I will discuss my point of view on how to
structure a game engine, using available design patterns. My knowledge mainly comes from
personal experiences and from my study at the computer science department of Aarhus University. There are many different design patterns and they all have different purposes and useability.
Looking at a game engine there are a multitude of aspects to take in consideration. A major factor is performance and efficiency of the code, another important factor is maintainability and knowledge sharing. The latter is especially important when working in a team. My approach is centered around a handful of essential design patterns that all shine at whatever abstraction level they are reflected at.
Wednesday, January 31, 2007
How to generate a problem
Whenever an interface is described as being generic and platform independant one should never blindly trust it. This is a short story of why ...
Some time ago I was involved in a project concerning constructing and deploying a simple .NET webservice interface to a core library that we develop in house. The need for the webservice interface was introduced by a very large international customer, so there was no way around it. Well, actually the customer just wanted a way to access the library from a server running a non-supported operating system. Where "non-supported operating system" should be read as an operating system that once was supported and now is so old that our product managers decided to cut the line. Doing so has an immediate impact on the amount maintaince :-)
So, this webservice was designated to convert back and forth between two military media, which shall remain nameless for no obvious reason. We, the developers, chose to implement the required feature as a webservice in .NET facilitating the SOAP standard protocol. Using standard tools and protocols should guarantee that the customer was able to interface the webservice seamlessly.
After releasing our product including the webservice a customer reported an issue concerning non-US characters in the data. When the customer invokes the webservice with data containing non-US character data the customers application fails to read the output of the webservice call. Such an inquiry is normally regarded as user fault, indicating that the bug was at their end. However, due to the importance of the customer we started debugging the issue. After several hours of debugging strange runtime environments I concluded that the fault was partly the customers issue (and partly our own). The issue was caused by the nature of the data transmitted which was in local code page of the system (which was a requirement). However, transmitting code page data over a UTF-8 encoded medium is not a clever move, seeing that non-US characters are represented as a multi byte encoding in UTF-8 and a single byte representation in local code page.
Our soloution was the base-64 encode the transmitted data, this prevents any mangling and incompatible data in the UTF-8 encoded SOAP XML Envelope. This fixes the problem and everything is jolly good - or is it?
Of course not, the data also needed to be encoded on the user end. As it turns out using different Java SOAP integration kits have different results. Some encodes the string flawlessly and lets the communication between the user application and our webservice work correct, while other kits fails to encode properly and thus provoke our webservice.
Another unforseen event was that the user application was written in Java, which uses 16-bit string representation. This is not a problem, however it is a problem when the developer at the customer end believes that UNICODE is the same be it UTF-7, UTF-8, UTF-16, etc.
So what was the morale of todays story? Never trust that anyone else knows what you are doing. If you need to publish an interface, make sure it is well documented.
Some time ago I was involved in a project concerning constructing and deploying a simple .NET webservice interface to a core library that we develop in house. The need for the webservice interface was introduced by a very large international customer, so there was no way around it. Well, actually the customer just wanted a way to access the library from a server running a non-supported operating system. Where "non-supported operating system" should be read as an operating system that once was supported and now is so old that our product managers decided to cut the line. Doing so has an immediate impact on the amount maintaince :-)
So, this webservice was designated to convert back and forth between two military media, which shall remain nameless for no obvious reason. We, the developers, chose to implement the required feature as a webservice in .NET facilitating the SOAP standard protocol. Using standard tools and protocols should guarantee that the customer was able to interface the webservice seamlessly.
After releasing our product including the webservice a customer reported an issue concerning non-US characters in the data. When the customer invokes the webservice with data containing non-US character data the customers application fails to read the output of the webservice call. Such an inquiry is normally regarded as user fault, indicating that the bug was at their end. However, due to the importance of the customer we started debugging the issue. After several hours of debugging strange runtime environments I concluded that the fault was partly the customers issue (and partly our own). The issue was caused by the nature of the data transmitted which was in local code page of the system (which was a requirement). However, transmitting code page data over a UTF-8 encoded medium is not a clever move, seeing that non-US characters are represented as a multi byte encoding in UTF-8 and a single byte representation in local code page.
Our soloution was the base-64 encode the transmitted data, this prevents any mangling and incompatible data in the UTF-8 encoded SOAP XML Envelope. This fixes the problem and everything is jolly good - or is it?
Of course not, the data also needed to be encoded on the user end. As it turns out using different Java SOAP integration kits have different results. Some encodes the string flawlessly and lets the communication between the user application and our webservice work correct, while other kits fails to encode properly and thus provoke our webservice.
Another unforseen event was that the user application was written in Java, which uses 16-bit string representation. This is not a problem, however it is a problem when the developer at the customer end believes that UNICODE is the same be it UTF-7, UTF-8, UTF-16, etc.
So what was the morale of todays story? Never trust that anyone else knows what you are doing. If you need to publish an interface, make sure it is well documented.
Tuesday, January 30, 2007
A wide selection of random C++ code
Looking through the archives of my past websites I stumbled over some long forgotten C++ code. The code is not neat, efficient or prepared for public display, however someone in cyberspace may find it useful (for whatever reason).
Subscribe to:
Posts (Atom)