|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
|
|
scaling of float soundfilesRichard Dobson brought to our attention that the scaling of output
soundfiles in floating-point format using WAVEX file format is wrong. I have traced this to the following lines in InOut/libsnd.c: if (!(O->outformat == AE_FLOAT || O->outformat == AE_DOUBLE) || (O->filetyp == TYP_WAV || O->filetyp == TYP_AIFF || O->filetyp == TYP_W64)) csound->spoutran = spoutsf; /* accumulate output */ else csound->spoutran = spoutsf_noscale; (I have not tested, but these lines seem to be at the centre of the issue). My question is: can we not use the spoutsf() function at all times as the 'spoutran' routine? Always scaling the output correctly, regardless of file format? Can someone else check this too? Victor ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: scaling of float soundfilesIt has been a good while and I have not had any replies. Should I just
proceed to change the code myself? Regards Victor On 5 Nov 2009, at 12:00, Victor Lazzarini wrote: > Richard Dobson brought to our attention that the scaling of output > soundfiles in floating-point format using WAVEX file format is wrong. > I have traced this to the following lines in InOut/libsnd.c: > > if (!(O->outformat == AE_FLOAT || O->outformat == AE_DOUBLE) || > (O->filetyp == TYP_WAV || O->filetyp == TYP_AIFF || > O->filetyp == TYP_W64)) > csound->spoutran = spoutsf; /* accumulate output */ > else > csound->spoutran = spoutsf_noscale; > > (I have not tested, but these lines seem to be at the centre of the > issue). > > My question is: can we not use the spoutsf() function at all times as > the 'spoutran' routine? Always scaling the output correctly, > regardless of file format? > > Can someone else check this too? > > Victor > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: scaling of float soundfilesOK by me!
Richard Dobson Victor Lazzarini wrote: > It has been a good while and I have not had any replies. Should I just > proceed to change the code myself? > > Regards > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
latest language to hit the streets...Google's new "Go" language:
http://golang.org/ supports concurrent processing using channels (much loved by the CSP community). Invented by (among others) Ken Thompson of unix fame. May be a while before someone writes an FFT or dsp package for it. Garbage-collected. Executables are claimed to be "almost as fast as C/C++". Interesting, though. Richard Dobson ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...If there is an easy way to do for line in file exc... and .append like python I am sold.. I think I may be using the nimrod programming language because it is more python like for my tools (ifn parser exc). It looks interesting though.
|
|
|
Re: latest language to hit the streets...I'd be interested if it were faster than c++. Mkg On Nov 11, 2009 7:06 AM, "edexter5" <Eric_Dexter@...> wrote: ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...Michael Gogins wrote:
> I'd be interested if it were faster than c++. > > Mkg > That may become an obsolete comparison in a few years. One of the 'selling points' of "Go" is support from the get-go (i.e. at the level of the language itself) of concurrency (it comes partly from an occam background); and if it proves, say, to be a good match for Intel's 80-core chip, it will likely easily eclipse C++, which has no such support other than through external libraries and which will be an awkward fit, at best, to such architectures. The DNA of C and C++ is still essentially sequential single-threaded. As I see it, a language such as "Go" is effectively running under emulation on a current-generation processor (even including 8-core ones) and OS. The somewhat modest attempts to add concurrency support to the forthcoming C++ standard are I suspect too little too late. Cracking off a few C++ threads on an 8-core processor will be modest compared to what will be needed in the next decade (or less, possibly). We will want to run either individual opcodes, or individual instruments, on each of those 80 cores. Who knows - maybe that famous Durham project of Csound on an array of Transputers may yet be able to enjoy a revival! Richard Dobson ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...It looks OK but I always view GC with suspicion for audio applications. bummer, that's the bit of C/C++ I love to teach students... In general, it seems promising, I like the relation to occam. It feels slighty higher-level than C or C++. Also in comparison to C, it might not be a small language (one thing I like about it). Victor On 11 Nov 2009, at 16:59, Richard Dobson wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...Speed will never stop being the main point. The only reason to bother
one's head programming a computer is that it will run faster than you can run a pencil and paper. The faster, the better, period. As we recently found, Csound users start to howl if there is a speed deficit of 10% or more... C++ has now got, in my experience, adequate support for concurrency with OpenMP. It is supported by all major compilers now including Sun Studio, gcc, MinGW, and Microsoft. There is no need to switch away from C++ to write parallel code. Almost all real software that has to run reliably and fast and that people trust in danger is written in C++. Airplanes, ships, guns, cars, computer games, particle physics experiments, database servers, Web servers all run on C or C++ (with calls into numeric Fortran, I admit). Almost all shrink-wrap commercial software is written in C++. There must be a reason. In my view, a better language would simply be C++ with some additional features -- and faster. And this is what we will get. That said, if someone comes up with Go or D or Haskell or Scala or Lisp or O'Caml that actually runs faster than C++ and is not too terribly difficult to use and can call into C libraries, I will be among the first to use it. I'm still waiting... Regards, Mike On 11/11/09, Richard Dobson <richarddobson@...> wrote: > Michael Gogins wrote: >> I'd be interested if it were faster than c++. >> >> Mkg >> > > > That may become an obsolete comparison in a few years. One of the > 'selling points' of "Go" is support from the get-go (i.e. at the level > of the language itself) of concurrency (it comes partly from an occam > background); and if it proves, say, to be a good match for Intel's > 80-core chip, it will likely easily eclipse C++, which has no such > support other than through external libraries and which will be an > awkward fit, at best, to such architectures. The DNA of C and C++ is > still essentially sequential single-threaded. > > As I see it, a language such as "Go" is effectively running under > emulation on a current-generation processor (even including 8-core ones) > and OS. The somewhat modest attempts to add concurrency support to the > forthcoming C++ standard are I suspect too little too late. Cracking off > a few C++ threads on an 8-core processor will be modest compared to what > will be needed in the next decade (or less, possibly). We will want to > run either individual opcodes, or individual instruments, on each of > those 80 cores. Who knows - maybe that famous Durham project of Csound > on an array of Transputers may yet be able to enjoy a revival! > > Richard Dobson > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...I guess for me, my core interest is not speed alone, but also long
term viability. It's a criteria I evaluate highly is one of the primary reasons I prefer Java over other languages. The JVM helps protect against changes of hardware and the ecosystem around the JVM is pretty vibrant, including many interesting languages besides just Java (i.e. Jython, Clojure, JRuby). There's also a large number of businesses using Java and great tools support. There's also a number of interesting concurrency things going on in the Java ecosystem (namely Actors in Groovy and Scala and Software Transactional Memory in Clojure). I think I'm alright with Java's speed when balancing against long-term viability and ease of development. I also like scaling my needs per language, as I couldn't script a piece of music in Java but could in Jython (python on java), as the speed required there isn't an issue. Go looks interesting though the syntax doesn't really appeal to me. I'll probably keep myself aware of it but being new I don't think it has enough around it yet to consider for personal projects. steven On Wed, Nov 11, 2009 at 1:31 PM, Michael Gogins <michael.gogins@...> wrote: > Speed will never stop being the main point. The only reason to bother > one's head programming a computer is that it will run faster than you > can run a pencil and paper. The faster, the better, period. As we > recently found, Csound users start to howl if there is a speed deficit > of 10% or more... > > C++ has now got, in my experience, adequate support for concurrency > with OpenMP. It is supported by all major compilers now including Sun > Studio, gcc, MinGW, and Microsoft. There is no need to switch away > from C++ to write parallel code. > > Almost all real software that has to run reliably and fast and that > people trust in danger is written in C++. Airplanes, ships, guns, > cars, computer games, particle physics experiments, database servers, > Web servers all run on C or C++ (with calls into numeric Fortran, I > admit). Almost all shrink-wrap commercial software is written in C++. > There must be a reason. > > In my view, a better language would simply be C++ with some additional > features -- and faster. And this is what we will get. > > That said, if someone comes up with Go or D or Haskell or Scala or > Lisp or O'Caml that actually runs faster than C++ and is not too > terribly difficult to use and can call into C libraries, I will be > among the first to use it. I'm still waiting... > > Regards, > Mike > > On 11/11/09, Richard Dobson <richarddobson@...> wrote: >> Michael Gogins wrote: >>> I'd be interested if it were faster than c++. >>> >>> Mkg >>> >> >> >> That may become an obsolete comparison in a few years. One of the >> 'selling points' of "Go" is support from the get-go (i.e. at the level >> of the language itself) of concurrency (it comes partly from an occam >> background); and if it proves, say, to be a good match for Intel's >> 80-core chip, it will likely easily eclipse C++, which has no such >> support other than through external libraries and which will be an >> awkward fit, at best, to such architectures. The DNA of C and C++ is >> still essentially sequential single-threaded. >> >> As I see it, a language such as "Go" is effectively running under >> emulation on a current-generation processor (even including 8-core ones) >> and OS. The somewhat modest attempts to add concurrency support to the >> forthcoming C++ standard are I suspect too little too late. Cracking off >> a few C++ threads on an 8-core processor will be modest compared to what >> will be needed in the next decade (or less, possibly). We will want to >> run either individual opcodes, or individual instruments, on each of >> those 80 cores. Who knows - maybe that famous Durham project of Csound >> on an array of Transputers may yet be able to enjoy a revival! >> >> Richard Dobson >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@... >> https://lists.sourceforge.net/lists/listinfo/csound-devel >> > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...hey steve I noticed something that was released that allows jython and ipython to be run from python what graphics libraries in java would you recommend??
.
|
|
|
Re: latest language to hit the streets...Hi Eric,
I use just the standard Swing toolkit that comes with Java. You could use the older AWT but I'd recommend against that (also comes with Java and Swing is built on top of AWT). SWT is also somewhat popular and I don't have all that much experience with it, but would just note that it would require extra libraries for each platform you publish on, while Swing is built-in. steven On Thu, Nov 12, 2009 at 12:40 AM, edexter5 <Eric_Dexter@...> wrote: > > hey steve I noticed something that was released that allows jython and > ipython to be run from python what graphics libraries in java would you > recommend?? > . > > Steven Yi wrote: >> >> I guess for me, my core interest is not speed alone, but also long >> term viability. It's a criteria I evaluate highly is one of the >> primary reasons I prefer Java over other languages. The JVM helps >> protect against changes of hardware and the ecosystem around the JVM >> is pretty vibrant, including many interesting languages besides just >> Java (i.e. Jython, Clojure, JRuby). There's also a large number of >> businesses using Java and great tools support. There's also a number >> of interesting concurrency things going on in the Java ecosystem >> (namely Actors in Groovy and Scala and Software Transactional Memory >> in Clojure). >> >> I think I'm alright with Java's speed when balancing against long-term >> viability and ease of development. I also like scaling my needs per >> language, as I couldn't script a piece of music in Java but could in >> Jython (python on java), as the speed required there isn't an issue. >> >> Go looks interesting though the syntax doesn't really appeal to me. >> I'll probably keep myself aware of it but being new I don't think it >> has enough around it yet to consider for personal projects. >> >> steven >> >> >> >> On Wed, Nov 11, 2009 at 1:31 PM, Michael Gogins >> <michael.gogins@...> wrote: >>> Speed will never stop being the main point. The only reason to bother >>> one's head programming a computer is that it will run faster than you >>> can run a pencil and paper. The faster, the better, period. As we >>> recently found, Csound users start to howl if there is a speed deficit >>> of 10% or more... >>> >>> C++ has now got, in my experience, adequate support for concurrency >>> with OpenMP. It is supported by all major compilers now including Sun >>> Studio, gcc, MinGW, and Microsoft. There is no need to switch away >>> from C++ to write parallel code. >>> >>> Almost all real software that has to run reliably and fast and that >>> people trust in danger is written in C++. Airplanes, ships, guns, >>> cars, computer games, particle physics experiments, database servers, >>> Web servers all run on C or C++ (with calls into numeric Fortran, I >>> admit). Almost all shrink-wrap commercial software is written in C++. >>> There must be a reason. >>> >>> In my view, a better language would simply be C++ with some additional >>> features -- and faster. And this is what we will get. >>> >>> That said, if someone comes up with Go or D or Haskell or Scala or >>> Lisp or O'Caml that actually runs faster than C++ and is not too >>> terribly difficult to use and can call into C libraries, I will be >>> among the first to use it. I'm still waiting... >>> >>> Regards, >>> Mike >>> >>> On 11/11/09, Richard Dobson <richarddobson@...> wrote: >>>> Michael Gogins wrote: >>>>> I'd be interested if it were faster than c++. >>>>> >>>>> Mkg >>>>> >>>> >>>> >>>> That may become an obsolete comparison in a few years. One of the >>>> 'selling points' of "Go" is support from the get-go (i.e. at the level >>>> of the language itself) of concurrency (it comes partly from an occam >>>> background); and if it proves, say, to be a good match for Intel's >>>> 80-core chip, it will likely easily eclipse C++, which has no such >>>> support other than through external libraries and which will be an >>>> awkward fit, at best, to such architectures. The DNA of C and C++ is >>>> still essentially sequential single-threaded. >>>> >>>> As I see it, a language such as "Go" is effectively running under >>>> emulation on a current-generation processor (even including 8-core ones) >>>> and OS. The somewhat modest attempts to add concurrency support to the >>>> forthcoming C++ standard are I suspect too little too late. Cracking off >>>> a few C++ threads on an 8-core processor will be modest compared to what >>>> will be needed in the next decade (or less, possibly). We will want to >>>> run either individual opcodes, or individual instruments, on each of >>>> those 80 cores. Who knows - maybe that famous Durham project of Csound >>>> on an array of Transputers may yet be able to enjoy a revival! >>>> >>>> Richard Dobson >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus >>>> on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>> >>> >>> -- >>> Michael Gogins >>> Irreducible Productions >>> http://www.michael-gogins.com >>> Michael dot Gogins at gmail dot com >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@... >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@... >> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> > > -- > View this message in context: http://old.nabble.com/scaling-of-float-soundfiles-tp26213291p26313777.html > Sent from the Csound - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...SWT is superior to Swing in many ways. Eclipse is based on SWT and
provides SWT librariesd for most platforms. Regards, Mike On Mon, Nov 16, 2009 at 12:37 PM, Steven Yi <stevenyi@...> wrote: > Hi Eric, > > I use just the standard Swing toolkit that comes with Java. You could > use the older AWT but I'd recommend against that (also comes with Java > and Swing is built on top of AWT). SWT is also somewhat popular and I > don't have all that much experience with it, but would just note that > it would require extra libraries for each platform you publish on, > while Swing is built-in. > > steven > > On Thu, Nov 12, 2009 at 12:40 AM, edexter5 <Eric_Dexter@...> wrote: >> >> hey steve I noticed something that was released that allows jython and >> ipython to be run from python what graphics libraries in java would you >> recommend?? >> . >> >> Steven Yi wrote: >>> >>> I guess for me, my core interest is not speed alone, but also long >>> term viability. It's a criteria I evaluate highly is one of the >>> primary reasons I prefer Java over other languages. The JVM helps >>> protect against changes of hardware and the ecosystem around the JVM >>> is pretty vibrant, including many interesting languages besides just >>> Java (i.e. Jython, Clojure, JRuby). There's also a large number of >>> businesses using Java and great tools support. There's also a number >>> of interesting concurrency things going on in the Java ecosystem >>> (namely Actors in Groovy and Scala and Software Transactional Memory >>> in Clojure). >>> >>> I think I'm alright with Java's speed when balancing against long-term >>> viability and ease of development. I also like scaling my needs per >>> language, as I couldn't script a piece of music in Java but could in >>> Jython (python on java), as the speed required there isn't an issue. >>> >>> Go looks interesting though the syntax doesn't really appeal to me. >>> I'll probably keep myself aware of it but being new I don't think it >>> has enough around it yet to consider for personal projects. >>> >>> steven >>> >>> >>> >>> On Wed, Nov 11, 2009 at 1:31 PM, Michael Gogins >>> <michael.gogins@...> wrote: >>>> Speed will never stop being the main point. The only reason to bother >>>> one's head programming a computer is that it will run faster than you >>>> can run a pencil and paper. The faster, the better, period. As we >>>> recently found, Csound users start to howl if there is a speed deficit >>>> of 10% or more... >>>> >>>> C++ has now got, in my experience, adequate support for concurrency >>>> with OpenMP. It is supported by all major compilers now including Sun >>>> Studio, gcc, MinGW, and Microsoft. There is no need to switch away >>>> from C++ to write parallel code. >>>> >>>> Almost all real software that has to run reliably and fast and that >>>> people trust in danger is written in C++. Airplanes, ships, guns, >>>> cars, computer games, particle physics experiments, database servers, >>>> Web servers all run on C or C++ (with calls into numeric Fortran, I >>>> admit). Almost all shrink-wrap commercial software is written in C++. >>>> There must be a reason. >>>> >>>> In my view, a better language would simply be C++ with some additional >>>> features -- and faster. And this is what we will get. >>>> >>>> That said, if someone comes up with Go or D or Haskell or Scala or >>>> Lisp or O'Caml that actually runs faster than C++ and is not too >>>> terribly difficult to use and can call into C libraries, I will be >>>> among the first to use it. I'm still waiting... >>>> >>>> Regards, >>>> Mike >>>> >>>> On 11/11/09, Richard Dobson <richarddobson@...> wrote: >>>>> Michael Gogins wrote: >>>>>> I'd be interested if it were faster than c++. >>>>>> >>>>>> Mkg >>>>>> >>>>> >>>>> >>>>> That may become an obsolete comparison in a few years. One of the >>>>> 'selling points' of "Go" is support from the get-go (i.e. at the level >>>>> of the language itself) of concurrency (it comes partly from an occam >>>>> background); and if it proves, say, to be a good match for Intel's >>>>> 80-core chip, it will likely easily eclipse C++, which has no such >>>>> support other than through external libraries and which will be an >>>>> awkward fit, at best, to such architectures. The DNA of C and C++ is >>>>> still essentially sequential single-threaded. >>>>> >>>>> As I see it, a language such as "Go" is effectively running under >>>>> emulation on a current-generation processor (even including 8-core ones) >>>>> and OS. The somewhat modest attempts to add concurrency support to the >>>>> forthcoming C++ standard are I suspect too little too late. Cracking off >>>>> a few C++ threads on an 8-core processor will be modest compared to what >>>>> will be needed in the next decade (or less, possibly). We will want to >>>>> run either individual opcodes, or individual instruments, on each of >>>>> those 80 cores. Who knows - maybe that famous Durham project of Csound >>>>> on an array of Transputers may yet be able to enjoy a revival! >>>>> >>>>> Richard Dobson >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>> 30-Day >>>>> trial. Simplify your report design, integration and deployment - and >>>>> focus >>>>> on >>>>> what you do best, core application coding. Discover what's new with >>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>> >>>> >>>> -- >>>> Michael Gogins >>>> Irreducible Productions >>>> http://www.michael-gogins.com >>>> Michael dot Gogins at gmail dot com >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and focus >>> on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@... >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >> >> -- >> View this message in context: http://old.nabble.com/scaling-of-float-soundfiles-tp26213291p26313777.html >> Sent from the Csound - Dev mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@... >> https://lists.sourceforge.net/lists/listinfo/csound-devel >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
|
|
Re: latest language to hit the streets...Well, I would say SWT has many limitations, especially concerning
customizing the look and feel. My bias is towards Swing as it's what I have the most experience in and I (mostly) like the design of the API. You can make fine apps in either one though, IMO. On Mon, Nov 16, 2009 at 1:17 PM, Michael Gogins <michael.gogins@...> wrote: > SWT is superior to Swing in many ways. Eclipse is based on SWT and > provides SWT librariesd for most platforms. > > Regards, > Mike > > On Mon, Nov 16, 2009 at 12:37 PM, Steven Yi <stevenyi@...> wrote: >> Hi Eric, >> >> I use just the standard Swing toolkit that comes with Java. You could >> use the older AWT but I'd recommend against that (also comes with Java >> and Swing is built on top of AWT). SWT is also somewhat popular and I >> don't have all that much experience with it, but would just note that >> it would require extra libraries for each platform you publish on, >> while Swing is built-in. >> >> steven >> >> On Thu, Nov 12, 2009 at 12:40 AM, edexter5 <Eric_Dexter@...> wrote: >>> >>> hey steve I noticed something that was released that allows jython and >>> ipython to be run from python what graphics libraries in java would you >>> recommend?? >>> . >>> >>> Steven Yi wrote: >>>> >>>> I guess for me, my core interest is not speed alone, but also long >>>> term viability. It's a criteria I evaluate highly is one of the >>>> primary reasons I prefer Java over other languages. The JVM helps >>>> protect against changes of hardware and the ecosystem around the JVM >>>> is pretty vibrant, including many interesting languages besides just >>>> Java (i.e. Jython, Clojure, JRuby). There's also a large number of >>>> businesses using Java and great tools support. There's also a number >>>> of interesting concurrency things going on in the Java ecosystem >>>> (namely Actors in Groovy and Scala and Software Transactional Memory >>>> in Clojure). >>>> >>>> I think I'm alright with Java's speed when balancing against long-term >>>> viability and ease of development. I also like scaling my needs per >>>> language, as I couldn't script a piece of music in Java but could in >>>> Jython (python on java), as the speed required there isn't an issue. >>>> >>>> Go looks interesting though the syntax doesn't really appeal to me. >>>> I'll probably keep myself aware of it but being new I don't think it >>>> has enough around it yet to consider for personal projects. >>>> >>>> steven >>>> >>>> >>>> >>>> On Wed, Nov 11, 2009 at 1:31 PM, Michael Gogins >>>> <michael.gogins@...> wrote: >>>>> Speed will never stop being the main point. The only reason to bother >>>>> one's head programming a computer is that it will run faster than you >>>>> can run a pencil and paper. The faster, the better, period. As we >>>>> recently found, Csound users start to howl if there is a speed deficit >>>>> of 10% or more... >>>>> >>>>> C++ has now got, in my experience, adequate support for concurrency >>>>> with OpenMP. It is supported by all major compilers now including Sun >>>>> Studio, gcc, MinGW, and Microsoft. There is no need to switch away >>>>> from C++ to write parallel code. >>>>> >>>>> Almost all real software that has to run reliably and fast and that >>>>> people trust in danger is written in C++. Airplanes, ships, guns, >>>>> cars, computer games, particle physics experiments, database servers, >>>>> Web servers all run on C or C++ (with calls into numeric Fortran, I >>>>> admit). Almost all shrink-wrap commercial software is written in C++. >>>>> There must be a reason. >>>>> >>>>> In my view, a better language would simply be C++ with some additional >>>>> features -- and faster. And this is what we will get. >>>>> >>>>> That said, if someone comes up with Go or D or Haskell or Scala or >>>>> Lisp or O'Caml that actually runs faster than C++ and is not too >>>>> terribly difficult to use and can call into C libraries, I will be >>>>> among the first to use it. I'm still waiting... >>>>> >>>>> Regards, >>>>> Mike >>>>> >>>>> On 11/11/09, Richard Dobson <richarddobson@...> wrote: >>>>>> Michael Gogins wrote: >>>>>>> I'd be interested if it were faster than c++. >>>>>>> >>>>>>> Mkg >>>>>>> >>>>>> >>>>>> >>>>>> That may become an obsolete comparison in a few years. One of the >>>>>> 'selling points' of "Go" is support from the get-go (i.e. at the level >>>>>> of the language itself) of concurrency (it comes partly from an occam >>>>>> background); and if it proves, say, to be a good match for Intel's >>>>>> 80-core chip, it will likely easily eclipse C++, which has no such >>>>>> support other than through external libraries and which will be an >>>>>> awkward fit, at best, to such architectures. The DNA of C and C++ is >>>>>> still essentially sequential single-threaded. >>>>>> >>>>>> As I see it, a language such as "Go" is effectively running under >>>>>> emulation on a current-generation processor (even including 8-core ones) >>>>>> and OS. The somewhat modest attempts to add concurrency support to the >>>>>> forthcoming C++ standard are I suspect too little too late. Cracking off >>>>>> a few C++ threads on an 8-core processor will be modest compared to what >>>>>> will be needed in the next decade (or less, possibly). We will want to >>>>>> run either individual opcodes, or individual instruments, on each of >>>>>> those 80 cores. Who knows - maybe that famous Durham project of Csound >>>>>> on an array of Transputers may yet be able to enjoy a revival! >>>>>> >>>>>> Richard Dobson >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>>> 30-Day >>>>>> trial. Simplify your report design, integration and deployment - and >>>>>> focus >>>>>> on >>>>>> what you do best, core application coding. Discover what's new with >>>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@... >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Gogins >>>>> Irreducible Productions >>>>> http://www.michael-gogins.com >>>>> Michael dot Gogins at gmail dot com >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>>> 30-Day >>>>> trial. Simplify your report design, integration and deployment - and >>>>> focus on >>>>> what you do best, core application coding. Discover what's new with >>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and focus >>>> on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>> >>> -- >>> View this message in context: http://old.nabble.com/scaling-of-float-soundfiles-tp26213291p26313777.html >>> Sent from the Csound - Dev mailing list archive at Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>> trial. Simplify your report design, integration and deployment - and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@... >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@... >> https://lists.sourceforge.net/lists/listinfo/csound-devel >> > > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Csound-devel mailing list Csound-devel@... https://lists.sourceforge.net/lists/listinfo/csound-devel |
| Free embeddable forum powered by Nabble | Forum Help |