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@lists.sourceforge.net

It 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@lists.sourceforge.net
> 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@lists.sourceforge.net

OK 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@lists.sourceforge.net

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@lists.sourceforge.net

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.


Richard Dobson wrote:
> 
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 

-- 
View this message in context: http://old.nabble.com/scaling-of-float-soundfiles-tp26213291p26300110.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@lists.sourceforge.net

I'd be interested if it were faster than c++.

Mkg

On Nov 11, 2009 7:06 AM, "edexter5" <Eric_Dexter@msn.com> wrote:


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.

Richard Dobson wrote: > > Google's new "Go" language: > > http://golang.org/ > > supports concu...

--
View this message in context: http://old.nabble.com/scaling-of-float-soundfiles-tp26213291p26300110.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------ Let Crystal Reports...

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@lists.sourceforge.net

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  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@lists.sourceforge.net
> 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@lists.sourceforge.net

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
 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  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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> 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@lists.sourceforge.net

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
>  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  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@lists.sourceforge.net
>>> 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi

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  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
>>  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  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@lists.sourceforge.net
>>>> 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@lists.sourceforge.net
>>> 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> 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@lists.sourceforge.net

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  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  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
>>>  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  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@lists.sourceforge.net
>>>>> 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@lists.sourceforge.net
>>>> 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@lists.sourceforge.net
>>> 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> 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@lists.sourceforge.net

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
 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  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  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
>>>>  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  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@lists.sourceforge.net
>>>>>> 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@lists.sourceforge.net
>>>>> 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@lists.sourceforge.net
>>>> 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@lists.sourceforge.net
>>> 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@lists.sourceforge.net
>> 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@lists.sourceforge.net
> 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@lists.sourceforge.net