I am not in favour of abandoning scons and moving
to a different build system. This build system has
worked well on all three platforms and I do not
see any reason to have to move away from it. It would
mean having to adapt to a new system and I don't
think this is worth the trouble.

Victor

>
> I am not very fond of scons. Thus, I started work on an
> alternate build system  with CMake. Why? There are several
> reasons:
>  * CMake is also cross-platform
>  * Separation of configure, build and install phases. This
> is very important  since usually lots of time are spent
> searching for python, java, lua,  sndfile, etc, and there
> is no need to do it more than once.
>  * CMake does not attempt to replace make. It only
> replaces auto*, and then it  generates several makefiles.
> One then can use make as usual to override  flags, etc.
>  * CMake syntax is clearer, as it was specifically
> designed to build stuff.
>  * Clearer separation of logic and target specification.
>  * Allows for out-of-tree builds (ie, build in a directory
> different from the  source directory).
>
> So I have a preliminary build system. It is nowhere near
> complete, and only  works on linux (more specifically, my
> computer :p). However adding support  for different
> platforms should not be difficult. Currently it builds
> most  stuff that I'm building for the Debian distribution,
> although there is no  possibility of configuration yet,
> and fails when stuff is not found, and,  most importantly,
> does not yet install anything.
>
> The patch consist mostly of adding CMakeLists.txt files,
> but there are 2 files  that were changed because some fltk
> stuff is named differently, and was  easier to change the
> source files than CMake's FLTK wrapper functions.
>
> Comments appreciated.
>
>
> --
>
>     Felipe Sateler
>
>
>
>
> ----------------------------------------------------------
> --------------- This SF.net email is sponsored by: Splunk
> Inc. Still grepping through log files to find problems?
> Stop. Now Search log events and configuration files using
> AJAX and a browser. Download your FREE copy of Splunk now
> >>  http://get.splunk.com/
>
>
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> [Attachment: cmake.patch]
> [Attachment: fsateler@gmail.com.sig]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Just a suggestion:

Add an option in GEN01 for loading audio files in a separate low- 
priority thread so they do not interrupt performance.

greg

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

matt ingalls wrote:

> also a separate thread for disk i/o for soundin/diskin would be great.
> 
> ever since the move to sndfilelib the real-time performance
> has not been good.  ( in csound4 i was able to make a diskin instrument
> and play live via MIDI with no clicks -- i can't do that in csound5!!! )

The main thing to be careful about is file endian-ness. Loading AIFF 
files on Intel CPUs or loading WAV files on PowerPC is going to be
much slower than loading AIFF files on PowerPC or WAV files in Intel
because of the byte swapping required.

Furthermore, if you want to make your files load quickly, it makes 
sense to store them on disk in the same format you are reading them
since this will give you the fastest path through libsndfile. Since 
Csound uses floats/doubles internally, it makes sense to store the 
source files as floats/double on disk.

I also notice that the diskin opcode reads in 4096 samples at a time.
Thats quite a small buffer considering the amount of memory in the
machines people are likely to be running Csound on. Reading files via
libsndfile has a per sample read cost and a cost for calling the
read function. As you increase the read size, you reduce the per sample
cost of calling the read and approach the per sample read cost.

Finally, memory is *really* cheap these days. Preloading the audio
data from the file on disk into memory makes a lot of sense when the
files are small (ie small means less than a couple of meg).

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Two hands working can do more than a thousand clasped in prayer."
-- anonymous

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Do you have any numbers that show this byte-swapping cost?  I'm sure  
there is some time lost there, but its probably negligible.  I'd be  
curious to see a few test results
I think buffer size is a much larger determinant.  Also converting  
from fixed to float might cost a fair amount of time.  And, I could  
be wrong, but I believe traditional AIFF file can only be represented  
as integers (and probably WAVE as well).  I think the AIFC format  
supports floating point ...  its been awhile since I've messed with  
formats.

But larger buffer size doesn't necessarily equal faster load time.   
The curve certainly isn't linear.  There is probably a sweet spot  
where the values match cache sizes, etc...

Yes, pre-loading is great when you know ahead of time what you will  
need, but sometimes you are processing audio and you want to let the  
user decide what to load.

And so --- in the original case I was mentioning, I don't care if it  
loads "slowly" in a low priority, just so long as it doesn't  
interrupt current processing.

Is anyone going to take a stab at this or am I to assume if I want it  
done, I will have to do it myself?  Is this not important to anyone  
else?

greg

On Sep 2, 2007, at 9:11 PM, Erik de Castro Lopo wrote:

> matt ingalls wrote:
>
>> also a separate thread for disk i/o for soundin/diskin would be  
>> great.
>>
>> ever since the move to sndfilelib the real-time performance
>> has not been good.  ( in csound4 i was able to make a diskin  
>> instrument
>> and play live via MIDI with no clicks -- i can't do that in  
>> csound5!!! )
>
> The main thing to be careful about is file endian-ness. Loading AIFF
> files on Intel CPUs or loading WAV files on PowerPC is going to be
> much slower than loading AIFF files on PowerPC or WAV files in Intel
> because of the byte swapping required.
>
> Furthermore, if you want to make your files load quickly, it makes
> sense to store them on disk in the same format you are reading them
> since this will give you the fastest path through libsndfile. Since
> Csound uses floats/doubles internally, it makes sense to store the
> source files as floats/double on disk.
>
> I also notice that the diskin opcode reads in 4096 samples at a time.
> Thats quite a small buffer considering the amount of memory in the
> machines people are likely to be running Csound on. Reading files via
> libsndfile has a per sample read cost and a cost for calling the
> read function. As you increase the read size, you reduce the per  
> sample
> cost of calling the read and approach the per sample read cost.
>
> Finally, memory is *really* cheap these days. Preloading the audio
> data from the file on disk into memory makes a lot of sense when the
> files are small (ie small means less than a couple of meg).
>
> Erik
> -- 
> -----------------------------------------------------------------
> Erik de Castro Lopo
> -----------------------------------------------------------------
> "Two hands working can do more than a thousand clasped in prayer."
> -- anonymous
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Greg Thompson wrote:

> Do you have any numbers that show this byte-swapping cost?

Its old data, but I seem to remember that reading byte swapped
floats was about half as fast as native floats.

>  I'm sure  
> there is some time lost there, but its probably negligible.
>  I'd be  
> curious to see a few test results

In the tests/ directory of the libsndfile source code there is
a benchmark program. Feel free to run that on your own hardware.

> I think buffer size is a much larger determinant.  Also converting  
> from fixed to float might cost a fair amount of time.

Converting int to float is cheap, while float to int is more expensive.

>  And, I could  
> be wrong, but I believe traditional AIFF file can only be represented  
> as integers (and probably WAVE as well).

Both WAV and AIFF/AIFC (and many other formats) support both 32 and 
64 bit float data.

>  I think the AIFC format  
> supports floating point ...  its been awhile since I've messed with  
> formats.

Well yes. I don't really much much distinction between AIFF and AIFC.
For PCM data I write an AIFF header and for float I write an AIFC 
header. Apart from that, they are not different enough to be considered
distinct formats.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"C is a programming language. C++ is a cult."
-- David Parsons in comp.os.linux.development.apps

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, you'll be able to try out the new buffer parameter and
see whether it works.

Victor

At 09:15 03/09/2007, you wrote:
>i don't know about the endianness issue.  although there is that extra
>swapping required, i never noticed it causing dropouts in the past and
>never a perceptible difference between using aiff or wav files.
>
>right now even ONE file can have sharp CPU spikes (presumably
>during a buffer i/o) causing a dropped audio buffer.  and i still have
>a hunch that libsndfile is the culprit.
>
>-m
>
>On Sep 3, 2007, at 3:11 AM, Erik de Castro Lopo wrote:
>
>>matt ingalls wrote:
>>
>>also a separate thread for disk i/o for soundin/diskin would be great.
>>
>>ever since the move to sndfilelib the real-time performance
>>has not been good.  ( in csound4 i was able to make a diskin instrument
>>and play live via MIDI with no clicks -- i can't do that in csound5!!! )
>
>The main thing to be careful about is file endian-ness. Loading AIFF
>files on Intel CPUs or loading WAV files on PowerPC is going to be
>much slower than loading AIFF files on PowerPC or WAV files in Intel
>because of the byte swapping required.
>
>Furthermore, if you want to make your files load quickly, it makes
>sense to store them on dis in the same format you are reading them
>since this will give you the fastest path through libsndfile. Since
>Csound uses floats/doubles internally, it makes sense to store the
>source files as floats/double on disk.
>
>I also notice that the diskin opcode reads in 4096 samples at a time.
>Thats quite a small buffer considering the amount of memory in the
>machines people are likely to be running Csound on. Reading files via
>libsndfile has a per sample read cost and a cost for calling the
>read function. As you increase the read size, you reduce the per sample
>cost of calling the read and approach the per sample read cost.
>
>Finally, memory is *really* cheap these days. Preloading the audio
>data from th file on disk into memory makes a lot of sense when the
>files are small (ie small means less than a couple of meg).
>
>Erik
>--
>-----------------------------------------------------------------
>Erik de Castro Lopo
>-----------------------------------------------------------------
>"Two hands working can do more than a thousand clasped in prayer."
>-- anonymous
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk 
>now >>  http://get.splunk.com/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>< DIV>

matt ingalls
development@gvox.com



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel


Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net