|
From: Juan L. <co...@re...> - 2002-10-29 20:24:01
|
On Mon, 28 Oct 2002 14:26:55 -0800 lin...@li... wrote: > Linuxsampler-devel -- confirmation of subscription -- request 730633 > > We have received a request from 24.232.150.110 for subscription of > your email address, <co...@re...>, to the > lin...@li... mailing list. To confirm the > request, please send a message to > lin...@li..., and either: > > - maintain the subject line as is (the reply's additional "Re:" is > ok), > > - or include the following line - and only the following line - in the > message body: > > confirm 730633 > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form.) > > If you do not wish to subscribe to this list, please simply disregard > this message. Send questions to > lin...@li.... > |
|
From: Richard A. S. <rs...@bi...> - 2002-10-29 21:56:29
|
Benno: Good to see you back in business again. I'm looking forward to burning up the free time I don't have messing with linuxsampler. My vote on programming languages would be C++. Really, if you code things in a modular and decoupled way like all the books preach then you C looks and acts like C++ anyway. Unless you are really doing some fancy template run time typing stuff there is little difference between C and C++. In 90% of the code you _won't_ need the speed advantage that C offers. Which is largely a myth anyway its more the programmer than the language. Yes there are some run time issues with C++ but unless you are really carefull about how you code your C it probally won't be the language choice that slows things down. GCC is amazingly good at optimizing things once you tweak the parameters right. One thing I've learned over the years is that you can't predict where you wil _really_ need optimization, things are just too complex. You just have to code in the cleanest most maintainable way and then come back and optimize. If you try to always code-for-performance you usually end up with just the opposite. I grew up learning C and that doing things via pointers was always faster than using arrays. Yeah, 10 years ago this was true but GCC broke me of this. My best attempt at stepper motor control algo I was working on was soundly stomped on by just using arrays and letting GCC optimize. And really if you get _that_ concerned about performance then you should probally use arch specific assembly and/or things like MMX/3dNOW type stuff like all the current audio encodeing/decodeing libraries do. The management and maintaince benefits of C++ seem to be a clear winner for a project like this. Oh and I like the socket interface for the GUI to engine communication. This allows them to be on different machines or even different architectures which considering the Mac heavy world that most studios have is probally a good thing. If you use a shared memory setup they you also greatly add to the work level needed to use other programming languages for the front end GUI. So like, if I wanted to use my new favorite language python a set of bindings would have to be written first but if its just a socket then it's easy. -- Richard A. Smith Bitworks, Inc. rs...@bi... 479.846.5777 x104 Sr. Design Engineer http://www.bitworks.com |
|
From: Juan L. <co...@re...> - 2002-10-29 22:16:04
|
On Tue, 29 Oct 2002 15:55:41 -0600 "Richard A. Smith" <rs...@bi...> wrote: > Benno: > > Good to see you back in business again. I'm looking forward to > burning up the free time I don't have messing with linuxsampler. > > My vote on programming languages would be C++. Really, if you code > things in a modular and decoupled way like all the books preach then > you C looks and acts like C++ anyway. Unless you are really doing > some fancy template run time typing stuff there is little difference > between C and C++. > I couldnt agree more! So I second that vote. > In 90% of the code you _won't_ need the speed advantage that C > offers. Which is largely a myth anyway its more the programmer than > the language. Yes there are some run time issues with C++ but unless > you are really carefull about how you code your C it probally won't > be the language choice that slows things down. GCC is amazingly good > at optimizing things once you tweak the parameters right. Such is true, I wouldnt care about optimization either since gcc does a fantastic work. I wrote my tracker in C++, and the mixing is actually faster than mikmod (which is written in C). > > I grew up learning C and that doing things via pointers was always > faster than using arrays. Yeah, 10 years ago this was true but GCC > broke me of this. My best attempt at stepper motor control algo I > was working on was soundly stomped on by just using arrays and > letting GCC optimize. > The same happened to me recently while doing ARM development. If you do things the "normal" way (ie using indexes and stuff) in most cases gcc will be able to optimize better than if you do the optimization yourself. I've even seen many cases recently of people who tried to write asm modules to optimize and ended up frustrated that gcc optimized more than their asm code. > > Oh and I like the socket interface for the GUI to engine > communication. This allows them to be on different machines or even > different architectures which considering the Mac heavy world that > most studios have is probally a good thing. > Yeah, I had in mind that musicans could build a linux box only to dedicate it to a sampler.. (in other words, building a cheap sampler box, since most commercial ones are over 2k USD). This way frontends can be done natively in any OS without having to resort to more complicated things such as the X protocol/Xlib/etc and without the sampler needing to have all those libs installed. And it could also be good if, in a future, we want to profit from this project by selling PCs specially built, configured and tuned in such a way that they cant be distinguished from a real hardware samplers :) Cheers! Juan Linietsky |