....but we do now develop on 64bit architecture; I keep one 32bit
machins for final builds.
==John ffitch

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

There are actually three, count them three, levels of 64 here.

(1) "32" or "64" bit sample size (actually float or double). We have
decided this one and are done with it.

(2) 32 or 64 bit platform (operating system). This may or may not be
what you are talking about. It's not what I am talking about.

(3) 32 or 64 bit architecture (code generation). This may or may not
be what you are talking about. It is what I am talking about.

All three major contemporary operating systems (Linux, OS X, and
Windows) are 64 bit architecture operating systems that can run 32 bit
architecture code as well as 64 bit architecture code. This seems to
be the source of some ambiguity in these discussions.

To make myself as clear as possible, I propose that Csound 6 be
targeted by default for 64 bit architecture that will run only on 64
bit operating systems, using double precision samples. It should also
be possible to target Csound 6 for 32 bit architecture that will run
on both 64 bit and 32 bit operating systems. I would like to drop the
32 bit sample size altogether.

Regards,
Mike





On Sun, Feb 26, 2012 at 1:58 PM, john ffitch  wrote:
> ....but we do now develop on 64bit architecture; I keep one 32bit
> machins for final builds.
> ==John ffitch
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> 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

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On OSX we currently develop on both 64 and 32 bit architectures, as we produce a FAT binary containing both.
On 26 Feb 2012, at 19:52, Michael Gogins wrote:

> There are actually three, count them three, levels of 64 here.
> 
> (1) "32" or "64" bit sample size (actually float or double). We have
> decided this one and are done with it.
> 
> (2) 32 or 64 bit platform (operating system). This may or may not be
> what you are talking about. It's not what I am talking about.
> 
> (3) 32 or 64 bit architecture (code generation). This may or may not
> be what you are talking about. It is what I am talking about.
> 
> All three major contemporary operating systems (Linux, OS X, and
> Windows) are 64 bit architecture operating systems that can run 32 bit
> architecture code as well as 64 bit architecture code. This seems to
> be the source of some ambiguity in these discussions.
> 
> To make myself as clear as possible, I propose that Csound 6 be
> targeted by default for 64 bit architecture that will run only on 64
> bit operating systems, using double precision samples. It should also
> be possible to target Csound 6 for 32 bit architecture that will run
> on both 64 bit and 32 bit operating systems. I would like to drop the
> 32 bit sample size altogether.
> 
> Regards,
> Mike
> 
> 
> 
> 
> 
> On Sun, Feb 26, 2012 at 1:58 PM, john ffitch  wrote:
>> ....but we do now develop on 64bit architecture; I keep one 32bit
>> machins for final builds.
>> ==John ffitch
>> 
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> 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
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

As mentioned, we need the float build now for arm cpu builds.  For
64-bit, there's no problem targeting by default, but as I mentioned,
the issues with 32-bit/64-bit are already solved problems on OSX and
Linux. It's really just Windows that needs to get up to date.  We just
need to work out the build process for that.

On Sun, Feb 26, 2012 at 7:52 PM, Michael Gogins
 wrote:
> There are actually three, count them three, levels of 64 here.
>
> (1) "32" or "64" bit sample size (actually float or double). We have
> decided this one and are done with it.
>
> (2) 32 or 64 bit platform (operating system). This may or may not be
> what you are talking about. It's not what I am talking about.
>
> (3) 32 or 64 bit architecture (code generation). This may or may not
> be what you are talking about. It is what I am talking about.
>
> All three major contemporary operating systems (Linux, OS X, and
> Windows) are 64 bit architecture operating systems that can run 32 bit
> architecture code as well as 64 bit architecture code. This seems to
> be the source of some ambiguity in these discussions.
>
> To make myself as clear as possible, I propose that Csound 6 be
> targeted by default for 64 bit architecture that will run only on 64
> bit operating systems, using double precision samples. It should also
> be possible to target Csound 6 for 32 bit architecture that will run
> on both 64 bit and 32 bit operating systems. I would like to drop the
> 32 bit sample size altogether.
>
> Regards,
> Mike
>
>
>
>
>
> On Sun, Feb 26, 2012 at 1:58 PM, john ffitch  wrote:
>> ....but we do now develop on 64bit architecture; I keep one 32bit
>> machins for final builds.
>> ==John ffitch
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sun, Feb 26, 2012 at 2:52 PM, Michael Gogins
 wrote:
> I would like to drop the
> 32 bit sample size altogether.

Is it so hard to support 32 bit sample sizes?  What problems would
limiting the sample size to 64 bits solve?

Cheers,
~ andy.f

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

My main motive for proposing double-precision samples only is
simplicity. This shouldn't be underestimated. It makes it easier to
write the software and easier to maintain it. This is all the more the
case in that we will probably rewrite most of the core of Csound. In
my view the performance impact is either a wash, or not large. And
there is a significant gain in accuracy.

In short, double precision samples only gives us better code and more
time to work on other things.

Note that Max 6, Csound's main competition, now supports
double-precision samples only.

But of course, supporting single-precision samples is not so terribly
difficult. We do, after all, do it now. But I would like to take
advantage of your question to address broader issues of performance
and software architecture.

I pay a certain amount of attention to trends in commercial audio
software. Leading commercial applications, the ones that are standard
in most music studios, are now as follows. I put this together in a
hurry and I may have missed some things, but the information presented
is from the manufacturers.

Max 6, software synthesizer with audio and video programming.
Double-precision samples only, 32 bit architecture, 64 bit
architecture is planned, multi-threading, some GPU computing. Max is
Csound's main competition.

Pro Tools HD (industry standard digital audio workstation),
single-precision samples, 192 KHz frame rate, 32 bit architecture
(AFAICT).

Sonar X1 Producer (digital audio workstation), single-precision
samples, double-precision engine, 192 KHz frame rate, 32 bit
architecture. Sonar x64 is similar but has 64 bit architecture.

Neundo 5.5 (digital audio workstation and post-production),
single-precision samples, 192 KHz frame rate, 32 bit and 64 bit
architecture, multi-threaded.

Cubase 6 (digital audio workstation), single-precision samples, 192
KHz frame rate, 32 bit and 64 bit architecture, multi-threaded.

Ableton Live (live performance sequencer, digital audio workstation),
32 bit architecture, 64 bit architecture is planned.

Sibelius (notation with VST plugin and sampler playback), 64 bit
architecture only.

To sum this up, the main mission of Csound is to be the most powerful
possible programmable software synthesizer, within the limitations of
our resources (i.e. we don't use the Intel performance libraries as
most of this software probably does).

Csound is OK for now. We have single- or double-precision samples and
multi-threading. But we are in the middle of the class. We can and
should do better.

To move to the head of the class, Csound needs double-precision
samples, 64 bit architecture, better multi-threading, and GPU
computing.

Regards,
Mike


On Sun, Feb 26, 2012 at 4:57 PM, andy fillebrown
 wrote:
> On Sun, Feb 26, 2012 at 2:52 PM, Michael Gogins
>  wrote:
>> I would like to drop the
>> 32 bit sample size altogether.
>
> Is it so hard to support 32 bit sample sizes?  What problems would
> limiting the sample size to 64 bits solve?
>
> Cheers,
> ~ andy.f
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> 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

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree with you on many points but I don't think limiting the
floating-point precision to doubles is going to provide a significant
enough reduction in development time to justify alienating the lower
powered cpus available in mobile platforms, and on older desktops the
performance impact is definitely not a wash.  When I'm maxing out the
user's cpu(s) on graphics intensive tasks such as pushing large meshes
to the gpu and updating scopes in real-time, I most definitely do not
want the audio engine wasting time doing everything in double
precision when the end result is 16 bit integers.

Ultimately, it's not up to me since I'm not a Csound dev.  I'm just
saying what my needs are as a user of the api.  Audio quality and ease
of development are not my top priorities.  Speed is.

Cheers,
~ andy.f



On Mon, Feb 27, 2012 at 12:01 AM, Michael Gogins
 wrote:
> My main motive for proposing double-precision samples only is
> simplicity. This shouldn't be underestimated. It makes it easier to
> write the software and easier to maintain it. This is all the more the
> case in that we will probably rewrite most of the core of Csound. In
> my view the performance impact is either a wash, or not large. And
> there is a significant gain in accuracy.
>
> In short, double precision samples only gives us better code and more
> time to work on other things.
>
> Note that Max 6, Csound's main competition, now supports
> double-precision samples only.
>
> But of course, supporting single-precision samples is not so terribly
> difficult. We do, after all, do it now. But I would like to take
> advantage of your question to address broader issues of performance
> and software architecture.
>
> I pay a certain amount of attention to trends in commercial audio
> software. Leading commercial applications, the ones that are standard
> in most music studios, are now as follows. I put this together in a
> hurry and I may have missed some things, but the information presented
> is from the manufacturers.
>
> Max 6, software synthesizer with audio and video programming.
> Double-precision samples only, 32 bit architecture, 64 bit
> architecture is planned, multi-threading, some GPU computing. Max is
> Csound's main competition.
>
> Pro Tools HD (industry standard digital audio workstation),
> single-precision samples, 192 KHz frame rate, 32 bit architecture
> (AFAICT).
>
> Sonar X1 Producer (digital audio workstation), single-precision
> samples, double-precision engine, 192 KHz frame rate, 32 bit
> architecture. Sonar x64 is similar but has 64 bit architecture.
>
> Neundo 5.5 (digital audio workstation and post-production),
> single-precision samples, 192 KHz frame rate, 32 bit and 64 bit
> architecture, multi-threaded.
>
> Cubase 6 (digital audio workstation), single-precision samples, 192
> KHz frame rate, 32 bit and 64 bit architecture, multi-threaded.
>
> Ableton Live (live performance sequencer, digital audio workstation),
> 32 bit architecture, 64 bit architecture is planned.
>
> Sibelius (notation with VST plugin and sampler playback), 64 bit
> architecture only.
>
> To sum this up, the main mission of Csound is to be the most powerful
> possible programmable software synthesizer, within the limitations of
> our resources (i.e. we don't use the Intel performance libraries as
> most of this software probably does).
>
> Csound is OK for now. We have single- or double-precision samples and
> multi-threading. But we are in the middle of the class. We can and
> should do better.
>
> To move to the head of the class, Csound needs double-precision
> samples, 64 bit architecture, better multi-threading, and GPU
> computing.
>
> Regards,
> Mike
>
>
> On Sun, Feb 26, 2012 at 4:57 PM, andy fillebrown
>  wrote:
>> On Sun, Feb 26, 2012 at 2:52 PM, Michael Gogins
>>  wrote:
>>> I would like to drop the
>>> 32 bit sample size altogether.
>>
>> Is it so hard to support 32 bit sample sizes?  What problems would
>> limiting the sample size to 64 bits solve?
>>
>> Cheers,
>> ~ andy.f
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Ok, its finally penetrating my thick skull that float is mainly about arm and devices. Of course we do need float samples for them.