It is done! The first alpha release of Halebopp, nicknamed "Kokino" is now available for the popular Ubuntu Linux platform.
Kokino is an ancient megalithic observatory in Macedonia, used to track the movement of sun and moon on the eastern horizon. Just like Kokino is one of the first primitive attempts of humans to touch the sky, our first release of Halebopp is meant to be only the first step of an ambitious project: a music composition application for everybody.
The source code is available at our development site at Google Code. If you need assistance or you want to take part in the development process, feel free to join the Halebopp Alpha Users Group. There are still 34 free seats left :)
Thanks to everybody who participated in this release!
Sunday, December 14, 2008
Friday, December 12, 2008
Halebopp Versioning & Our Release Needs a Nickname
This is a message forwarded from the Halebopp Alpha Users group:
Hi everyone,
Hi everyone,
I am in the process of preparing the release of the first alpha version of Halebopp. I hope everyone's eagerly anticipating the release. It's not going to be a totally awesome version, but it is, I hope, a good start for a new way to do computer music.
We are going to utilize a versioning scheme that's a mix between Ubuntu's versioning scheme and a proposal by kernel developer Greg Kroah-Hartman. Versions will be numbered by the scheme YEAR.MONTH.RELEASE
I was thinking that perhaps it would be fun if each release had a nickname, to honor someone or something important in the fields of space exploration, science fiction or astronomy.
If you have a great suggestion for a nickname, please do not hesitate to hit reply and write it down. It might need a little Wikipedia research. Whatever I like best will be picked for the release. If you state a reason for the name it has greater chances of being selected.
Thursday, December 11, 2008
Where "Halebopp" comes from...
While we wait for the weekend, and invite even more people to join the Halebopp Alpha Users mailing list (please tell your friends and your favorite forum!), here is a little treat. Halebopp is of course named after the famous comet, but also after this track, which I have particularly fond memories of:
Wednesday, December 10, 2008
Will Halebopp Earn Money and Continue to be Developed?
I wanted to write this as a simple comment reply, but I thought it is too important to be hidden in a comment section, and wanted to share it with you. Here it goes.
Michael wrote, in reply to my business model proposal:
Will this eventually earn you money, or only cover the cost of the support? I should hope the former is the case, although I imagine that will depend entirely on how much support you actually have to 'supply'?
I personally do prefer to pay for my software, as it enables much more rapid development (unless the company in question has grown so much, any new idea needs to go through 5 layers of executive red tape, ofcourse), and certainty that your favourite software's development won't be abandoned anytime soon. Although I must say I have recently lost my faith in 1-man development teams, I wish you all the best, and will be following Halebopp with interest!
Hi Michael, good questions, I am glad that you asked. I will start with detailing the current situation, followed by a more in-depth explanation of the underlying assumptions for the business model pick, and why I think that we made a good choice.
I am currently employed, and, although looking for a new job, will work in my free time on Largemind and Halebopp.
Secondly, I only develop software that I need and would use myself. This ensures that the software is practical and tested. Since I am also a composer as much as I am a developer, I am dependent on Halebopp just as my customers are. This software is the result of 16 years of experience with computer music and accumulates a lot of ideas about what composing should be like.
I am also confident that a lot of support will come from the community, in the form of patches and documentation. I have made very good experiences with open source while developing Aldrin. Should I ever have an accident and pass away, Halebopp is not lost. I care a big deal about source code documentation. The project is licenced in such a way that anyone could pick it up and continue developing it.
Now a few words about the viability of the business model.
To be honest with you, I have no idea if this business model will ever be profitable. As far as I know, there are several companies working with this model exclusively (Canonical being the biggest), but they all still run on venture capital and none of them is profitable, to my knowledge. This is a very new business model.
I still believe though, that this model is in the best interest of customers. Let me try an explanation: if you pay for a software upfront, it says nothing about its future potential. You only pay for what you get. But applications are never finished. When people get used to the work flow and wish for more, they do not want a different program immediately. What they expect is improvements to the application that they are using. That is a sane position. Software developers have relied on this custom for decades, and should therefore always work in the customers best interest, but often enough, it does not work out so well for the customer. People favor to buy upgrades for new features, not for bug fixes. Therefore, over time, applications become cluttered with features, while some bugs introduced by previous versions remain unfixed - sometimes even for years.
You could fix that through subscriptions, where payments stop when developers neglect their responsibilities. But people do want to own their software. They do not want someone else to decide when and where they can or can not use their tools. That is, again, a practical viewpoint, which must be respected.
Finally, there is a huge advantage in giving out a product for free, for both customers and vendors. As a customer, you can use the software free of charge. If you recommend it to your friends, they can get started immediately as well. There is no software piracy, and hence no serial numbers, no dongles or any of that nonsense. As a vendor, you profit from the tendency of people to get accustomed to the software. People recommend more. Blogs run wild. Magazines write about it without hesitation. And there are advantages on the development side: open source licenses allow developers to incorporate third party libraries more easily. Technical enthusiasts submit patches or write tutorials and documentation.
But where does the money come from? We have seen a large increase in social capitalism in the last years: few pay for many. At first sight, that might look like ripping off those who spend. But that is not the case. With traditional product marketing, you were only paying for one unit. If that unit or the support for it was not meeting your expectations, all you could do was waving your fist, asking for your money back, and hoping everyone else was doing the same - which is usually not the case. With social capitalism, you pay not only for your own unit, but for a large margin of free units as well. That makes you a patron of the company and therefore, gives you more power. You represent more customers, so your voice is more important.
On these assumptions rests our business model. We will give out free versions, but we will stress that buying a warranted supported version gives you influence and peace of mind. Therefore, paying customers will be those who "care more", and these are the people we need to listen to.
Michael wrote, in reply to my business model proposal:
Will this eventually earn you money, or only cover the cost of the support? I should hope the former is the case, although I imagine that will depend entirely on how much support you actually have to 'supply'?
I personally do prefer to pay for my software, as it enables much more rapid development (unless the company in question has grown so much, any new idea needs to go through 5 layers of executive red tape, ofcourse), and certainty that your favourite software's development won't be abandoned anytime soon. Although I must say I have recently lost my faith in 1-man development teams, I wish you all the best, and will be following Halebopp with interest!
Hi Michael, good questions, I am glad that you asked. I will start with detailing the current situation, followed by a more in-depth explanation of the underlying assumptions for the business model pick, and why I think that we made a good choice.
I am currently employed, and, although looking for a new job, will work in my free time on Largemind and Halebopp.
Secondly, I only develop software that I need and would use myself. This ensures that the software is practical and tested. Since I am also a composer as much as I am a developer, I am dependent on Halebopp just as my customers are. This software is the result of 16 years of experience with computer music and accumulates a lot of ideas about what composing should be like.
I am also confident that a lot of support will come from the community, in the form of patches and documentation. I have made very good experiences with open source while developing Aldrin. Should I ever have an accident and pass away, Halebopp is not lost. I care a big deal about source code documentation. The project is licenced in such a way that anyone could pick it up and continue developing it.
Now a few words about the viability of the business model.
To be honest with you, I have no idea if this business model will ever be profitable. As far as I know, there are several companies working with this model exclusively (Canonical being the biggest), but they all still run on venture capital and none of them is profitable, to my knowledge. This is a very new business model.
I still believe though, that this model is in the best interest of customers. Let me try an explanation: if you pay for a software upfront, it says nothing about its future potential. You only pay for what you get. But applications are never finished. When people get used to the work flow and wish for more, they do not want a different program immediately. What they expect is improvements to the application that they are using. That is a sane position. Software developers have relied on this custom for decades, and should therefore always work in the customers best interest, but often enough, it does not work out so well for the customer. People favor to buy upgrades for new features, not for bug fixes. Therefore, over time, applications become cluttered with features, while some bugs introduced by previous versions remain unfixed - sometimes even for years.
You could fix that through subscriptions, where payments stop when developers neglect their responsibilities. But people do want to own their software. They do not want someone else to decide when and where they can or can not use their tools. That is, again, a practical viewpoint, which must be respected.
Finally, there is a huge advantage in giving out a product for free, for both customers and vendors. As a customer, you can use the software free of charge. If you recommend it to your friends, they can get started immediately as well. There is no software piracy, and hence no serial numbers, no dongles or any of that nonsense. As a vendor, you profit from the tendency of people to get accustomed to the software. People recommend more. Blogs run wild. Magazines write about it without hesitation. And there are advantages on the development side: open source licenses allow developers to incorporate third party libraries more easily. Technical enthusiasts submit patches or write tutorials and documentation.
But where does the money come from? We have seen a large increase in social capitalism in the last years: few pay for many. At first sight, that might look like ripping off those who spend. But that is not the case. With traditional product marketing, you were only paying for one unit. If that unit or the support for it was not meeting your expectations, all you could do was waving your fist, asking for your money back, and hoping everyone else was doing the same - which is usually not the case. With social capitalism, you pay not only for your own unit, but for a large margin of free units as well. That makes you a patron of the company and therefore, gives you more power. You represent more customers, so your voice is more important.
On these assumptions rests our business model. We will give out free versions, but we will stress that buying a warranted supported version gives you influence and peace of mind. Therefore, paying customers will be those who "care more", and these are the people we need to listen to.
Tuesday, December 9, 2008
Now Open: Halebopp Alpha User Group
So here we go, just as planned. Hereby you are invited to join the
Halebopp Alpha Users Group
The alpha version of Halebopp for Ubuntu Linux will be released at the end of this week. It is an early preview of the full application and mirrors in no way the final product.
If you are interested in trying out an early preview of Halebopp and giving feedback, we will be more than happy.
Attention: The group will be closed once it reaches 50 members.
Halebopp Alpha Users Group
The alpha version of Halebopp for Ubuntu Linux will be released at the end of this week. It is an early preview of the full application and mirrors in no way the final product.
If you are interested in trying out an early preview of Halebopp and giving feedback, we will be more than happy.
Attention: The group will be closed once it reaches 50 members.
Monday, December 8, 2008
A Final Business Model Proposal
The survey has shown that people can be divided into two categories: users who use audio software for free (no matter how), and users who want to spend money on an expensive audio product.
Where expensive software pays off after time, free software is, also, like laziness: it pays off immediately. Expensive software usually has better support, more features and added value like sample libraries. Free software requires less fiddling with dongles, and of course, it's immediately available.
From a developers viewpoint, there are many advantages with free software and open development: it's easier for third parties to contribute, communities build faster, blogs and magazines advertise the program earlier. There is all kind of fame associated with a free product, yet development has to be financed in some way if the application is becoming too important to drop.
From my experience with a software company I worked for, the major part of time (and ultimately cost) is spent in support. People ask questions about a lot of things - they report bugs and compatibility issues, they talk about usage problems (and rarely suggest features!) and often need assistance with the operating system itself.
So why not put the fee where it costs?
I spent thinking several days about how I could make everyone happy, including myself. It would not be in your interest if I did all this for free. In the end, it would only mean that production would be abandoned in case I lost my paying job and had to find work. That would serve nobody.
So this is how we are going to start this.
Development will start with Ubuntu Linux as target platform, then Windows will follow, finally Mac OS X. The licence model will be GPL v3. That means the software is free to modify and distribute, as long as you ship the source with your custom version.
First, there will be an Alpha User Group for Halebopp to which everyone can join. When we reach 50 users, the group will be closed, although I doubt that will happen.
The alpha version of Halebopp will be extended until a majority of users is happy with the feature set. Then we will go into public beta, with a bugtracker open for everyone.
At the point release, Halebopp will be officially launched on the Largemind website, available for download in three different versions:
1) Basic Download, basic support, no warranty, free of charge
2) "Try-Out" Download, 30 days of support, full warranty, cheap
3) Full Download, 3 years of support, full warranty, expensive
When a support plan runs out, it will only be extended at request. The software will remain fully usable.
Where expensive software pays off after time, free software is, also, like laziness: it pays off immediately. Expensive software usually has better support, more features and added value like sample libraries. Free software requires less fiddling with dongles, and of course, it's immediately available.
From a developers viewpoint, there are many advantages with free software and open development: it's easier for third parties to contribute, communities build faster, blogs and magazines advertise the program earlier. There is all kind of fame associated with a free product, yet development has to be financed in some way if the application is becoming too important to drop.
From my experience with a software company I worked for, the major part of time (and ultimately cost) is spent in support. People ask questions about a lot of things - they report bugs and compatibility issues, they talk about usage problems (and rarely suggest features!) and often need assistance with the operating system itself.
So why not put the fee where it costs?
I spent thinking several days about how I could make everyone happy, including myself. It would not be in your interest if I did all this for free. In the end, it would only mean that production would be abandoned in case I lost my paying job and had to find work. That would serve nobody.
So this is how we are going to start this.
Development will start with Ubuntu Linux as target platform, then Windows will follow, finally Mac OS X. The licence model will be GPL v3. That means the software is free to modify and distribute, as long as you ship the source with your custom version.
First, there will be an Alpha User Group for Halebopp to which everyone can join. When we reach 50 users, the group will be closed, although I doubt that will happen.
The alpha version of Halebopp will be extended until a majority of users is happy with the feature set. Then we will go into public beta, with a bugtracker open for everyone.
At the point release, Halebopp will be officially launched on the Largemind website, available for download in three different versions:
1) Basic Download, basic support, no warranty, free of charge
2) "Try-Out" Download, 30 days of support, full warranty, cheap
3) Full Download, 3 years of support, full warranty, expensive
When a support plan runs out, it will only be extended at request. The software will remain fully usable.
Friday, December 5, 2008
Working for a New Generation of Composers
I noticed that I never explained why I want to found a company in the first place, and rather prefer to write articles about development progress and statistics, while assuming that the reasons are obvious. This might also explain the little interest that people put into this blog. Well, that, and the lack of pictures.
So, here it is, a reason why the world would be worse off without my organization, and what kind of meaning I want to bring to it.
The starting question is: if both computers and music were meant to be for everybody, why is making computer music still seen as a profession for enthusiasts, and why is there no change in that situation?
Computer music is hard. Interfaces are overly technical and complex, because application designers use old-fashioned recording studio metaphors. Barely anyone is familiar with these concepts. Coming to persuading results in a reasonable time is impossible. As a result, mastering a music making program takes literally ages.
Computer music is rotting. Almost all music technology used today is based on ideas that have been formulated and realized twenty to thirty years ago. The ways how people can interact with music making programs are constrained by these ideas. Developers focus on rephrasing rather than rethinking these concepts, and resort to keeping interface design close to limitations of the underlying system.
Computer music is boring. Rarely can we enjoy a symphony made on a computer. Excessively technical editing interfaces slow down users and break their flow. Song setups have a static feel to them. Changing song structure requires a big count of work steps. It is easier to work on a small loop endlessly than to roll out an entire track that changes shape and structure over time, featuring entertaining variations and breaks. Therefore tracks sound conceptual and repetitive.
Computer music sounds like computer music. It is usually easy to tell when a computer was involved in making a track. Synthesized sounds often carry an uncanny feeling when meant to sound like real instruments. Engineering new interesting sounds takes an awful lot of time. Computer music therefore often sounds thin and unconvincing. Artists often resort to natural sound sources to add a feeling of authenticity or warmth to their tracks.
Within my organization, I want to change what sucks about computer music. I want to enable you to do what you expected when you first became interested in composing music: write excellent music on your computer that persuades through richness and entertains through variation.
The solution is a new set of applications that make this goal possible, crafted with steady feedback from our customers. With our commitment, computers will be the fuel of tomorrows music scores, no expensive orchestra required. With our dedication, everyone with a good idea for a song has a chance to reach for the stars - and beyond.
We are going to change the meaning of "computer music". Who is with me?
So, here it is, a reason why the world would be worse off without my organization, and what kind of meaning I want to bring to it.
The starting question is: if both computers and music were meant to be for everybody, why is making computer music still seen as a profession for enthusiasts, and why is there no change in that situation?
Computer music is hard. Interfaces are overly technical and complex, because application designers use old-fashioned recording studio metaphors. Barely anyone is familiar with these concepts. Coming to persuading results in a reasonable time is impossible. As a result, mastering a music making program takes literally ages.
Computer music is rotting. Almost all music technology used today is based on ideas that have been formulated and realized twenty to thirty years ago. The ways how people can interact with music making programs are constrained by these ideas. Developers focus on rephrasing rather than rethinking these concepts, and resort to keeping interface design close to limitations of the underlying system.
Computer music is boring. Rarely can we enjoy a symphony made on a computer. Excessively technical editing interfaces slow down users and break their flow. Song setups have a static feel to them. Changing song structure requires a big count of work steps. It is easier to work on a small loop endlessly than to roll out an entire track that changes shape and structure over time, featuring entertaining variations and breaks. Therefore tracks sound conceptual and repetitive.
Computer music sounds like computer music. It is usually easy to tell when a computer was involved in making a track. Synthesized sounds often carry an uncanny feeling when meant to sound like real instruments. Engineering new interesting sounds takes an awful lot of time. Computer music therefore often sounds thin and unconvincing. Artists often resort to natural sound sources to add a feeling of authenticity or warmth to their tracks.
Within my organization, I want to change what sucks about computer music. I want to enable you to do what you expected when you first became interested in composing music: write excellent music on your computer that persuades through richness and entertains through variation.
The solution is a new set of applications that make this goal possible, crafted with steady feedback from our customers. With our commitment, computers will be the fuel of tomorrows music scores, no expensive orchestra required. With our dedication, everyone with a good idea for a song has a chance to reach for the stars - and beyond.
We are going to change the meaning of "computer music". Who is with me?
Thursday, December 4, 2008
The Audio 2.0 Survey Results
Here are, as promised, the Survey results. 58 people have taken part. A huge "thank you" to everybody who took the time to answer it.
In a later blog post, I'm going into details on the submissions, especially some of the comments people made, and my interpretation of the data.
In a later blog post, I'm going into details on the submissions, especially some of the comments people made, and my interpretation of the data.
How old are you? | |||||||||||||||||||||
| |||||||||||||||||||||
What operating systems do you use? | |||||||||||||||||||||
People may select more than one checkbox, so percentages may add up to more than 100%. | |||||||||||||||||||||
What are you using audio editing software for? | |||||||||||||||||||||||||||||
People may select more than one checkbox, so percentages may add up to more than 100%. | |||||||||||||||||||||||||||||
What kind of audio editing software do you use? | |||||||||||||||||||||||||||||
People may select more than one checkbox, so percentages may add up to more than 100%. | |||||||||||||||||||||||||||||
Did you buy any software this year? | |||||||||||||||||||||
| |||||||||||||||||||||
What would be your favorite way of purchasing software? | |||||||||||||||||||||||||
| |||||||||||||||||||||||||
How important is personal email support to you? | ||||||||||||||||||||||||
|
| |||||||||||||||||||||||
How important is phone support to you? | ||||||||||||||||||||||||
|
| |||||||||||||||||||||||
How important are updates to you? | ||||||||||||||||||||||||
|
| |||||||||||||||||||||||
Do you see software as a product or a service? | ||||||||||||||||||||||||
|
| |||||||||||||||||||||||
What would you consider the average tolerable fee for a software service subscription? | |||||||||||||||||||||||||
| |||||||||||||||||||||||||
For above fee, what mandatory services MUST be included in such a subscription? | |||||||||||||||||||||||||||||||||||||||||||||||||||||
People may select more than one checkbox, so percentages may add up to more than 100%. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
Subscribe to:
Posts (Atom)
