foo-devel — foo development list

Re: [foo-devel] Buff Bugs

[martin r. <fo...@ru...>]

dear ramon,

hmm.  i tried to look into the offset thing, but i can't find an
error:

>>>

(create-soundfile (test-file-name) 'aiff 'short (foo-default-srate) 2)

(define c
  (context 2
	   (output~ 1 (gate~ (sine~ (~ 440)) 1))
	   (output~ 2 (time 1 (gate~ (sine~ (~ 880)) 1)))))

(define t (make-task 0 0.5 (test-file-name) c))

(run-task t 2)

<<<

does exactly what it should do: rendering seconds 0.5 to 2.5 of the
context.  the resulting file then is 0.5 seconds silence, 0.5 seconds
rest of sine wave 440 on ch 1, followed by 1 sec 880 sine on ch2,
followed by 0.5 sec silence.

i suspect that the bug is somewhere else, since the syntax of our
tests is quite different, but i didn't yet find it.  but a
question regarding your examples:

> ;shifting 1 sec. with task Offset
>   (make-soundfile nam1 'aiff 'short 44100. 1)
>   (define c1=20
>     (lambda ()
>       (context 1 (output~ 1 (mul~ (sine~ (~ 440.))=20
> 				  (read-bpf~ (make-bpf '((0 1) (1 0)))))))))
>   (define m1 (make-task 0. 1. nam1 (c1) 'punch 44100. 1024))
>   (run-task m1 2. 1.)

as far as i understand the foo doc, this should result in a3 seconds
of silence?  since it doesn't shift anything, it just renders seconds
1 to 3 of the context, where, due to the bpf, ist silence.  the result
is different, strangely enough.  just wanted to know which result you
are expecting here in order to avoid misunderstandings or so.

bests,

martin

Re: [foo-devel] Re: Buff Bugs

[martin r. <fo...@ru...>]

dear gerhard,

On Fri, Jun 03, 2005 at 02:31:31AM +0200, Gerhard Eckel wrote:
> I just talked to Ramon on the phone and I told him that I had =20
> verified that close is called on the output soundfile. Stupidly =20
> enough I didin't check what happens with the input one. Ramon =20
> confirmed that the problem only arises if reading from a file, so the =20

yes, thanks.  i already wrote a mail back to the list concerning this,
but it was stuck in my outbox for three days... (didn't have internet
access for this time).

bests,

martin

Re: [foo-devel] Re: Buff Bugs

[martin r. <fo...@ru...>]

dear gerhard, dear ramon,

On Thu, Jun 02, 2005 at 03:01:44PM +0200, Gerhard Eckel wrote:
> that problem #1 is much easier to fix for Martin, as he - if I =20
> remember correctly - has already debugged this area and fixed =20
> problems which existed in the past with related issues. Problem #2 =20

let's see.  don't know if i get it now.

> status from my point of view: sf_close is called after the task has =20
> been computed - this is verified by inserting debug messages in the =20
> source. This suggests that the library doesn't treat things the way =20
> it should. Martin, what do you think we can do in this case? I will =20

i think that's a different one.  that's the target sound file.

as far as i understand, ramon refers to (open-snd), and my tests
confirm:

(define (trouble x)
	(if (> x 0)
	    (begin
		(kill-context (context 1 (open-snd "dummy.aiff")))
		(trouble (1- x)))))

(trouble 1024)

and the trouble is there.

even if you do a kill-all-contexts, several (collect), whatever, there
is something with the reference counting issue for the FOOSoundFile
objects, i just didn't yet find out where.  i'll try to find it.

bests,

martin

[foo-devel] Re: Buff Bugs

[Gerhard E. <ec...@ie...>]

Dear Martin,

I just talked to Ramon on the phone and I told him that I had  
verified that close is called on the output soundfile. Stupidly  
enough I didin't check what happens with the input one. Ramon  
confirmed that the problem only arises if reading from a file, so the  
output seems to be fine (if he uses synthesis instead of reading a  
file, the problem doesn't show). This is just to complete the picture  
for you in case you find the time to have a look into it.

Best regards,

Gerhard

Re: [foo-devel] Re: Buff Bugs

[Ramon Gonzalez-A. <ar...@ma...>]

Dear Martin,

I just saw now your message.

> hmm, strange.  i now remember exactly what i tried to do: position the
> context's origin at -5 seconds into the soundfile, and then render
> seconds 5 to 20 or so of the context, in order to render a later part
> of the context, but to have it at the beginning of the soundfile.
> that wasn't working, and maybe i misfixed something at the same time.

Well this is possible. I never tried such thing. Actually I have never 
much used the Reference until now. Say when Reference is 0., offset 
values were doing what was supposed. My life would have been completely 
wrong otherwise.


> yes, because the management memory scheme of openstep is different
> then the old nextstepish foo.

Was the version I was using with my Linux machine not an openstep? It 
was one of the first ports, but I thought it was already openstep.

> the huge memory usage is not inside the scheme heap.

OK Now I understand.

> another "approach" (in other words: dirty hack) would be writing a foo
> script

My planned strategies were closely related to this idea you offer. 
However, I don't think I will try now to get in touch with scripts, so 
I'll do the hard/dirty job myself. Thanks for the suggestion, though.


All the best,

Ramon

Re: [foo-devel] Re: Buff Bugs

[martin r. <fo...@ru...>]

hi ramon,

On Thu, Jun 02, 2005 at 07:30:01PM +0200, Ramon Gonzalez-Arroyo wrote:
> In the "previous" version (this is to be checked with what we mean by=20
> previous), the task offset  was correct. I am sure about that. Also in=20

hmm, strange.  i now remember exactly what i tried to do: position the
context's origin at -5 seconds into the soundfile, and then render
seconds 5 to 20 or so of the context, in order to render a later part
of the context, but to have it at the beginning of the soundfile.
that wasn't working, and maybe i misfixed something at the same time.

> that version there were no problems with the soundfiles. I think=20
> kill-context was doing the job, because I have it as almost last=20
> statement in the SP-run function. An I remember vaguely I had to=20
> include that at some point in life, probably because of the same=20
> reason. Somehow kill-context does not close the file now (?)

yes, because the management memory scheme of openstep is different
then the old nextstepish foo.  in old days, you just called "dealloc",
and the thing was away.  openstep uses a reference counting mechanism,
and i got the feeling that a soundfile is maybe referenced once more
than dereferenced when killing the context, thus it remains.  i'll try
to have a closer look.  but i have to keep aware of the "damokles"
coming wednesday, when i'll have to hand in my thesis.

> I have tried the filehack you sent me Martin, and seems to work under=20
> Linux, although it doesn't really change that much. So now the job ends=
=20
> which is something, but the computer gets completely off. From second=20
> 90 or so (until 120) (that is more or less after 700/800 turns in the=20
> loop) you can see the computer pulling from itself. I put a heap of=20
> 65M, but he curious thing is that this seems not to affect. Collect is=20
> never bigger than a few Kbs with this loopy.

the huge memory usage is not inside the scheme heap. it's the system
reserving file buffers and stuff like that, thus the process' memory
usage goes up and finally causes the machine to swap and finally,
kills it.  that's why the number of open files allowed per process is
limited.  my hack just increases this limit, but obviously can't
compensate for the consequences.

> In the meantime I am running other less sndfied jobs, and thinking=20
> strategies of how to bypass the problem, in case solving it really=20
> demands much more time than you could afford during the next days.

another "approach" (in other words: dirty hack) would be writing a foo
script which does a part of your job according to command line
parameters and then quits, and then calling it repeatedly with the
appropriate parameters from a shell script.  as soon as you quit foo,
all files of the process will be closed automatically.  so a script
which invokes foo repeatedly will everytime start from zero.

there is this example/scripts/sine.foo which is an example for using
the cmdline: parser functions, not much tested, but apparently
working, which could help you with parsing the commandline in a
script.

hopefully this could be workarounf in the meantime,

all the best,

martin

Re: [foo-devel] Re: Buff Bugs

[Ramon Gonzalez-A. <ar...@ma...>]

Dear friends,

Thank you very much for your response. It was nice to see both your 
mails early this morning. I understand perfectly you are both very 
busy, and I really take care of the situation. I really thank you for 
your immediate response!!

I guess, as Gerhard does, that the Offset problem must be an easy one. 
I saw in task.m some comment about offset corrected from previous 
state, but as far as I understood the code looks fine. However, it must 
be there.

In the "previous" version (this is to be checked with what we mean by 
previous), the task offset  was correct. I am sure about that. Also in 
that version there were no problems with the soundfiles. I think 
kill-context was doing the job, because I have it as almost last 
statement in the SP-run function. An I remember vaguely I had to 
include that at some point in life, probably because of the same 
reason. Somehow kill-context does not close the file now (?)

What I mean by previous version is a rather old one, the one I have 
been using until last January/February, which actually was one of the 
first translations of Foo. Maybe the fact that these two problems 
didn't exist at that moment serves to hint what "branch of the tree" 
has to be surveyed.

I have tried the filehack you sent me Martin, and seems to work under 
Linux, although it doesn't really change that much. So now the job ends 
which is something, but the computer gets completely off. From second 
90 or so (until 120) (that is more or less after 700/800 turns in the 
loop) you can see the computer pulling from itself. I put a heap of 
65M, but he curious thing is that this seems not to affect. Collect is 
never bigger than a few Kbs with this loopy.

In the meantime I am running other less sndfied jobs, and thinking 
strategies of how to bypass the problem, in case solving it really 
demands much more time than you could afford during the next days.

All the best,

Ramon

[foo-devel] Re: Buff Bugs

[Gerhard E. <ec...@ie...>]

Dear friends,

I could verify problem #2, on which I concentrated first. I guess  
that problem #1 is much easier to fix for Martin, as he - if I  
remember correctly - has already debugged this area and fixed  
problems which existed in the past with related issues. Problem #2  
status from my point of view: sf_close is called after the task has  
been computed - this is verified by inserting debug messages in the  
source. This suggests that the library doesn't treat things the way  
it should. Martin, what do you think we can do in this case? I will  
continue looking into it but I have more meetings from 16h onwards  
today.

Best regards,

Gerhard

On Jun 1, 2005, at 20:56, Ramon Gonzalez-Arroyo wrote:

> Dear friends,
>
> I know you are all very busy. I have a real problem, because I just  
> discovered now 2 bugs with Foo which are really bad, and after  
> having tested many things and done many things didn't come out  
> until the realwork was there. One of the things I think is easy to  
> find out, and eventually I could bypass the problem. The other is  
> really crude.
>
> 1. Time Offset in task has some error. Time Reference in task  
> works. That's why I think I can bypass the problem.
>
> 2. When opening-snd reading-snd~ the file is not closed once the  
> task is fulfilled. SO after some hundreds/thousands the whole  
> computer explodes and one gets a horrible error. This one is more  
> difficult when trying to massively synthesize, which is what I had  
> to do now.
>
>
> I perfectly understand you are both as water-necked as I am myself.  
> So Ionly ask you to tell me if I have any chance to have the  
> problem solved in the next few fetoseconds!!!!! It is as urgent as  
> that.
>
>
> With all my best wishes,
>
> Ramon
>
> I send you a file with examples to trace the problem ::
>
>
> ;
> ;1. Offset Error
> ;
> (define (OffseterrorEx1 nam)
>   (define nam0 (make-sndname (string-append nam "0")))
>   (define nam1 (make-sndname (string-append nam "1")))
>   (define nam2 (make-sndname (string-append nam "2")))
>   (define nam3 (make-sndname (string-append nam "3")))
>   (define nam4 (make-sndname (string-append nam "4")))
>
> ;shifting 1 sec. with time
>   (synt 1 2 nam0 'aiff 'short 44100.
>     (output~ 1
>          (time 1. (mul~ (sine~ (~ 440.))
>                 (read-bpf~ (make-bpf '((0 1) (1 0))))))))
> ;
> ;shifting 1 sec. with task Offset
>   (make-soundfile nam1 'aiff 'short 44100. 1)
>   (define c1
>     (lambda ()
>       (context 1 (output~ 1 (mul~ (sine~ (~ 440.))
>                   (read-bpf~ (make-bpf '((0 1) (1 0)))))))))
>   (define m1 (make-task 0. 1. nam1 (c1) 'punch 44100. 1024))
>   (run-task m1 2. 1.)
> ;
> ;shifting 1sec. with task Reference
>   (make-soundfile nam2 'aiff 'short 44100. 1)
>   (define c2
>     (lambda ()
>       (context 1 (output~ 1 (mul~ (sine~ (~ 440.))
>                   (read-bpf~ (make-bpf '((0 1) (1 0)))))))))
>   (define m2 (make-task 1. 0. nam2 (c2) 'punch 44100. 1024))
>   (run-task m2 2. 1.)
> ;
> ;shifting 1sec. with time  and 1sec. with task Reference
>   (make-soundfile nam3 'aiff 'short 44100. 1)
>   (define c3
>     (lambda ()
>       (context 1
>            (output~ 1
>             (add~
>              (mul~ (sine~ (~ 440.))
>                    (read-bpf~ (make-bpf '((0 1) (1 0)))))
>              (time 1.
>                    (mul~ (sine~ (~ 440.))
>                      (read-bpf~ (make-bpf '((0 1) (1 0)))))))))))
>   (define m3 (make-task 1. 0. nam3 (c3) 'punch 44100. 1024))
>   (run-task m3 3. 1.)
> ;
> ;  (make-soundfile nam4 'aiff 'short 44100. 1)
> ;  (define c4
> ;    (lambda ()
> ;      (context 1 (output~ 1 (mul~ (sine~ (~ 440.))
> ;                  (read-bpf~ (make-bpf '((0 1) (1 0)))))))))
> ;  (define m4 (make-task 0. 1. nam4 (c4) 'punch 44100. 1024))
> ;  (run-task m4 2. 1.)
>   )
> ;                    ;
> (OffseterrorEx1 "OffErrorEx")
> ;
> ;;Same happens with 'blend mode
> ;
>
> ;
> ;1. Opensnd Error
> ;
> (define (FileerrorEx)
>   (let* ((nam "FileErrorEx")
>      (DUR 120.)
>      (ctx) (tsk) (tim 0.)
>      (aenv '((0 0.) (.3 1 1/3) (0.6 1) (1 0. 1/3)))
>      (clr "~/snd1/AML.snd1/zPartls/caveair.aiff")
>      )
>   (set! nam (make-sndname nam))
>   (make-soundfile nam 'aiff 'short 44100. 1)
>   (set! tim (randint 0.07 0.14))
>   (while (< tim DUR)
>       (prn tim)
>       (set! ctx
>         (lambda ()
>           (context 1 (output~ 1 (mul~ (read-snd~ (open-snd clr))
>                       (~ 0.1)
>                       (read-bpf~ (make-bpf aenv)))))))
>       (set! tsk
>       (make-task tim 0. nam (ctx) 'blend 44100. 1024))
>       (run-task tsk 1. 1.)
>       (set! tim (+ tim (randint 0.07 0.14)))
>       )))
> ;
> (FileerrorEx)
> ;
> ;libsndfile: System error : Too many open files.
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 148
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 198
> ;107.3742555737842110374913318083
> ;libsndfile: System error : Too many open files.
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 148
> ;foo:open-snd: unknown sound file format: 0
> ;Inspector (type ? for help)
> ;
>

Univ.Prof. Dr. Gerhard Eckel
Institute of Electronic Music and Acoustics
Inffeldgasse 10/3
A-8010 Graz
Tel: +43 316 389 3726
FAX: +43 316 389 3171

[foo-devel] Re: Buff Bugs

[Gerhard E. <ec...@ie...>]

Dear Ramon,

I only read your message now. I will dive into the source directly to  
see what I can see and hopefully do. I have a Seminar from 10h-13h,  
so I won't get very far now. And also: I am afraid I could not be  
able to solve the problems alone. Martin, please help!

Best regards,

Gerhard

On Jun 1, 2005, at 20:56, Ramon Gonzalez-Arroyo wrote:

> Dear friends,
>
> I know you are all very busy. I have a real problem, because I just  
> discovered now 2 bugs with Foo which are really bad, and after  
> having tested many things and done many things didn't come out  
> until the realwork was there. One of the things I think is easy to  
> find out, and eventually I could bypass the problem. The other is  
> really crude.
>
> 1. Time Offset in task has some error. Time Reference in task  
> works. That's why I think I can bypass the problem.
>
> 2. When opening-snd reading-snd~ the file is not closed once the  
> task is fulfilled. SO after some hundreds/thousands the whole  
> computer explodes and one gets a horrible error. This one is more  
> difficult when trying to massively synthesize, which is what I had  
> to do now.
>
>
> I perfectly understand you are both as water-necked as I am myself.  
> So Ionly ask you to tell me if I have any chance to have the  
> problem solved in the next few fetoseconds!!!!! It is as urgent as  
> that.
>
>
> With all my best wishes,
>
> Ramon
>
> I send you a file with examples to trace the problem ::
>
>
> ;
> ;1. Offset Error
> ;
> (define (OffseterrorEx1 nam)
>   (define nam0 (make-sndname (string-append nam "0")))
>   (define nam1 (make-sndname (string-append nam "1")))
>   (define nam2 (make-sndname (string-append nam "2")))
>   (define nam3 (make-sndname (string-append nam "3")))
>   (define nam4 (make-sndname (string-append nam "4")))
>
> ;shifting 1 sec. with time
>   (synt 1 2 nam0 'aiff 'short 44100.
>     (output~ 1
>          (time 1. (mul~ (sine~ (~ 440.))
>                 (read-bpf~ (make-bpf '((0 1) (1 0))))))))
> ;
> ;shifting 1 sec. with task Offset
>   (make-soundfile nam1 'aiff 'short 44100. 1)
>   (define c1
>     (lambda ()
>       (context 1 (output~ 1 (mul~ (sine~ (~ 440.))
>                   (read-bpf~ (make-bpf '((0 1) (1 0)))))))))
>   (define m1 (make-task 0. 1. nam1 (c1) 'punch 44100. 1024))
>   (run-task m1 2. 1.)
> ;
> ;shifting 1sec. with task Reference
>   (make-soundfile nam2 'aiff 'short 44100. 1)
>   (define c2
>     (lambda ()
>       (context 1 (output~ 1 (mul~ (sine~ (~ 440.))
>                   (read-bpf~ (make-bpf '((0 1) (1 0)))))))))
>   (define m2 (make-task 1. 0. nam2 (c2) 'punch 44100. 1024))
>   (run-task m2 2. 1.)
> ;
> ;shifting 1sec. with time  and 1sec. with task Reference
>   (make-soundfile nam3 'aiff 'short 44100. 1)
>   (define c3
>     (lambda ()
>       (context 1
>            (output~ 1
>             (add~
>              (mul~ (sine~ (~ 440.))
>                    (read-bpf~ (make-bpf '((0 1) (1 0)))))
>              (time 1.
>                    (mul~ (sine~ (~ 440.))
>                      (read-bpf~ (make-bpf '((0 1) (1 0)))))))))))
>   (define m3 (make-task 1. 0. nam3 (c3) 'punch 44100. 1024))
>   (run-task m3 3. 1.)
> ;
> ;  (make-soundfile nam4 'aiff 'short 44100. 1)
> ;  (define c4
> ;    (lambda ()
> ;      (context 1 (output~ 1 (mul~ (sine~ (~ 440.))
> ;                  (read-bpf~ (make-bpf '((0 1) (1 0)))))))))
> ;  (define m4 (make-task 0. 1. nam4 (c4) 'punch 44100. 1024))
> ;  (run-task m4 2. 1.)
>   )
> ;                    ;
> (OffseterrorEx1 "OffErrorEx")
> ;
> ;;Same happens with 'blend mode
> ;
>
> ;
> ;1. Opensnd Error
> ;
> (define (FileerrorEx)
>   (let* ((nam "FileErrorEx")
>      (DUR 120.)
>      (ctx) (tsk) (tim 0.)
>      (aenv '((0 0.) (.3 1 1/3) (0.6 1) (1 0. 1/3)))
>      (clr "~/snd1/AML.snd1/zPartls/caveair.aiff")
>      )
>   (set! nam (make-sndname nam))
>   (make-soundfile nam 'aiff 'short 44100. 1)
>   (set! tim (randint 0.07 0.14))
>   (while (< tim DUR)
>       (prn tim)
>       (set! ctx
>         (lambda ()
>           (context 1 (output~ 1 (mul~ (read-snd~ (open-snd clr))
>                       (~ 0.1)
>                       (read-bpf~ (make-bpf aenv)))))))
>       (set! tsk
>       (make-task tim 0. nam (ctx) 'blend 44100. 1024))
>       (run-task tsk 1. 1.)
>       (set! tim (+ tim (randint 0.07 0.14)))
>       )))
> ;
> (FileerrorEx)
> ;
> ;libsndfile: System error : Too many open files.
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 148
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 367
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 198
> ;107.3742555737842110374913318083
> ;libsndfile: System error : Too many open files.
> ;FOO ERROR: class: FOOSoundFile, file: FOOSoundFile.m, line: 148
> ;foo:open-snd: unknown sound file format: 0
> ;Inspector (type ? for help)
> ;
>

Univ.Prof. Dr. Gerhard Eckel
Institute of Electronic Music and Acoustics
Inffeldgasse 10/3
A-8010 Graz
Tel: +43 316 389 3726
FAX: +43 316 389 3171

Re: [foo-devel] Buff Bugs

[martin r. <fo...@ru...>]

dear ramon,

thanks for your bug reports.

On Wed, Jun 01, 2005 at 08:56:12PM +0200, Ramon Gonzalez-Arroyo wrote:
> 1. Time Offset in task has some error. Time Reference in task works. 
> That's why I think I can bypass the problem.

hmm.  i bumped into that problem some time ago, and i thought i fixed
it.  apparently that's not true...  i got the impression that is was
present in the old foo as well, but i am not sure.

> 2. When opening-snd reading-snd~ the file is not closed once the task is 
> fulfilled. SO after some hundreds/thousands the whole computer explodes 
> and one gets a horrible error. This one is more difficult when trying to 
> massively synthesize, which is what I had to do now.

yes, i thought about that as well when thinking about all the sound
synthesis stuff in conjunction with my thesis.  the only real solution
would be a kind of lazy-evaluation-semantics for opening soundfiles
just during task execution time.  at the moment, it's opened when
executing (open-snd).  one workaround would be to call (kill-context)
or (kill-all-contexts) and maybe (collect) in between, but it simply
does not work.  i am afraid there is a memory management bug somewhere
which prevents the objc-soundfile object being dealloc'd (which would
close the corresponding file).

i had a look but couldn't find it at the moment.  sorry.

i put together a quick and very dirty hack, which allows for
increasing the number of files a process is allowed to open.  find the
source attached.

gcc -o filehack filehack.c

should compile it.  then you could do:

./filehack 16384 foo

which allows foo to have 16384 files open instead of the default of
1024.  this is, of course, quite memory consuming, but hopefully it'll
help you for the moment.  depending on your system configuration you
might have to run this as root, but on my machine it works as an
ordinary user.  and i don't have any idea whether this works with mac
os x, but at least on my linux machine it does.

i won't have the chance to hunt the actual bug until the beginning of
the week after next week, but hopefully this dirty thing works for you
for this time...

all the best,

martin

[foo-devel] Buff Bugs

[Ramon Gonzalez-A. <ar...@ma...>]

Dear friends,

I know you are all very busy. I have a real problem, because I just 
discovered now 2 bugs with Foo which are really bad, and after having 
tested many things and done many things didn't come out until the 
realwork was there. One of the things I think is easy to find out, and 
eventually I could bypass the problem. The other is really crude.

1. Time Offset in task has some error. Time Reference in task works. 
That's why I think I can bypass the problem.

2. When opening-snd reading-snd~ the file is not closed once the task is 
fulfilled. SO after some hundreds/thousands the whole computer explodes 
and one gets a horrible error. This one is more difficult when trying to 
massively synthesize, which is what I had to do now.


I perfectly understand you are both as water-necked as I am myself. So 
Ionly ask you to tell me if I have any chance to have the problem solved 
in the next few fetoseconds!!!!! It is as urgent as that.


With all my best wishes,

Ramon

I send you a file with examples to trace the problem ::

Re: [foo-devel] upper/lowercase, WAS: foo oops et al.

[martin r. <fo...@ru...>]

> On Sun, Aug 15, 2004 at 08:52:57PM +0200, Ramon Gonzalez-Arroyo wrote:
> > Please tell me why is so important the lowercase conversion. Unix has=
=20
> > always been case sensitive. The Mac wasn't before it became a real=20
> > machine, but now it is,

it is not, i had to find out today.  restarting an old discussion...

even on mac os x, the default HFS+ file system is case preserving, but
not case sensitive:

$ touch Test
$ rm test

guess what happens?

there is an option for formatting a volume with HFSX, which means case
sensitive.  it means a complete reinstall (or restore from backup) for
the startup drive.  at least photoshop cs is known to have problems
with a case sensitive (HFSX) file system.

another option would be UFS (unix file system), which is case
sensitive and supported by mac os x as well.

shame on apple et al.

bests,

martin

Re: [foo-devel] last 0.0. series release

[Ramon Gonzalez-A. <ar...@ma...>]

Dear Martin,

Sorry for the delay in answering you. I was away and without 
connection. Just give me a week to settle myself.

You are absolutely right, we have to come out with the new release.

I hope you are fine,

Ramon

Re: [foo-devel] last 0.0. series release

[Gerhard E. <ger...@im...>]

dear martin,

> after having the 0.1.0 release, we are maybe able to figure out how to
> build those .dmg install archives for macintosh, which could be quite
> handy.  there is at least one composer from new york who i met at anet
> summit in banff and who is interested in foo, but i really can't bring
> myself to propose to her the usual readline/elk/sndfile/configure
> torture...

... great to hear that you are thinking about a .dmg install archive 
for OSX - this would make life of people who want to use foo so much 
easier!

Best regards,

Gerhard

[foo-devel] last 0.0. series release

[martin r. <fo...@ru...>]

dear fooers,

i just made the foo-0.0.7 release, which is not a "real" release, thus
not announced officially.  its purpose is to get the latest changes to
our old CVS repository inside a release tarball in order to not
"loose" any history.  from my part, the listen/foo/ subdirectory is
closed now and should not undergo any changes related to the foo main
tree.

i'd like to see another "real" release of all the work done in krems,
madrid and banff quite soon.

ramon, do you think it will be possible for you to check in your
updated scheme/control lib tree soon?

next thing would be solving the remaining soundfile accessing things.
i have to reread the latest mails written to and received from erik,
maybe i have to insist on another answer from him in order to decide
whether i'd propose to leave out the comment support.  it really looks
too messy.

after having the 0.1.0 release, we are maybe able to figure out how to
build those .dmg install archives for macintosh, which could be quite
handy.  there is at least one composer from new york who i met at anet
summit in banff and who is interested in foo, but i really can't bring
myself to propose to her the usual readline/elk/sndfile/configure
torture...  on the other hand i am not yet decided which of the
prompts is more intuitive, the foo> or the bash$...

bests,

martin

[foo-devel] Re: [linux-audio-dev] libsndfile: type combinations and string data

[Erik de C. L. <eri...@me...>]

On Mon, 30 Aug 2004 22:30:41 -0600
martin rumori <li...@ru...> wrote:

> but, with 1.0.10 and 1.0.11pre4,
> 
>   SF_INFO info;
> 
>   info.format = SF_FORMAT_AIFF | SF_FORMAT_PCM_16 | SF_ENDIAN_LITTLE;
>   if (! sf_format_check(&info))
>     {
>       printf("AIFF | LITTLE invalid\n");
>     }
> 
>   info.format = SF_FORMAT_AIFF | SF_FORMAT_PCM_16 | SF_ENDIAN_BIG;
>   if (! sf_format_check(&info))
>     {
>       printf("AIFF | BIG invalid\n");
>     }
> 
> yields me both an error.  is that supposed to return true?

For sf_format_check() to return TRUE, you MUST also set the sample
rate, channel count and number of channels.

<snip>

> i don't know too much about the data organisation in .aiff and .wav,
> but if the comment is located in the head of the file, it could still
> be possible to write/change the data section in SFM_RDWR. 

Yes, and that should be possible. What is not possible is
openning the file RDWR and modifying the string data in the 
header.

> what do you
> think about letting sf_set_string() fail in any other mode than
> SFM_WRITE, 

Yes, thats sound pretty sensible.

> but still allowing to open files with comments in SF_RDWR
> and to use the sf_writex_*() calls?  (currently possible with AIFF,
> but not with WAV).

Are you sure?

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"Linux is produced to be used, whereas the others are produced
to be sold"  -- Bobby D. Bryant

[foo-devel] Re: [linux-audio-dev] libsndfile: type combinations and string data

[martin r. <li...@ru...>]

On Tue, Aug 31, 2004 at 09:33:44PM +1000, Erik de Castro Lopo wrote:
> > yields me both an error.  is that supposed to return true?
> 
> For sf_format_check() to return TRUE, you MUST also set the sample
> rate, channel count and number of channels.

i see. thank you.  missed that in the test case...  o.k., now

SF_FORMAT_AIFF | SF_FORMAT_FLOAT | SF_ENDIAN_BIG succeeds, as well as
SF_FORMAT_WAV | SF_FORMAT_FLOAT | SF_ENDIAN_LITTLE, so the endian-ness
switches are like requests which could be fulfilled or not.

i am still wondering whether it wouldn't be useful to let
| SF_ENDIAN_CPU fail in the case it "resolves" to an invalid combination
but let it succeed in the other case.

in our foo sound synthesis language (scheme scripted), the user is
allowed to do:

(create-soundfile "test.aiff" 'aiff 'auto 48000 2)

where 'auto is an alternative way of specifying the sample format
(instead of 'short or 'float), and means: foo's native processing
sample type (currently float) in host byte order, SF_FORMAT_FLOAT |
SF_ENDIAN_CPU.  the user might expect that the above call works on
macintosh. while the call with 'wav should work on pc (and 'snd or 'au
should work everywhere, which is the case).

in order to allow 'aiff and 'wav in combination with 'auto, i could
check manually for the host byteorder and the formats before calling
libsndfile, but that feels like doubling efforts since those checks
are already done in libsndfile, except of the different return
behavior with SF_ENDIAN_CPU.

> Yes, and that should be possible. What is not possible is
> openning the file RDWR and modifying the string data in the 
> header.

agreed.

> > but still allowing to open files with comments in SF_RDWR
> > and to use the sf_writex_*() calls?  (currently possible with AIFF,
> > but not with WAV).
> 
> Are you sure?

quite sure.  the attached example yields:

libsndfile(open): Error : Cannot open file in read/write mode due to string data in header.

but maybe i am missing something again...

thanks a lot,

martin

Re: [foo-devel] soundfile extensions, WAS: foo oops et al.

[martin r. <fo...@ru...>]

dear ramon,

On Mon, Aug 30, 2004 at 08:52:19PM +0200, Ramon Gonzalez-Arroyo wrote:
> >what should we do with default-soundfile-type?
> 
> We must have a variable to be seen/altered by the functions. My doubts 
> are:
> 
> How should it be called?
> and Where (in which file) should it be defined?

hm.  i was using default-soundfile-filetype in order to distinguish it
from "sample format", which sometimes was referred to as "type", too
(e. g. in the old foo:synthesize).  in general "type" and "format" are
maybe enough for distinguishing this.

[... staring at elkfoo.scm  "defaults section" ...]

hmm, the scheme for other values is like

(define foo-default-taps foo:default-taps)
(define set-foo-default-taps! foo:set-default-taps!)

here we have a kernel interface for setting the defaults, which makes
sense, since the kernel uses it.

i thought about different schemes of having a kernel interface like
this for soundfile-defaults as well.  but for what reason?  if the
kernel should query it, it has to know something about the extensions
as well, and for my taste it's maybe too much magic for the low level
kernel interface.   and storing the values in the kernel just in order
to retrieve them again for use in scheme is a bit dirty.

the idea attracted me at first sight because we could solve the
'incremental problem as well:

(define foo-incremental-sf-type foo:incremental-sf-type)
(define set-foo-incremental-sf-type! foo:set-incremental-sf-type!)

and in this case the kernel could really use that information.  it's a
bit dirty, anyway.  the only reason for doing so is that we need the
'type' field of (create-soundfile) for the 'incremental information,
and that's why we are looking for a place where to specify the actual
type information (which has a meaningful default).

the problem is that 'incremental (or 'imx in your new database) is
neither a type nor a format, it's more like an additional boolean
qualifier.  since we are trying to integrate it seamlessly with the
other soundfile parameters (in former times it was posed as a format,
now as a type, which is both not fully correct), we've got that messy
problem.

my proposal:

1.
(define foo-default-soundfile-type foo:default-soundfile-type)
(define set-foo-default-soundfile-type! foo:set-default-soundfile-type!)

in order to reflect the same thing as with the taps, but with the
difference that the foo:xxx functions are in scheme, not in the
kernel.

2.
the global variable for storing the type should call...  no idea.
foo:default-soundfile-type-var ?  (uuh)

3.
for the incremental stuff, we should find a way to specify
'incremental independent from 'aiff and friends, otherwise we'll never
get happy...

we could introduce a doublette of every type with the prefix imx-,
like 'imx-aiff etc., but ugly...

or we emphasize on the special nature of mix files and have a kernel
function

(foo:make-mixfile) and scheme things like

(create-mixfile "test.imx" 'aiff 'float 48000 2) and
(make-mixfile idem)

which looks like the cleanest solution to me.  i guess this will clean
up the related kernel code as well.


> 
> -> Concerning $SFDIR, foo:SFDIR {foo:soundfile-dir}, test-file-dir
> 
> 1.
> The variable foo:SFDIR is ok for me to call it foo:sndfile-dir or 
> foo:snd-file-dir. But do you want also to change the names of the 
> functions get-SFDIR and set-SFDIR ? I would anyway keep the names of 
> the functions for backward compatibility.
> 
> (define (foo:get-sndfile-dir) foo:snd-flle-dir)
> (define (foo:set-sndfile-dir! paz) ...etc....
> 
> (define get-SFDIR foo:get-sndfile-dir)
> (define set-SFDIR foo:set-sndfile-dir! )
> 
> That looks ok for you?

almost.  i am just wondering whether we shouldn't keep the full
(foo:get-soundfile-dir) in order to keep the difference between 'snd'
(a foo substrate) and 'soundfile' (the dirty thing below it), as it is
done already in the kernel (soundfile-channels/snd-channels etc.).

of course we should keep the backwards compat stuff.  there is already
a file next-compat.foo, which is exactly for that purpose.  since the
old (syn ) and (synt )-stuff may not be necessary anymore, feel free
to delete what you don't need.


> 2.
> I think foo:test-file-dir and foo:SFDIR have different purposes. The 
> first is the directory where to syn sync and test, everything will be 

i see, agreed.  i am just wondering whether we should initialize both
the dirs to the same value.  maybe we should stick with the /tmp/USER
thing for test-file-dir?


> 3.
> The convention ^ for $SFDIR goes beyond the Foo universe.  <= That's 
> the main drawback. If someone has declared $SFDIR in his environment ^ 
> should stand for it, independently that he uses or not foo:SFDIR for 
> other purposes. But if someone has not an SFDIR variable declared in 
> his environment then he might profit from the symbol to represent his 
> current SFDIR. This is the idea behind when writing the function 
> hat-expand. To have different possibilities for creating levels of 
> organization is not a drawback, unless it becomes too heavy to use. 
> (This is what I think).

ahh, i see.  what's your mode of working?  do you have such a static
SFDIR pointed to by an environment var?

intuitively, i guessed that one might have "project" soundfile dirs
depending on the current project, which is foo:SFDIR.  having a
shortcut for them (^) is a great thing for specifying files
relatively.

but let's say i have an environment SFDIR for my everyday-foo-tasks
(resampling, converting, mixing or so), then i'd have to leave foo and
unset the env variable in order to start with project stuff and to get
^ bound to the project sndfile-dir.  this looks a bit ugly to me.

in order to solve that we'd need another shortcut for the dynamic
thing...  '^' looks really static, maybe '%' looks "soft"...  if that
doesn't mess up everything even more.  but having a clean distinction
between a "static" SFDIR and a "dynamic" project foo:soundfile-dir
looks cool to me.

i am curious to read more about your mode of working with files and
organizing them and your ideas regarding shortcuts like '^'.

bests,

martin

[foo-devel] Re: [linux-audio-dev] libsndfile: type combinations and string data

[martin r. <li...@ru...>]

On Tue, Aug 31, 2004 at 07:54:58AM +1000, Erik de Castro Lopo wrote:
> SF_ENDIAN_CPU really only makes sense when the file format allows
> bot endian-nesses.

ahh, i see, the SF_ENDIAN_* format parameters are meant to FORCE to a
specific endian-ness, and with formats supporting just one endian-ness
forcing does not make sense at all.

i was thinking of it like REQUESTING a specific endian-ness,
which would yield an error in
SF_FORMAT_AIFF | SF_FORMAT_FLOAT | SF_ENDIAN_LITTLE
but would proceed in 
SF_FORMAT_AIFF | SF_FORMAT_FLOAT | SF_ENDIAN_BIG.
i understood SF_ENDIAN_CPU like "resolving" to one of SF_ENDIAN_LITTLE
or _BIG depending on the current platform, that's why my question...

> AIFF amd WAV only allows one endian-ness for float data, while AU
> allows both. AIFF is a little strange in that it does allow both
> endian-nesses for PCM ints.

but, with 1.0.10 and 1.0.11pre4,

  SF_INFO info;

  info.format = SF_FORMAT_AIFF | SF_FORMAT_PCM_16 | SF_ENDIAN_LITTLE;
  if (! sf_format_check(&info))
    {
      printf("AIFF | LITTLE invalid\n");
    }

  info.format = SF_FORMAT_AIFF | SF_FORMAT_PCM_16 | SF_ENDIAN_BIG;
  if (! sf_format_check(&info))
    {
      printf("AIFF | BIG invalid\n");
    }

yields me both an error.  is that supposed to return true?

> > snd does not explicitly allow using string data in the file format.
> > however, i remember that it was done in the old NeXT days by
> > increasing the data offset and using the space in between for a
> > comment.  do you think this could be implemented in libsndfile for the
> > SF_STR_COMMENT thing or is that just too non-standard?
> 
> Do you mean for the AU file format?

yes, sorry.

> > with SF_FORMAT_AIFF, i can't write string data to the file in SFM_RDWR
> > mode.  
> 
> There are good reasons for this. Say you already have a comment in
> the head which is 10 bytes long. You now open the file in RDWR mode
> and change that comment header to be 16 bytes long. Fixing that is
> completely non-trivial.

i see.  maybe you'd had to move the data back in order to create space
for the comment.  not worth the work, agreed.

> > the call to sf_set_string() succeeds, but the actual data in
> > the file is not changed.  the call to sf_set_string() succeeds even
> > when the file is in SFM_READ mode.
> 
> Thats probably a bug.
> 
> > with SF_FORMAT_WAV, a file with string data can't be opened with
> > SFM_RDWR anymore.  this means there is no way to change the audio data

> As above.

i don't know too much about the data organisation in .aiff and .wav,
but if the comment is located in the head of the file, it could still
be possible to write/change the data section in SFM_RDWR.  what do you
think about letting sf_set_string() fail in any other mode than
SFM_WRITE, but still allowing to open files with comments in SF_RDWR
and to use the sf_writex_*() calls?  (currently possible with AIFF,
but not with WAV).

bests,

martin

[foo-devel] Re: [linux-audio-dev] libsndfile: type combinations and string data

[Erik de C. L. <eri...@me...>]

On Mon, 30 Aug 2004 21:58:32 +0200
martin rumori <li...@ru...> wrote:

> hi erik,
> 
> i've got a question regarding type combinations in libsndfile:
> 
> SF_FORMAT_FLOAT | SF_ENDIAN_CPU works with SF_FORMAT_AU on any
> platform, which is great.  but it doesn't work with neither aiff nor
> wav. 

AIFF amd WAV only allows one endian-ness for float data, while AU
allows both. AIFF is a little strange in that it does allow both
endian-nesses for PCM ints.

> i expected that it would work with one of the both formats,
> depending on the host endianess.

SF_ENDIAN_CPU really only makes sense when the file format allows
bot endian-nesses.

> some other questions regarding string data:
> 
> snd does not explicitly allow using string data in the file format.
> however, i remember that it was done in the old NeXT days by
> increasing the data offset and using the space in between for a
> comment.  do you think this could be implemented in libsndfile for the
> SF_STR_COMMENT thing or is that just too non-standard?

Do you mean for the AU file format?

> with SF_FORMAT_AIFF, i can't write string data to the file in SFM_RDWR
> mode.  

There are good reasons for this. Say you already have a comment in
the head which is 10 bytes long. You now open the file in RDWR mode
and change that comment header to be 16 bytes long. Fixing that is
completely non-trivial.

> the call to sf_set_string() succeeds, but the actual data in
> the file is not changed.  the call to sf_set_string() succeeds even
> when the file is in SFM_READ mode.

Thats probably a bug.

> with SF_FORMAT_WAV, a file with string data can't be opened with
> SFM_RDWR anymore.  this means there is no way to change the audio data
> or the comment of the file without copying it?  i guess there is a
> special reason for that...

As above.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"What lawyers call 'intellectual property' is -- as every Latin student
knows -- no more than theft from the public domain."
  -- Andy Mueller-Maguhn, newly elected ICANN board member for Europe.

Re: [foo-devel] sinc interpolation questions

[martin r. <fo...@ru...>]

On Mon, Aug 30, 2004 at 08:52:13PM +0200, Ramon Gonzalez-Arroyo wrote:
> >there is a "perfect" window though to which the kaiser window itself
> >is just an approximation: the "prolate spheroidal window",
> 
> > takes
> >much longer to compute than foo...  guess we'll never reach that level
> >with foo, regardless of the window we are using...

> Why not? Always the best, as a possibility, even if we have a cheaper 
> one for practical reasons. That was the philisophy of Foo. Wans't it?

of course.  i just referred to the fact that erik de castro lopo uses
a 64-bit-fixed-point representation for sample values in his
implementation, because the IEEE double type (~ 48 bit resulting) is
not precise enough.  unless we are not doing the same, i suspect that
just using the prolate instead of the kaiser window and increasing the
tap size is not enough for reaching the 97 dB/ 97 % bandwidth thing.

instead of doing that we should build an (optional) interface to
libsamplerate in addition to our implementation (maybe low priority).

bests,

martin

[foo-devel] libsndfile: type combinations and string data

[martin r. <li...@ru...>]

hi erik,

i've got a question regarding type combinations in libsndfile:

SF_FORMAT_FLOAT | SF_ENDIAN_CPU works with SF_FORMAT_AU on any
platform, which is great.  but it doesn't work with neither aiff nor
wav.  i expected that it would work with one of the both formats,
depending on the host endianess.

is there a special reason why it does not?


some other questions regarding string data:

snd does not explicitly allow using string data in the file format.
however, i remember that it was done in the old NeXT days by
increasing the data offset and using the space in between for a
comment.  do you think this could be implemented in libsndfile for the
SF_STR_COMMENT thing or is that just too non-standard?

with SF_FORMAT_AIFF, i can't write string data to the file in SFM_RDWR
mode.  the call to sf_set_string() succeeds, but the actual data in
the file is not changed.  the call to sf_set_string() succeeds even
when the file is in SFM_READ mode.

with SF_FORMAT_WAV, a file with string data can't be opened with
SFM_RDWR anymore.  this means there is no way to change the audio data
or the comment of the file without copying it?  i guess there is a
special reason for that...

thanks very much for your patience...

bests,

martin

Re: [foo-devel] soundfile extensions, WAS: foo oops et al.

[Ramon Gonzalez-A. <ar...@ma...>]

Dear Martin,

> cool.  looks good.

Great

> what should we do with default-soundfile-type?

We must have a variable to be seen/altered by the functions. My doubts 
are:

How should it be called?
and Where (in which file) should it be defined?

-> Concerning $SFDIR, foo:SFDIR {foo:soundfile-dir}, test-file-dir

1.
The variable foo:SFDIR is ok for me to call it foo:sndfile-dir or 
foo:snd-file-dir. But do you want also to change the names of the 
functions get-SFDIR and set-SFDIR ? I would anyway keep the names of 
the functions for backward compatibility.

(define (foo:get-sndfile-dir) foo:snd-flle-dir)
(define (foo:set-sndfile-dir! paz) ...etc....

(define get-SFDIR foo:get-sndfile-dir)
(define set-SFDIR foo:set-sndfile-dir! )

That looks ok for you?

2.
I think foo:test-file-dir and foo:SFDIR have different purposes. The 
first is the directory where to syn sync and test, everything will be 
removed and you don't care. Actually I was by default setting foo:SFDIR 
to foo:test-file-dir because SP-run takes make-sndname (and thus 
foo:SFDIR), but if you are just testing and the like (if you do not 
change things manually), test-file names and directories are set to the 
foo:test convention for that purpose. In this way you know everything 
is removed on logout, deleting a file doesn't query for permission 
(which otherwise it does) and (play) (save) (edit) work without other 
arguments. On the other hand foo:SFDIR is a working tool, to establish 
where you synthesize, and where your soundfiles are organized. If you 
want to overwrite a soundfile which is not foo:test-file-name it asks 
permission.


3.
The convention ^ for $SFDIR goes beyond the Foo universe.  <= That's 
the main drawback. If someone has declared $SFDIR in his environment ^ 
should stand for it, independently that he uses or not foo:SFDIR for 
other purposes. But if someone has not an SFDIR variable declared in 
his environment then he might profit from the symbol to represent his 
current SFDIR. This is the idea behind when writing the function 
hat-expand. To have different possibilities for creating levels of 
organization is not a drawback, unless it becomes too heavy to use. 
(This is what I think).


Conclusion.
  I agree therefore with you, in that foo:SFDIR should be called 
otherwise to avoid mixing it up with $SFDIR. This one is static, the 
other dynamic. However I think they may serve different purposes, when 
working. Same applies to mixing up the test-dir and the foo:SFDIR.

But  I'm happy to keep on arguing, if you do not agree with my points 
of view.

Yours,

Ramon

Re: [foo-devel] sinc interpolation questions

[Ramon Gonzalez-A. <ar...@ma...>]

> there is a "perfect" window though to which the kaiser window itself
> is just an approximation: the "prolate spheroidal window",


>  takes
> much longer to compute than foo...  guess we'll never reach that level
> with foo, regardless of the window we are using...
>

Why not? Always the best, as a possibility, even if we have a cheaper 
one for practical reasons. That was the philisophy of Foo. Wans't it?

[foo-devel] new (foo:make-soundfile) interface

[martin r. <fo...@ru...>]

hi all,

i recently checked in the slightly changed implementation of
(foo:make-soundfile).  this means for (create-soundfile):

(create-soundfile "name.aiff" 'aiff 'float srate channels . comment)

'incremental is a type now (to be specified instead of 'aiff).  the
function for changing the default (snd/au inside .imx dir) is not yet
implemented.

there is another sample format now, 'auto (instead of 'float).  it
means: native foo processing sample type (currently float) with native
byte order (platform dependent).  surprisingly, this works only with
'snd type (neither 'aiff nor 'wav), "invalid parameter combination"
otherwise.  i'll ask the author of libsndfile for the reason.  i'd
expect that it should work with 'wav (little endian) on my (pc)
platform, while on mac it should work with 'aiff (big endian).
'snd is the most flexible format here.

unfortunetaly, setting a comment to a 'snd file yields an error from
the underlying sf_set_string() function.  i'll ask erik, may be there
isn't an official specification for the comment string in 'snd files.

already implemented, but not yet working is (set-soundfile-comment!).
until now, the soundfile has to be in pure write-mode in order to set
the comment.  i'll ask for a fix to libsndfile which should allow
writing the comment in r/w mode as well.

bests,

martin