64-bit lang

[Josh Parmenter]

Hi all,

For various reason, I am thinking again about the 64-bit lang. What needs to be done for this to get going? Seems like it is time as more and more computer makers aren't even offering 32-bit machines anymore... what do others think?

Josh

******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[Arie van Schutterhoef]

>For various reason, I am thinking again about the 64-bit lang. What needs
>to be done for >this to get going?
-I think SC3 needs an architectural change before it really can benefit.
This was  what J.McC mentioned quit awhile ago in a discussion on 64-bit
Opterons in relation to the intention to get a machine with this/these
cpu's.

>Seems like it is time as more and more computer makers aren't even
>offering 32-bit >machines anymore... what do others think?
-This does not mean that a 32-bit SC3 can not run on it. All 64-bit cpu's
run 32-bit code without a problem.

AvS

......................................................................
......................................................................
     ` *===========================================================+++
     ` |arsche.net sound-image-word http://www.arsche.net/index.html |
       *===========================================================+++
     ` |Schreck Ensemble/Assembly - live electro-acoustic music-     |
     ` |             http://www.schreck.nl/index.html                |
     ` *===========================================================+++
     ` |S T R A T I F I E R - a multi-dimensional controller-        |
     ` |                  http://www.stratifier.nl/index.html        |
     ` *============================================================++
    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
......................................................................


_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[Julian Rohrhuber]

>Hi all,
>
>For various reason, I am thinking again about the 64-bit lang. What
>needs to be done for this to get going? Seems like it is time as
>more and more computer makers aren't even offering 32-bit machines
>anymore... what do others think?


as far as I know and remember it was mainly that there SC uses the
default type for float and double internally instead of defining its
own. For the server, all the places where a float variable is defined
would have to be changed, then one could run it on 64 bit, which
would make a lot of sense for some things.

In sclang, the object datatype is not so easily extendible to 64 bit
- James pointed out a couple of possible solutions, but each with
their own disadvantages.
--





.
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[Josh Parmenter]

Mostly, it seems like this is something that should be done at some  
point. While Arie points out (correctly) that 64-bit machines run 32-
bit code without a problem, it also seems to me that if we had 64-bit  
code, there would be improvements. I know this comes up frequently in  
Linux discussions...

Whether there needs to be an entire architecture change or not is  
another question. It has also been said that SCServer isn't going to  
go away. As far as the basics of the program are concerned, SC Server  
(3) has been the longest surviving SC, and with support now on Linux,  
Windows and Mac, I don't see it going anywhere fast. Its open-source  
status also gives me comfort that I will be using it for years to come  
(unlike the feeling of dread I remember as the days when OS 9 and SC2  
were winding down).

If the issue is the tedium and time, I think it is something that  
should be done. I'm looking ahead to a few months of sitting around  
while a new kid naps, and no major SC release deadlines on the horizon  
(no SC 3.2 like projects coming up). So - I'm thinking, is it time to  
start this work? Figure out what needs to be done and do it? Or should  
this be a topic at the next symposium that gets serious attention?

Best,

Josh


On May 14, 2008, at 2:13 PM, Julian Rohrhuber wrote:

>> Hi all,
>>
>> For various reason, I am thinking again about the 64-bit lang. What
>> needs to be done for this to get going? Seems like it is time as
>> more and more computer makers aren't even offering 32-bit machines
>> anymore... what do others think?
>
>
> as far as I know and remember it was mainly that there SC uses the
> default type for float and double internally instead of defining its
> own. For the server, all the places where a float variable is defined
> would have to be changed, then one could run it on 64 bit, which
> would make a lot of sense for some things.
>
> In sclang, the object datatype is not so easily extendible to 64 bit
> - James pointed out a couple of possible solutions, but each with
> their own disadvantages.
> --
>
>
>
>
>
> .
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[kernel-12]

maybe I'm off the pace but i seem to remember James Mc mentioning he  
had started work on a 64 bit lang and something about a big search and  
replace.  I thought this work became a fork or pseudo fork of the  
standard lang distro.. no?  I'm curious about which parts of the lang  
will benefit.

kernel

On 14 May 2008, at 15:43, Josh Parmenter wrote:

> Mostly, it seems like this is something that should be done at some
> point. While Arie points out (correctly) that 64-bit machines run 32-
> bit code without a problem, it also seems to me that if we had 64-bit
> code, there would be improvements. I know this comes up frequently in
> Linux discussions...
>
> Whether there needs to be an entire architecture change or not is
> another question. It has also been said that SCServer isn't going to
> go away. As far as the basics of the program are concerned, SC Server
> (3) has been the longest surviving SC, and with support now on Linux,
> Windows and Mac, I don't see it going anywhere fast. Its open-source
> status also gives me comfort that I will be using it for years to come
> (unlike the feeling of dread I remember as the days when OS 9 and SC2
> were winding down).
>
> If the issue is the tedium and time, I think it is something that
> should be done. I'm looking ahead to a few months of sitting around
> while a new kid naps, and no major SC release deadlines on the horizon
> (no SC 3.2 like projects coming up). So - I'm thinking, is it time to
> start this work? Figure out what needs to be done and do it? Or should
> this be a topic at the next symposium that gets serious attention?
>
> Best,
>
> Josh
>
>
> On May 14, 2008, at 2:13 PM, Julian Rohrhuber wrote:
>
>>> Hi all,
>>>
>>> For various reason, I am thinking again about the 64-bit lang. What
>>> needs to be done for this to get going? Seems like it is time as
>>> more and more computer makers aren't even offering 32-bit machines
>>> anymore... what do others think?
>>
>>
>> as far as I know and remember it was mainly that there SC uses the
>> default type for float and double internally instead of defining its
>> own. For the server, all the places where a float variable is defined
>> would have to be changed, then one could run it on 64 bit, which
>> would make a lot of sense for some things.
>>
>> In sclang, the object datatype is not so easily extendible to 64 bit
>> - James pointed out a couple of possible solutions, but each with
>> their own disadvantages.
>> --
>>
>>
>>
>>
>>
>> .
>> _______________________________________________
>> Sc-devel mailing list
>> Sc-devel@...
>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
> ******************************************
> /* Joshua D. Parmenter
> http://www.realizedsound.net/josh/
>
> “Every composer – at all times and in all cases – gives his own
> interpretation of how modern society is structured: whether actively
> or passively, consciously or unconsciously, he makes choices in this
> regard. He may be conservative or he may subject himself to continual
> renewal; or he may strive for a revolutionary, historical or social
> palingenesis." - Luigi Nono
> */
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[Josh Parmenter]

There was a branch, but that was well before 3.2. I'd be surprised if  
they are synced anymore.

I'll look into it a bit though. That may give an idea of what needs to  
be done.

Not sure what would be faster. I'm trying to find the original post  
from James McC, but it may be on the old sc-dev that is lost.

Josh


On May 14, 2008, at 6:09 PM, kernel wrote:

> maybe I'm off the pace but i seem to remember James Mc mentioning he
> had started work on a 64 bit lang and something about a big search and
> replace.  I thought this work became a fork or pseudo fork of the
> standard lang distro.. no?  I'm curious about which parts of the lang
> will benefit.
>
> kernel
>
> On 14 May 2008, at 15:43, Josh Parmenter wrote:
>
>> Mostly, it seems like this is something that should be done at some
>> point. While Arie points out (correctly) that 64-bit machines run 32-
>> bit code without a problem, it also seems to me that if we had 64-bit
>> code, there would be improvements. I know this comes up frequently in
>> Linux discussions...
>>
>> Whether there needs to be an entire architecture change or not is
>> another question. It has also been said that SCServer isn't going to
>> go away. As far as the basics of the program are concerned, SC Server
>> (3) has been the longest surviving SC, and with support now on Linux,
>> Windows and Mac, I don't see it going anywhere fast. Its open-source
>> status also gives me comfort that I will be using it for years to  
>> come
>> (unlike the feeling of dread I remember as the days when OS 9 and SC2
>> were winding down).
>>
>> If the issue is the tedium and time, I think it is something that
>> should be done. I'm looking ahead to a few months of sitting around
>> while a new kid naps, and no major SC release deadlines on the  
>> horizon
>> (no SC 3.2 like projects coming up). So - I'm thinking, is it time to
>> start this work? Figure out what needs to be done and do it? Or  
>> should
>> this be a topic at the next symposium that gets serious attention?
>>
>> Best,
>>
>> Josh
>>
>>
>> On May 14, 2008, at 2:13 PM, Julian Rohrhuber wrote:
>>
>>>> Hi all,
>>>>
>>>> For various reason, I am thinking again about the 64-bit lang. What
>>>> needs to be done for this to get going? Seems like it is time as
>>>> more and more computer makers aren't even offering 32-bit machines
>>>> anymore... what do others think?
>>>
>>>
>>> as far as I know and remember it was mainly that there SC uses the
>>> default type for float and double internally instead of defining its
>>> own. For the server, all the places where a float variable is  
>>> defined
>>> would have to be changed, then one could run it on 64 bit, which
>>> would make a lot of sense for some things.
>>>
>>> In sclang, the object datatype is not so easily extendible to 64 bit
>>> - James pointed out a couple of possible solutions, but each with
>>> their own disadvantages.
>>> --
>>>
>>>
>>>
>>>
>>>
>>> .
>>> _______________________________________________
>>> Sc-devel mailing list
>>> Sc-devel@...
>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>
>> ******************************************
>> /* Joshua D. Parmenter
>> http://www.realizedsound.net/josh/
>>
>> “Every composer – at all times and in all cases – gives his own
>> interpretation of how modern society is structured: whether actively
>> or passively, consciously or unconsciously, he makes choices in this
>> regard. He may be conservative or he may subject himself to continual
>> renewal; or he may strive for a revolutionary, historical or social
>> palingenesis." - Luigi Nono
>> */
>>
>> _______________________________________________
>> Sc-devel mailing list
>> Sc-devel@...
>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[Florian Schmidt]

On Wednesday 14 May 2008, Arie van Schutterhoef wrote:

> >For various reason, I am thinking again about the 64-bit lang. What needs
> >to be done for >this to get going?
>
> -I think SC3 needs an architectural change before it really can benefit.
> This was  what J.McC mentioned quit awhile ago in a discussion on 64-bit
> Opterons in relation to the intention to get a machine with this/these
> cpu's.
>
> >Seems like it is time as more and more computer makers aren't even
> >offering 32-bit >machines anymore... what do others think?
>
> -This does not mean that a 32-bit SC3 can not run on it. All 64-bit cpu's
> run 32-bit code without a problem.

This is too bland a statement. And besides: While this is true for the
X86-architecture (and maybe PowerPC which i have no clue about) it still is
an organizational problem. You need 32 bit versions of all libs required,
etc, maybe even setup a chroot environment.

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[stefan kersten-2]

On 15.05.2008, at 03:23, Josh Parmenter wrote:
> There was a branch, but that was well before 3.2. I'd be surprised if
> they are synced anymore.
>
> I'll look into it a bit though. That may give an idea of what needs to
> be done.

jmc and i started to work on a 64 bit version independently (james  
got a little farther).

jmc's branch is here: http://supercollider.sourceforge.net/mod/ 
resource/view.php?id=31
my version is here: http://space.k-hornz.de/files/ 
SuperCollider3-64.tar.bz2

from what i recall the main difference was that my version can switch  
between 32 and 64 bit by redefining a macro, but there were still  
some severe bugs concerning the garbage collector.

> Not sure what would be faster. I'm trying to find the original post
> from James McC, but it may be on the old sc-dev that is lost.

i agree it would be worth doing a 64 bit port, but at this point it's  
probably easier to do the find/replace again, taking inspirations  
from the branches posted above. i'm not in a position to do it myself  
right now, but whoever succeeds i'm sure will find a place in SC  
mythology.

here's the original thread on sc-dev in case it has vanished from the  
internetz:

http://space.k-hornz.de/pub/sc-dev_64_bit_clean_SC.mbox

<sk>

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[stefan kersten-2]

hi julian,

On 14.05.2008, at 23:13, Julian Rohrhuber wrote:
>> as far as I know and remember it was mainly that there SC uses the
> default type for float and double internally instead of defining its
> own. For the server, all the places where a float variable is defined
> would have to be changed, then one could run it on 64 bit, which
> would make a lot of sense for some things.
>
> In sclang, the object datatype is not so easily extendible to 64 bit
> - James pointed out a couple of possible solutions, but each with
> their own disadvantages.

scsynth already runs on 64 bit and the float vs double issue only has to
do with audio resolution. it's sclang's way of packing a pointer into a
machine double that stops working on 64 bit.

<sk>

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[ronald kuivila]

Hi Stefan,

   Right, so a 64 bit version is likely to run slower than a 32 bit  
version.
But, it seems to me that the real motivation behind making a 64 bit  
version
is lengthen the lifespan of the whole project.  In the long term, it  
is likely that it will get increasingly
difficult to keep a 32  bit version running.

RJK


On May 15, 2008, at 6:04 AM, stefan kersten wrote:

> hi julian,
>
> On 14.05.2008, at 23:13, Julian Rohrhuber wrote:
>>> as far as I know and remember it was mainly that there SC uses the
>> default type for float and double internally instead of defining its
>> own. For the server, all the places where a float variable is defined
>> would have to be changed, then one could run it on 64 bit, which
>> would make a lot of sense for some things.
>>
>> In sclang, the object datatype is not so easily extendible to 64 bit
>> - James pointed out a couple of possible solutions, but each with
>> their own disadvantages.
>
> scsynth already runs on 64 bit and the float vs double issue only  
> has to
> do with audio resolution. it's sclang's way of packing a pointer  
> into a
> machine double that stops working on 64 bit.
>
> <sk>
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[stefan kersten-2]

hi ron,

On 15.05.2008, at 14:42, ronald kuivila wrote:
>    Right, so a 64 bit version is likely to run slower than a 32 bit
> version.
> But, it seems to me that the real motivation behind making a 64 bit
> version
> is lengthen the lifespan of the whole project.  In the long term, it
> is likely that it will get increasingly
> difficult to keep a 32  bit version running.

i totally agree, my comment was aimed at clarifying that there is no
change necessary for scsynth to run on 64 bit.

<sk>

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[ronald kuivila]

Hi Stefan and Josh,

  Actually, a 64 bit server or, at least, 64 bit implementations of  
filter internal states  might have a significant
impact on the audio performance of SC (less round-off error, better  
filter accuracy at low cutoff frequencies).
What is entailed in compiling the server and associated plug-ins as  
64 bit?

   This might be a moment to ask whether buffers should support  
different word sizes (so you could have
16 bit integer samples or 32 bit floats in a buffer). (16 bytes per  
stereo frame seems a bit extravagant.)

   Extending buffer, DiskIn, BufRd, BufWr, and PlayBuf to support  
multiple word sizes sounds like a good project in itself.
I guess one major problem is how to do this without breaking the OSC  
interface.  Perhaps it would be cleanest to add a
new command name (perhaps /b_allocRaw) with wordsize, signed/
unsigned, and alignment arguments.


Cheers,

RJK


On May 15, 2008, at 10:05 AM, stefan kersten wrote:

> hi ron,
>
> On 15.05.2008, at 14:42, ronald kuivila wrote:
>>    Right, so a 64 bit version is likely to run slower than a 32 bit
>> version.
>> But, it seems to me that the real motivation behind making a 64 bit
>> version
>> is lengthen the lifespan of the whole project.  In the long term, it
>> is likely that it will get increasingly
>> difficult to keep a 32  bit version running.
>
> i totally agree, my comment was aimed at clarifying that there is no
> change necessary for scsynth to run on 64 bit.
>
> <sk>
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[kernel-12]

On 15 May 2008, at 08:59, ronald kuivila wrote:

> Actually, a 64 bit server or, at least, 64 bit implementations of
> filter internal states  might have a significant
> impact on the audio performance of SC (less round-off error, better
> filter accuracy at low cutoff frequencies).

In my work outside SC I implemented some resonant digital filters  
using double precision coefficients and compared the results against  
normal 32 bit float coefficients.  In each case I stored the resulting  
audio as floats or doubles respectively.  In short the filters sounded  
smoother when using double precision especially when sweeping the  
cutoff.  Even using double precision for the coefficients but  
rendering audio to floats might have a noticeable effect.  I believe  
most envelope generators do that.  I tested on a PPC G4 1.33 and  
noticed a very marginal increase in CPU between the two versions.  I  
was expecting something larger.

I don't know what other DSP algorithms/processes would benefit from  
double precision.  FFT stuff maybe?  Perhaps using doubles would  
noticeably reduce rounding errors when chaining lots of UGens in a  
signal graph where each UGen is feeding off another.


> What is entailed in compiling the server and associated plug-ins as
> 64 bit?

Much fiddling around I imagine :)  Memory allocation, pointers to  
memory, UGen code etc.  I'm just guessing really though.

kernel
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[Dan Stowell]

2008/5/16 kernel <kernel@...>:

> On 15 May 2008, at 08:59, ronald kuivila wrote:
>
>> Actually, a 64 bit server or, at least, 64 bit implementations of
>> filter internal states  might have a significant
>> impact on the audio performance of SC (less round-off error, better
>> filter accuracy at low cutoff frequencies).
>
> In my work outside SC I implemented some resonant digital filters
> using double precision coefficients and compared the results against
> normal 32 bit float coefficients.  In each case I stored the resulting
> audio as floats or doubles respectively.  In short the filters sounded
> smoother when using double precision especially when sweeping the
> cutoff.  Even using double precision for the coefficients but
> rendering audio to floats might have a noticeable effect.  I believe
> most envelope generators do that.  I tested on a PPC G4 1.33 and
> noticed a very marginal increase in CPU between the two versions.  I
> was expecting something larger.
>
> I don't know what other DSP algorithms/processes would benefit from
> double precision.  FFT stuff maybe?  Perhaps using doubles would
> noticeably reduce rounding errors when chaining lots of UGens in a
> signal graph where each UGen is feeding off another.
>
>
>> What is entailed in compiling the server and associated plug-ins as
>> 64 bit?
>
> Much fiddling around I imagine :)  Memory allocation, pointers to
> memory, UGen code etc.  I'm just guessing really though.

But scsynth and the UGen API treats signals as the standard "float"
data-type, which would be handled straightforwardly when compiling on
64-bit, surely? No changes needed there. Memory allocation is always
done using "n * sizeof(float)" etc. I can't think of anything in the
*server* that is fragile about the bit-depth of floats.

Dan
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[nescivi]

scsynth compiles and runs perfectly fine 64bit. I have been running it
for a couple of months now on my new laptop, and others have been
running it for longer. The swiki contains instruction on how to set up
a system on Linux, using 64bit scsynth and 32bit sclang.

DiskIn and DiskOut depend on the file formats that libsndfile support
and most of these file formats are not 64bit, as far as I know.

sincerely,
Marije
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[stefan kersten-2]

On 16.05.2008, at 03:08, kernel wrote:

> On 15 May 2008, at 08:59, ronald kuivila wrote:
>
>> Actually, a 64 bit server or, at least, 64 bit implementations of
>> filter internal states  might have a significant
>> impact on the audio performance of SC (less round-off error, better
>> filter accuracy at low cutoff frequencies).
>
> In my work outside SC I implemented some resonant digital filters
> using double precision coefficients and compared the results against
> normal 32 bit float coefficients.  In each case I stored the resulting
> audio as floats or doubles respectively.  In short the filters sounded
> smoother when using double precision especially when sweeping the
> cutoff.  Even using double precision for the coefficients but
> rendering audio to floats might have a noticeable effect.  I believe
> most envelope generators do that.  I tested on a PPC G4 1.33 and
> noticed a very marginal increase in CPU between the two versions.  I
> was expecting something larger.

did you quantify your results or did you only do informal listening
tests? could be interesting to have a meaningful metric for the actual
differences in SNR etc. hmm, i'm sure there must be papers about
coefficient quantization ...

> I don't know what other DSP algorithms/processes would benefit from
> double precision.  FFT stuff maybe?  Perhaps using doubles would
> noticeably reduce rounding errors when chaining lots of UGens in a
> signal graph where each UGen is feeding off another.

i'm pretty confident that the difference in quantization error between a
32 bit float and a 64 bit double is unnoticable audibly and that only
for filter coefficients and where roundoff errors accumulate in filter
states you will actually hear a difference.

>> What is entailed in compiling the server and associated plug-ins as
>> 64 bit?
>
> Much fiddling around I imagine :)  Memory allocation, pointers to
> memory, UGen code etc.  I'm just guessing really though.

let's not confuse the issue of using double floating point for audio
computation vs. a 64 bit address space. the latter is not an issue for
scsynth, it compiles fine on a 64 bit architecture and can use the full
64 bit address space. as to the former, i'd suggest conducting
conclusive experiments before making vast code changes. i
would imagine that the float vs. double issue only makes a real
difference in a limited number of cases (such as recursive filters and
oscillators). csound can be compiled using double audio samples btw., so
maybe it could be used for comparison (i'm not sure if the compile time
switch affects filter coefficients, too, though).

<sk>

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel