Another way to sell your music (in addition to CD Baby) is to work directly with companies like Audio Lunchbox. ALB gives 65% of sales to the artist. They also offer up your music in the non-evil MP3 and Ogg Vorbis (even less evil) formats. You can also plug your band across the internet on various indie and digital music sites. Audio Lunchbox also offers forums for just that purpose as does CD Baby and MP3.com.
The first release intended for developers / development will probably be made this weekend. It's usable, but it's still in the larval stage so to speak.
If anyone is interested in working on a free 3d modeling / rendering project, I would reccomend working on one of the many existing projects. Each project seems to have a slightly different slant on what it intends to be good at so I don't think diversity is a problem.
I have been writing a modeller named Extreme Wave which is based on some of my grad school work, but there are a number of other fine projects that have made some significant progress including MOPS, Moonlight Creator, 3DOM, and MindsEye. No Maya killers in the bunch yet.
If you design your application/system to be extended through subclassing and then pick a language that does not support that particular OO feature, well, you've made a mistake in design.
I agree. And so for core libraries that you would like to be functional and useful for everyone you logically don't want to use any OO feature specific to the language the library is written in. This is what I was referring to when I said c was the least common denominator. (not that you nust use c)
It all comes down to good design, not picking the lowest common denominator language.
This is true, but I don't presume to know exactly how something I write will be used, and thus can't plan to add or remove certain OO features. Thus if you limit your scope to certain bindings that you feel are useful, you have written Good [TM] code. If someone else comes along wanting to put this library into a different binding or context, they might not agree it was so good. I am not saying ALL libraries should not require certain OO specific language features. Just libraries that you want everyone to be able to use and be more or less language neutral. It is possible to use OO principles without using OO specific language features in the interface.
SWIG is a good tool, and it will help you use classes and methods written in c++, but a lot of c++'s functionality comes through inheritance. If you would like to "subclass" a c++ class in order to extend the application you must do so in c++. Many libraries provide classes that must be subclassed even to be useful, SWIG really can't help you here.
The best you could do would be to write a subclass in c++ that does what you want and then bind that with SWIG. But my point is you still haven't provided the user of your SWIG bindings with the same functionality that is only available when you can subclass something. If the very method of extending your application is through subclassing, then SWIG bindings wont allow the target language to extend your library / application.
Not long ago I would have loudly agreed with you, but I have come to beleive that GTK's OO hierarchy in C was actually a very wise thing to do. I have been working on a very large software application that needs multiple language bindings and must run on a diverse number of machines. The application has grown quite large, but I fear I must transition it from C++ to C.
In particular, writing bindings to non-OO scripting languages has been very difficult and because I used all sorts of function and operator overloading the bindings don't "parallel" each other very well. Writing foreign language bindings to c code is pretty standard for any scripting language, it's rare that any scripting language has any particular support for c++ features in their binding system (i.e. creating new c++ classes in other languages).
I designed my application so that a c++ class could be dynamically added as a plugin, but this is really bad if you hope to have non-c++ plugins. The Gimp procedural database is a much better approach IMHO.
I also find that c++ compilers vary widely on the implementation of ISO c++ features. Thus portability was VERY difficult for me. To get my application to run on the target systems, I basically had to get rid of all templates and use very vanilla classes. Writing c++ code was great until I had to move it to another machine with a different c++ compiler. I would then spend about as much time redesigning it to work on the new machines as I did on the original. Plain vanilla C has been much kinder to me than C++ in this regard.
I do agree that there is a definite anti-c++ bent in the free software community, and I don't intend to be encouraging it, but my personal beleif is that core libraries should be written in c. This makes it easier for people writing "end user" applications of less utilitary scope to take advantage of the code base no matter what language they prefer to write their applications in.
I truly sympathize with wanting to be able to use c++ features that were DESIGNED to do what you must implement in c, but if the code can be used by more people with more languages on more systems it is more useful if it is written in a less elegant form. As languages go, c is the common denominator.
Slashdot Mirror
Another way to sell your music (in addition to CD Baby) is to work directly with companies like Audio Lunchbox. ALB gives 65% of sales to the artist. They also offer up your music in the non-evil MP3 and Ogg Vorbis (even less evil) formats. You can also plug your band across the internet on various indie and digital music sites. Audio Lunchbox also offers forums for just that purpose as does CD Baby and MP3.com.
The first release intended for developers / development will probably be made this weekend. It's usable, but it's still in the larval stage so to speak.
If anyone is interested in working on a free 3d modeling / rendering project, I would reccomend working on one of the many existing projects. Each project seems to have a slightly different slant on what it intends to be good at so I don't think diversity is a problem.
I have been writing a modeller named Extreme Wave which is based on some of my grad school work, but there are a number of other fine projects that have made some significant progress including MOPS, Moonlight Creator, 3DOM, and MindsEye. No Maya killers in the bunch yet.
If you design your application/system to be extended through subclassing and then pick a language that does not support that particular OO feature, well, you've made a mistake in design.
I agree. And so for core libraries that you would like to be functional and useful for everyone you logically don't want to use any OO feature specific to the language the library is written in. This is what I was referring to when I said c was the least common denominator. (not that you nust use c)
It all comes down to good design, not picking the lowest common denominator language.
This is true, but I don't presume to know exactly how something I write will be used, and thus can't plan to add or remove certain OO features. Thus if you limit your scope to certain bindings that you feel are useful, you have written Good [TM] code. If someone else comes along wanting to put this library into a different binding or context, they might not agree it was so good. I am not saying ALL libraries should not require certain OO specific language features. Just libraries that you want everyone to be able to use and be more or less language neutral. It is possible to use OO principles without using OO specific language features in the interface.
SWIG is a good tool, and it will help you use classes and methods written in c++, but a lot of c++'s functionality comes through inheritance. If you would like to "subclass" a c++ class in order to extend the application you must do so in c++. Many libraries provide classes that must be subclassed even to be useful, SWIG really can't help you here.
The best you could do would be to write a subclass in c++ that does what you want and then bind that with SWIG. But my point is you still haven't provided the user of your SWIG bindings with the same functionality that is only available when you can subclass something. If the very method of extending your application is through subclassing, then SWIG bindings wont allow the target language to extend your library / application.
Not long ago I would have loudly agreed with you, but I have come to beleive that GTK's OO hierarchy in C was actually a very wise thing to do. I have been working on a very large software application that needs multiple language bindings and must run on a diverse number of machines. The application has grown quite large, but I fear I must transition it from C++ to C.
In particular, writing bindings to non-OO scripting languages has been very difficult and because I used all sorts of function and operator overloading the bindings don't "parallel" each other very well. Writing foreign language bindings to c code is pretty standard for any scripting language, it's rare that any scripting language has any particular support for c++ features in their binding system (i.e. creating new c++ classes in other languages).
I designed my application so that a c++ class could be dynamically added as a plugin, but this is really bad if you hope to have non-c++ plugins. The Gimp procedural database is a much better approach IMHO.
I also find that c++ compilers vary widely on the implementation of ISO c++ features. Thus portability was VERY difficult for me. To get my application to run on the target systems, I basically had to get rid of all templates and use very vanilla classes. Writing c++ code was great until I had to move it to another machine with a different c++ compiler. I would then spend about as much time redesigning it to work on the new machines as I did on the original. Plain vanilla C has been much kinder to me than C++ in this regard.
I do agree that there is a definite anti-c++ bent in the free software community, and I don't intend to be encouraging it, but my personal beleif is that core libraries should be written in c. This makes it easier for people writing "end user" applications of less utilitary scope to take advantage of the code base no matter what language they prefer to write their applications in.
I truly sympathize with wanting to be able to use c++ features that were DESIGNED to do what you must implement in c, but if the code can be used by more people with more languages on more systems it is more useful if it is written in a less elegant form. As languages go, c is the common denominator.