foo-devel — foo development list

[foo-devel] (foo:string-index) changes

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

hi,

from the cvs log message for latest elkfoo.scm changes:

- changed (foo:string-(r)index) in order to return -1 if char not
  found instead of #f, cause this led to an error in synt when using
  local path without '/'.  however, (foo:dirname) returns strings with
  trailing '/' now, but (foo:dirname "test.aiff") now returns ""
  correctly instead of yielding an error

former (foo:string-rindex) behavior:

(foo:dirname "/tmp/rumori/testfile.aiff")
"/tmp/rumori"

(foo:dirname "/testfile.aiff")
""

(foo:dirname "testfile.aiff")
substring: wrong argument type boolean (expected integer)

(because of (substring "xxx" 0 #f))


new (foo:string-rindex) behavior:

(foo:dirname "/tmp/rumori/testfile.aiff")
"/tmp/rumori/"

(foo:dirname "/testfile.aiff")
"/"

(foo:dirname "testfile.aiff")
""

as shown, the new behavior corrects one wrong return value and avoids
an error.  the trailing slash works with (file-exists?) as well as
with (system "mkdir -p"), which is used in (foo:synthesize).  the new
behavior avoids the abovementioned error, especially when using (synt)
with filenames without a directory part.

however, it changes the "solution set" of (foo:string-rindex) and
(foo:string-index), that's why i wanted to ask whether i am missing
something which gets broken by this new behavior.

bests,

martin

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

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

dear ramon,

On Mon, Aug 30, 2004 at 05:27:12PM +0200, Ramon Gonzalez-Arroyo wrote:
> I have done the new soundfile-funs-foo. Type, extensions and all that 

cool.  looks good.

> I don't know how to remove a directorybranch (tools in scm), but this 
> should be removed.

don't now either.  i suspect the only possible way is to it manually,
like with checking in (except of import).  did it.

> It takes first the environment SFDIR, and if it is not defined it takes 
> foo:SFDIR. I don't know if this is a wonderful idea. My assumption: ^ 

i think you could omit this test and use just foo:SFDIR for
(hat-expand).  at init time, foo:SFDIR is set to (foo:test-file-dir),
which itself is set to (getenv "SFDIR"), or /tmp/USER/ if SFDIR is not
set.  it is not desirable, that the user changes the environment var
SFDIR during runtime of foo, he should use (set-SFDIR) for that.  when
checking for SFDIR in (hat-expand), (set-SFDIR) wouldn't have any
effect to (hat-expand), since env var SFDIR keeps the old content.

btw., shouldn't we change foo:SFDIR to (foo:sound-file-dir) (like in
foo:test-file-dir)?

and: i am wondering about the benefit having from to separated
soundfile-dirs (test-file-dir and sound-file-dir).  they get
initialized to the same value (SFDIR or /tmp/USER) anyway, and are
different only when changing sound-file-dir manually.  i am wondering
whether it's desirable to change the location of the test-files with
(set-SFDIR) as well.  the only drawback is that we have to keep track
of created temp files with another mechanism than now in order to
remove them properly even if the directory changed.  shouldn't be hard
to keep a list of created tempfiles which are removed on
(foo:cleanup).  i think that's a clean design, since other functions
could use it for creating and registering tempfiles as well.

> ^ is a "standard" for the environment SFDIR. If one has this variable 
> defined, one expects it to be interpreted so. Otherwise if someone 

we could say: '^' expands to the current (foo:sound-file-dir), which
gets initialized to SFDIR.  this way '^' is a "dynamic" shorthand,
while '~' is a static one.  if you have SFDIR defined, it works as
expected, as long as you don't change (foo:sound-file-dir) manually.

> (define (foo:default-soundfile-type) foo-default-soundfile-filetype)
> 
> this should probably look different. I am using your definition in 
> elkfoo.scm. Also  foo-default-soundfile-extension should be removed.

doing that currently, committing soon.  what should we do with
default-soundfile-type?

thanks, the new functions will ease dealing with soundfiles a lot.

bests,

martin

Re: [foo-devel] FOOSineXoverXTable.m

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

hi ramon,

On Mon, Aug 30, 2004 at 05:27:16PM +0200, Ramon Gonzalez-Arroyo wrote:
> FOOSineXoverXTable.m: In function `-[FOOSineXoverXTable 
> initWithTaps:size:]':
> FOOSineXoverXTable.m:87: error: `stderr' undeclared (first use in this 
> function)

added #include <stdio.h>.  seems not to be necessary on linux, for
whatever reason. compiles on gerhards machine at least.

> Something else, at some point you wrote
> 
> >1) FOOMOscillator: the oscillator module is prepared to work both on
> >sine tables as well as on file tables.  is the file table
> >functionality ever used?  as far as i can see, all file operations are
> >done via the FOOMReadSnd modules and friends.  just good to know...
> 
> Yes, I have used it with other tables. Actually this was done not so 
> long ago. Results were not breath-taking but who knows this was 
> probably my (conceptual) fault

good to know.  i just overlooked the 'osc~' scheme function, which
uses this functionality.  thought it was implemented in
FOOMOscillator, but not used from the scheme side.  just my fault.

bests,

martin

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

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

dear sirs,

I have done the new soundfile-funs-foo. Type, extensions and all that 
are dealt here with. I have also altered the directory trees and the 
makes in them.  Also altered the load order in toplevel.foo as 
discussed.

Now tools is within control. util is within tools and soundfus.foo has 
been renamed to soundfile-funs.foo.
This is the file with all the extension/type/SFDIR/make-sndname crab.

I don't know how to remove a directorybranch (tools in scm), but this 
should be removed.

Some comments :

> (define (foo:test-file-dir)
>   (let ((dir (getenv "SFDIR")))

Had no idea about this, but why not?

I have written a function hat-expand for the ^ symbol.

It takes first the environment SFDIR, and if it is not defined it takes 
foo:SFDIR. I don't know if this is a wonderful idea. My assumption: ^ 
is a "standard" for the environment SFDIR. If one has this variable 
defined, one expects it to be interpreted so. Otherwise if someone 
doesn't have an env. SFDIR, one may want to use the sign as foo:SFDIR. 
However, I am well aware it is not "elegant", and for someone trying to 
use both it could lead to confussion, who knows?

(define (foo:default-soundfile-type) foo-default-soundfile-filetype)

this should probably look different. I am using your definition in 
elkfoo.scm. Also  foo-default-soundfile-extension should be removed.

foo:find-name-type-extension

is the function to get a pair type extension from a soundfile name.


The rest should be clear I hope. I think this gives the functionalities 
we were looking for.

A +,

ramon

[foo-devel] FOOSineXoverXTable.m

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

Hello Martin,

I'm trying to check that everything works with my new changes but I get 
this error:

FOOSineXoverXTable.m: In function `-[FOOSineXoverXTable 
initWithTaps:size:]':
FOOSineXoverXTable.m:87: error: `stderr' undeclared (first use in this 
function)
FOOSineXoverXTable.m:87: error: (Each undeclared identifier is reported 
only once

, so I cannot make.


Something else, at some point you wrote

> 1) FOOMOscillator: the oscillator module is prepared to work both on
> sine tables as well as on file tables.  is the file table
> functionality ever used?  as far as i can see, all file operations are
> done via the FOOMReadSnd modules and friends.  just good to know...

Yes, I have used it with other tables. Actually this was done not so 
long ago. Results were not breath-taking but who knows this was 
probably my (conceptual) fault

Bests,

ramon

Re: [foo-devel] sinc interpolation questions

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

hi again,

just the latest tests: even with high tapsizes the kaiser window does
something in worst cases:

took a 20-24000 Hz @ 48k sweep now, going until niquist.  transposed
down by 6 octaves.  first aliasing kicks in (> -60dB) when the sine is
at ~ 20400 Hz with kaiser, at ~18950 Hz with hann.

bests,

martin

Re: [foo-devel] sinc interpolation questions

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

dear gerhard,

On Fri, Aug 27, 2004 at 11:35:13AM +0200, Gerhard Eckel wrote:
> >with the hann, when fixing either one of the bugs, i got distortion
> >immediately, since 1) we are doing a symmetric lookup, but get a zero
> >for one of the last taps, or 2) we are getting the correct value for
> >the last tap in looking back, but zero for the corresponding one by
> >ommiting the lookup for the other side.
> 
> you mean if you fix only one of the issues at a time, this is what you 
> get?

yes, i treated it as a proof for the mutual influence of the two bugs
to each other.

> >does this make sense anyhow or am i missing something?
> 
> Makes perfectly sense to me. Looking forward to using the Kaiser window 
> and propagating the changes to the MSP-verion of the resampling code. 
> Does the Kaiser window also have a down side?

there is a "beta" parameter for the kaiser window, but the only thing
i (and the teachers here) now is that the optimal value for audio is
between 5 and 8 or so.  the tradeoff is between main lobe width and
side lobe height, as usual, in resampling maybe the tradeoff between
bandwidth and SNR.  may be we should ask somebody who is familiar with
that, but couldn't find concrete values on the web (not even julius
orion IIId's).  the main idea is to concentrate the energy in the main
lobe.

the drawback is computional cost, you need the "modified bessel
function of the first kind, first order" (TM), which is some odd
differential stuff, thus could just be approximated.  referred to
another dsp library and matlab for that.  since that just happens at
table generation time, it doesn't matter.

there is a "perfect" window though to which the kaiser window itself
is just an approximation: the "prolate spheroidal window", downloaded
the paper yesterday. in order to compute that, you have to build a
matrix and then find the eigenvector corresponding to the largest
eigenvalue.  since i am hardly able to spell the math terms, i kept
away from that :-)

btw. i had a look at libsamplerate (a resampling library by the author
of libsndfile), and for the best sinc interpolator in his library (97
dB SNR with 97% bandwidth) he implemented a fixed-pointed number
representation since double is not precise enough for that.  takes
much longer to compute than foo...  guess we'll never reach that level
with foo, regardless of the window we are using...

all the best (last day in banff)

martin

Re: [foo-devel] print~ & lookup-snd~

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

Dear Martin,

> for the print function, i added the hack for just ommiting the first 4
> letters, with should lead to the old output format.  in the future,
> each module should handle it's one "print version", including
> meaningful parameters (bpf, soundfiles, line boundaries...)

Thanks. I imagined what was the reason, but I thought there was a print 
function. About the bpf, don't worry therefore, I assumed there was 
some other kind of problem because the contents were never printed with 
print~, but it was worth trying.


> guess the scheme code i have is just too old...

right. I am just checking with the suite of examples, but there are 
differences with respect to the manual. And by and by, one starts 
thinking better examples and all that crab, so it is slower than 
expected. Actually what I should be doing is a set of tests to check 
that everything still works fine with any "major" change, but then one 
becomes pedagogical and cosmetic and sugarized. Sweet instead of bitter 
tests. Gosh!

I was also waiting for the "proper" (?) moment to implement the new 
manipulation of soundfiles, in order to alter the corresponding 
functions in the interface lib.

Hopefully soon all.

All hopes for the sound in life,

Ramon

Re: [foo-devel] sinc interpolation questions

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

dear martin,

On Aug 27, 2004, at 7:49 AM, martin rumori wrote:
> this means that you are looking tap/2 samples back, but only tap/2-1
> samples in advance.  i think, the latter should read
>
> for (si = 1; si <= tot; si++, ti2 += tinc)

Yes, I think you are right.

> double xMax = _taps / 2 - .5;
>
> if (x > xMax)
> {
>   return 0;
> }
>
> that would mean applying a rectangular window in addition to the hann
> window by zeroing the second half of the last tap region.  again, with
> many taps the difference is almost zero, but for small tapsizes it
> could make a difference.

Yes, I understand. I didn't realize when I wrote that.

> i encountered that when debugging the kaiser window (still a bug in
> the bessel approximation in CVS, but fixed locally).  i used a sweep
> 20-20000 Hz @ 48k, transposed down by 6 octaves.  tested with both the
> windows and different tapsizes, had a look at the sprectrum and got
> somehow strange results.

It is great that you are introducing a Kaiser window. I was not aware 
that this can improve performance with small number of taps. Your stay 
in Banff is very successful in any sense!

> when fixing the abovementioned issues, i got more meaningful results.
> now the kaiser window gives much better results than the hann when
> using smaller tapsizes, i. e. the aliasing reaches the -60dB later
> when getting towards nyquist.  for large tapsizes, however, the
> difference doesn't really matter.

That sounds like a great result!

> with the hann, when fixing either one of the bugs, i got distortion
> immediately, since 1) we are doing a symmetric lookup, but get a zero
> for one of the last taps, or 2) we are getting the correct value for
> the last tap in looking back, but zero for the corresponding one by
> ommiting the lookup for the other side.

you mean if you fix only one of the issues at a time, this is what you 
get?

> does this make sense anyhow or am i missing something?

Makes perfectly sense to me. Looking forward to using the Kaiser window 
and propagating the changes to the MSP-verion of the resampling code. 
Does the Kaiser window also have a down side?

Best regards from Krems,

Gerhard

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

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

dear fooers,

On Thu, Aug 26, 2004 at 07:48:12PM +0200, Ramon Gonzalez-Arroyo wrote:
> >we could reintroduce the comment interface, but i don't know whether
> >you want it.
> 
> I am not very sure whether it is wanted. It is always a messy thing. 
> Not all filetypes suport it, of those that support it, different 

you are right.  i'll schedule it with low priority.  but shouldn't be
too hard to bring it back.

> being. I remember we used it at some point to keep segment-definitions 
> as an interface to some signal editor (because that was the way the 
> editor was saving the segments points). On the other hand other users 

i heard somewhat about aiff (?) allowing markers in the file (not
stored in the comment).  snd could set them.  libsndfile doesn't has
support for that.  a neat thing, but difficult with respect to
different formats, anyway.

> >(create-soundfile "test.aiff" 'aiff 'short 48000 2)
> 
> For me it's ok. I have to change the order when calling the function, 
> but that's fine (It's only done once).

cool.

> >'incremental is a filetype now, meaning snd/au according to erik de

> I am not very sure about this. Normally speaking one would mix 
> incrementally using floats, but I wouldn't forbid doing that in shorts 
> or whatever. There are always good reasons to do otherwise.

it's not forbidden.  foo will choose the most performant sample format
for the platform just in case 'auto is given instead of 'short or
'long or so.

> Then, if I understand correctly, you mean that the old floatmix.imx is 
> now always an snd/au ? Because of efficiency as I understand. Mmmmm. To 

yes, because it is the file with the simplest header (cheapest for
parsing) while being most flexible with regards to the sample format
and the file length.  wav for example won't allow files larger than 2
GB, which is reached quite quickly with 8 channels in float and 96 kHz
e.g.

> say the truth I have incrementally mixed like a fooL but almost always 
> using the blend option, and not the incremental mixing proper, 

the blend option won't get touched at all.  with blend, you can
specify whatever filetype/sampletype combination you want.

i think of using the incremental mixing is kind of using a black box:
you are mixing like a fooL until ready, then you'll do a "mixdown"
with (read-snd~) anyway in order to convert the float format to the
desired int format.

when touching the soundfile inside the incremental dir manually, i
think it's not a problem: all sndfile-based and most of the other
professional tools support 'snd/'au.

but, for the sake of convenience: i can add a kernel function for
specifying the current filetype which gets used for incremental mixing
files.  when doing that, we should keep the name mixfloat.imx or
something static (rather than mixfloat.snd, like i proposed) in order
to be able to open the file.  what do you think?

but, in general i think the user should not touch the enclosed
soundfile, since that violates the incremental mechanism.  he should
be forced to do a (read-snd~) and then "import" the manipulated file
again into a new mixfile.

> >we don't need to have too comfortable functions for editing this
> >database, since it gets quite unlikely that a user has to touch it
> 
> I don't quite agree with this, Let us use your dual cases as example. 
> Both aiff and aif are aiff. We (developers) choose .aiff, but I (user) 
> prefer .aif. What should I do? Same stands for .au/.snd. Further, I am 
> not very sure that all filetypes have a standard extension. So editing 
> the database, or having a user-database which shadows the foo-database 
> should be there.

agreed.  i just proposed using a list on both sides of the database
rather than single values, such that specifying ".aif" and ".aiff"
both returns 'aiff.  when doing the reverse lookup, 'aiff could return
the first entry in the list, which is user-changeable.

> Now I understand your environment variable. You mean unix-shell 
> environment variable, Actually SFDIR in Foo  was never an environmnet 
> variable, Personally I don't care about that, beacuse each branch of a 

it is, at least for testfiles (kernel/elkfoo.scm):

(define (foo:test-file-dir)
  (let ((dir (getenv "SFDIR")))
    (if dir
        dir
        (string-append "/tmp/" (getenv "USER")))))

> OK I'll write the functions and share with you doubts and etceteras. 

good.

> Global variables will always be defined as functions?:
> 
> foo:default-var
> foo:set-default-var

i am not that scheme-experienced, but i've got the impression that
that's the common way.  looks good to me.

> Then, should I wait until create-soundfile is changed?

for writing, you can rely on the format on which we agreed.  for
testing, indeed, it's better to wait for the new function :-)  will
try to do that soon.

> Also. I am not sure I now the (standard) extensions for all filetypes. 
> Should I invent? Is there a list somewhere?

invent.  it takes just changing a single file followed by a "cvs ci"
if we get known of additional conventions which we want to correct
globally.

> I'll add the functions to tools/util/soundfuns.foo
> Then I'll put back the tools dir into the control dir, and change 
> toplevel. OK?

good idea.  sorry again for the invconvenience i caused by messing up
the holy scm tree :-)

bests,

martin

Re: [foo-devel] print~ & lookup-snd~

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

dear ramon again,

On Thu, Aug 26, 2004 at 07:48:18PM +0200, Ramon Gonzalez-Arroyo wrote:
> (define s1 (make-sigpack 440  '((0 #s-1) (.1 1) (1 1)) '(mod .02 6 .01 
> 8)))
> (context 1 (print~ (Eval-sigpack s1 1)))

apply: too few arguments for #<compound Env-reset>
Inspector (type ? for help):
inspect>

guess the scheme code i have is just too old...

bests,

martin

Re: [foo-devel] print~ & lookup-snd~

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

dear ramon,

thanks for the reports.

On Thu, Aug 26, 2004 at 07:48:18PM +0200, Ramon Gonzalez-Arroyo wrote:
> ;  (Add

> ;  (FOOMAdd

this is due to the renaming of the module classes.  since there is no
namespace concept in objc, we followed the recommendation and added a
unique prefix.

for the print function, i added the hack for just ommiting the first 4
letters, with should lead to the old output format.  in the future,
each module should handle it's one "print version", including
meaningful parameters (bpf, soundfiles, line boundaries...)

> Couldn't we remove the FOOM prefix and add the values of the constants? 

added again.  did comment them while porting in order to avoid mutual
#include.

> Eventually also the bpf argument?

there is already a print-command for bpf implemented.  unfortunetaly,
it is not called when printing a context, since you won't print a bpf
directly but the reader object.  i tried to call the bpf-print from
inside the module-print, but the output will get messed up.  the
print-call prints all the subsequent prints (printsprints) into one
single buffer which flies around at print time.  unlike the bpf print,
it prints directly to the output, therefore it's difficult to include
this output at the right position without changing the whole print
mechanism.  with the new module API everything will get better :-)

in the meantime, you can do:

(define bpf (make-bpf '((0 0) (1 3) (1.1 4.4))))
(tell (bpf-pointer bpf) 'print)

beginT = 0.000000, endT = 1.100000
 0: 3.000000 1.000000 0.000000 0.000000 -1
 1: 4.400000 1.100000 0.000000 0.000000 -1
#[pointer <id> {FOOBreakpointFunction instance} (143560456)]


> have a look at this:
> 
> > (syn 1 1 (output~ 1 (lookup-snd~ (open-snd "/tmp/sin.aiff") 
> (read-bpf~ (make-bpf '((0 0) (1 1)))))))
> 2004-08-26 18:41:03.787 foox[12547] *** -[FOOMLookup 
> initializeWith:taps:]: selector not recognized

fixed.  renaming issues, named back so far.  the goal is to have the
OpenStep-like init-methods, in this case: initWithSubstrate: taps:

bests,

martin

[foo-devel] sinc interpolation questions

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

dear gerhard,

while implementing both the interpolation for the FOOMComb and the
kaiser windowing for the sinc tables, i discovered two issues
regarding interpolation in foo, with seem to be related to each other:

1)
sinc table lookup in FOOMTransposeSnd:

for (si = 0; si > -tot; si--, ti1 += tinc)
{
}

for (si = 1; si < tot; si++, ti2 += tinc)
{
}

this means that you are looking tap/2 samples back, but only tap/2-1
samples in advance.  i think, the latter should read

for (si = 1; si <= tot; si++, ti2 += tinc)

in order to do a symmetric lookup.  if the fractional sample position
matches *exactly* a sample, we will be looking one sample too less
back, but in that case all the lookups will yield zero anyway.

the asymmetric lookup won't change too much when using many taps, but
with a small tapsize the contribution of the missing sample might get
noticeable.


2)
FOOSineXOverXTable:

double xMax = _taps / 2 - .5;

if (x > xMax)
{
  return 0;
}

that would mean applying a rectangular window in addition to the hann
window by zeroing the second half of the last tap region.  again, with
many taps the difference is almost zero, but for small tapsizes it
could make a difference.

when relating this to the issue above, that would mean: for a tapsize
of let's say 8 you are looking 7 samples in advance, thus never
hitting this zeroed region.  when looking back, there is a certain
probability that you would pick up a zeroed sample for the 8th tap
lookup.  this would just mean reducing the tap size by one, without
touching the symmetry of the process.  in the other case, the result
will distort the output with small tapsizes only (like 8).

i encountered that when debugging the kaiser window (still a bug in
the bessel approximation in CVS, but fixed locally).  i used a sweep
20-20000 Hz @ 48k, transposed down by 6 octaves.  tested with both the
windows and different tapsizes, had a look at the sprectrum and got
somehow strange results.

when fixing the abovementioned issues, i got more meaningful results.
now the kaiser window gives much better results than the hann when
using smaller tapsizes, i. e. the aliasing reaches the -60dB later
when getting towards nyquist.  for large tapsizes, however, the
difference doesn't really matter.

with the hann, when fixing either one of the bugs, i got distortion
immediately, since 1) we are doing a symmetric lookup, but get a zero
for one of the last taps, or 2) we are getting the correct value for
the last tap in looking back, but zero for the corresponding one by
ommiting the lookup for the other side.

does this make sense anyhow or am i missing something?

bests,

martin

[foo-devel] print~ & lookup-snd~

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

Dear Fooers,

---> print~

The print~ function is less explicit and less clear. I am checking the 
examples with the new control , some of them make use of this 
functionality to show the meaning of some control-functions.

I send you an example so that you can see the previous output and the 
new one.

(define s1 (make-sigpack 440  '((0 #s-1) (.1 1) (1 1)) '(mod .02 6 .01 
8)))
(context 1 (print~ (Eval-sigpack s1 1)))

;;Old one :
;(Mul
;  (ReadBpf)
;  (Add
;    (Add
;      (Mul
;        (Oscillator
;          (Constant [6]))
;        (Constant [0.02]))
;      (Mul
;        (BandlimittedNoise
;          (Constant [8]))
;        (Constant [0.01])))
;    (Constant [1]))
;  (Constant [440]))#[context (1 channel)]

;;New one :
,(FOOMMul
;  (FOOMReadBpf)
;  (FOOMAdd
;    (FOOMAdd
;      (FOOMMul
;        (FOOMOscillator
;          (FOOMConstant))
;        (FOOMConstant))
;      (FOOMMul
;        (FOOMBandlimitedNoise
;          (FOOMConstant))
;        (FOOMConstant)))
;    (FOOMConstant))
;  (FOOMConstant))#[context (1 channel)]


Couldn't we remove the FOOM prefix and add the values of the constants? 
Eventually also the bpf argument?


---> lookup-snd~

have a look at this:

 > (syn 1 1 (output~ 1 (lookup-snd~ (open-snd "/tmp/sin.aiff") 
(read-bpf~ (make-bpf '((0 0) (1 1)))))))
2004-08-26 18:41:03.787 foox[12547] *** -[FOOMLookup 
initializeWith:taps:]: selector not recognized
2004-08-26 18:41:03.790 foox[12547] *** Uncaught exception: 
<NSInvalidArgumentException> *** -[FOOMLookup initializeWith:taps:]: 
selector not recognized
Trace/BPT trap
Till later,

Ramon

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

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

Dear sirs,

Delays , lags, leaps, pits, abysses. Blups.

> we could reintroduce the comment interface, but i don't know whether
> you want it.

I am not very sure whether it is wanted. It is always a messy thing. 
Not all filetypes suport it, of those that support it, different 
lengths accepted, etc. Personally I am fine without it, for the time 
being. I remember we used it at some point to keep segment-definitions 
as an interface to some signal editor (because that was the way the 
editor was saving the segments points). On the other hand other users 
might feel it as a need. Perhaps we can have it as an optional argument 
:

> maybe the "comment" is enough with a fallback try on "title", if
> "comment" should be not supported.

;;;;

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

For me it's ok. I have to change the order when calling the function, 
but that's fine (It's only done once).

> 'incremental is a filetype now, meaning snd/au according to erik de
> castro lopo's recommendation, but we could transparently change that
> on demand.  therefore the extension for the actual soundfile inside
> the mix directory is fixed, since we don't allow specifying the actual
> file type.  if the user want's, he may specify a sample type, but we
> should use 'auto for that, which means: foo's processing sample type
> (== float) in host byte order.

I am not very sure about this. Normally speaking one would mix 
incrementally using floats, but I wouldn't forbid doing that in shorts 
or whatever. There are always good reasons to do otherwise.
Then, if I understand correctly, you mean that the old floatmix.imx is 
now always an snd/au ? Because of efficiency as I understand. Mmmmm. To 
say the truth I have incrementally mixed like a fooL but almost always 
using the blend option, and not the incremental mixing proper, 
therefore it is hard for rme to imagine cases where "in real life" this 
can be an inconvenient (a small one in any case). I know, that is why I 
mentioned it before, that I have incremented in shorts quite often 
(against the laws of reason, but for otehr good reasons). I guess that 
if the reasons for it are strong enough (for violating the sndfile-type 
of choice) we should do it, but I cannot judge.


>  'snd and 'au are the
> same format, ".aiff" and ".aif" are both extensions for 'aiff.

Yes, this was no problem in what I said.

> we don't need to have too
> comfortable functions for editing this database, since it gets quite
> unlikely that a user has to touch it

I don't quite agree with this, Let us use your dual cases as example. 
Both aiff and aif are aiff. We (developers) choose .aiff, but I (user) 
prefer .aif. What should I do? Same stands for .au/.snd. Further, I am 
not very sure that all filetypes have a standard extension. So editing 
the database, or having a user-database which shadows the foo-database 
should be there.

  Otherwise I agree with you.

Now I understand your environment variable. You mean unix-shell 
environment variable, Actually SFDIR in Foo  was never an environmnet 
variable, Personally I don't care about that, beacuse each branch of a 
tree has its own wills and paths, and it is an intimate thing where it 
does its things.

In the current version SFDIR is set by default to foo;test-file.dir. 
The functions get-SFDIR and set-SFDIR, where just changing the value of 
foo:SFDIR.

> definitely scheme code, since it's much easier to handle.  regarding
> the lower-level: we could introduce a "tool" file just for soundfile
> handling, creation, deletion, (may be even renaming, converting,
> resampling in the future) which is on top of the kernel functions, but
> below the control library, which in turn could make use of it.

OK I'll write the functions and share with you doubts and etceteras. 
Some questions though:

Global variables will always be defined as functions?:

foo:default-var
foo:set-default-var

Then, should I wait until create-soundfile is changed?

Also. I am not sure I now the (standard) extensions for all filetypes. 
Should I invent? Is there a list somewhere?

I'll add the functions to tools/util/soundfuns.foo
Then I'll put back the tools dir into the control dir, and change 
toplevel. OK?

Bests,

Ramon

Re: [foo-devel] fooelk configure fails

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

On Aug 26, 2004, at 5:15 PM, martin rumori wrote:
> b.t.w., on the ANET summit last weekend i met johannes goebel.  he was
> quite surprised that foo still exists...  hehe.

good to know that he knows it is still alive - he made it possible in=20
the first place by receiving Ram=F3n and me at ZKM to develop it there!

Best regards from Krems,

Gerhard

Re: [foo-devel] fooelk configure fails

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

On Thu, Aug 26, 2004 at 03:24:47PM +0200, Gerhard Eckel wrote:
> I tried with an extra ./bootstrap, yes, but still didn't run through. I 
> threw away the old checkout. It works fine with a new one. Sorry for 
> the noise.

still strange.  but i've got an idea: you have to do a

cvs up -d[P]

in order to get newly checked in directories updated.  otherwise just
the existing ones get updated.  -P deletes empty directories after
checkout.

since the examples stuff was checked in later, that may be a reason.

b.t.w., on the ANET summit last weekend i met johannes goebel.  he was
quite surprised that foo still exists...  hehe.

bests,

martin

Re: [foo-devel] fooelk configure fails

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

On Aug 26, 2004, at 11:51 AM, martin rumori wrote:
> On Thu, Aug 26, 2004 at 10:23:09AM +0200, Gerhard Eckel wrote:
>> Dear Martin,
>>
>> I just discovered that configure fails in fooelk with:
>>
>> config.status: error: cannot find input file: examples/Makefile.in
>> configure: error: /bin/sh './configure' failed for elkfoo
>
> hmm.  fresh checkout works here.  did you try an extra ./bootstrap
> again (seems to be necessary sometimes)?

I tried with an extra ./bootstrap, yes, but still didn't run through. I 
threw away the old checkout. It works fine with a new one. Sorry for 
the noise.

Best regards,

Gerhard

[foo-devel] comb module

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

dear foo-devels,

i just checked in two experimental new modules (wanted to wait for the
new dynamic module layout first, but couldn't resist to do our labs in
the banff DSP courses on foo instead of VST plugins).

i used the allpass for a chirp generation (which takes way too long,
since you'll need an order of several thousand for reasonable
length).  have to get back to it and figure out how to layout the
params best in order to get nice phase distortion effects...

the comb seems to work now.  for easier experimenting, there is the
fourth input signal, which controls the mixture of the wet-dry signal.
i am not completely comfortable with that, since it violates somehow
the patch philosophy.

what do you think?  if the user wants to get e. g. comb filter effects
just due do delay, he should use the comb object and add it to the
undelayed input himself, shouldn't he?  this way we could save this
input.

bests,

martin

Re: [foo-devel] fooelk configure fails

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

On Thu, Aug 26, 2004 at 10:23:09AM +0200, Gerhard Eckel wrote:
> Dear Martin,
> 
> I just discovered that configure fails in fooelk with:
> 
> config.status: error: cannot find input file: examples/Makefile.in
> configure: error: /bin/sh './configure' failed for elkfoo

hmm.  fresh checkout works here.  did you try an extra ./bootstrap
again (seems to be necessary sometimes)?

bests,

martin (time to go to bed)

[foo-devel] fooelk configure fails

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

Dear Martin,

I just discovered that configure fails in fooelk with:

config.status: error: cannot find input file: examples/Makefile.in
configure: error: /bin/sh './configure' failed for elkfoo

Best regards,

Gerhard

Re: [foo-devel] elk garbage collector

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

dear gerhard,

On Mon, Aug 16, 2004 at 11:59:49PM +0200, Gerhard Eckel wrote:
> On Aug 16, 2004, at 8:02 AM, martin rumori wrote:
> >would remove the scheme object for the 2-channel-context, but not the
> >corresponding objc-object?

> be freed. I think I decided to have the ObjC-objects dangling around, 
> accepring the memory leak. I think at that time Elk didn't have the 

no, you didn't accept it.  sorry for complaining.  i thought i
greped through the entire cprog.ps now --  but am still missing
something, apparently.

Register_Object() does the trick and it is already done for the foo
context.  since all other objc objects (like modules) are registered
with the context, we don't have a memory leak.

i was just wondering when looking over the other elk type definitions
and i've got the impression that elk is lacking the functionality of a
finalizer.

glad that it's not the case, since i was thinking about how to
implement several external module tricks during the last days...

bests,

martin

Re: [foo-devel] offline

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

On Tue, Aug 17, 2004 at 09:28:19AM +0200, Gerhard Eckel wrote:
> a little warning: I will be offline for 2 days from now.

.. but not your computer, apparently.  great. :-)

have a good time...

martin

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

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

dear fooers,

On Mon, Aug 16, 2004 at 11:42:26PM +0200, Gerhard Eckel wrote:
> On Aug 16, 2004, at 2:43 PM, Ramon Gonzalez-Arroyo wrote:
> >On first approach, I think the strategy for "basic" functions is not 
> >to have optionals, but rather to build adjacent functionalities that 
> 
> This is quite important for higher order programming (passing functions 
> to functions, which get called, so the signature should be rather 
> unambiguous. It is also important when writing macros, althought I 

of course, good to know.  even my taste is not very constant:
sometimes i like sugar and error-prone magic, sometimes the cleaner
the better.  in this case definitely for the cleaner at kernel level.

but where we are at this point: maybe we just should clean up the
(create-soundfile) interface.  remember, when introducing the
different filetypes, i just replaced the optional "comment" argument
into the filetype argument, which is not that beautiful for the
future.  by the way, libsndfile support reading and writing string
data since the last or one the versions before:

<cite url="http://www.mega-nerd.com/libsndfile/api.html">

const char* sf_get_string   (SNDFILE *sndfile, int str_type) ;
int         sf_set_string   (SNDFILE *sndfile, int str_type, const char* str) ;

These functions allow strings to be set on files opened for write and to be retrieved from files opened for read where supported by the given file type. The str_type parameter can be any one of the following string types:

          enum
          {   SF_STR_TITLE,
              SF_STR_COPYRIGHT,
              SF_STR_SOFTWARE,
              SF_STR_ARTIST,
              SF_STR_COMMENT,
              SF_STR_DATE
          } ;
</cite>

i don't know whether we really need an interface to all the strings,
maybe the "comment" is enough with a fallback try on "title", if
"comment" should be not supported.

we could reintroduce the comment interface, but i don't know whether
you want it.

anyway, i'd rather like to move the file-type argument of
(create-soundfile) away from the last and optional position to a more
"intuitive" one:

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

having the filetype-field optional is really crappy with respect to
your comments on low-level functions.

for incremental i'd propose:

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

'incremental is a filetype now, meaning snd/au according to erik de
castro lopo's recommendation, but we could transparently change that
on demand.  therefore the extension for the actual soundfile inside
the mix directory is fixed, since we don't allow specifying the actual
file type.  if the user want's, he may specify a sample type, but we
should use 'auto for that, which means: foo's processing sample type
(== float) in host byte order.

this should not break many things, since it just has to be changed in
the control, am i right?  may be with the optional comment parameter,
again.  what do you think?

> incremental mixing directory was indeed thought as kind of a black box, 
> to be treated by tools who know how to operate with its contents 
> (humans playing the role of the tools were never excluded). I think on 

> the NeXT one could register extensions which would show as atomic units 
> in the finder (such as .app - if you create a directiry foo.app it will 

yes, on hp-ux there was a similar thing using different binaries: if
you try to start a directory, the correct binary for that platform was
grabbed out of the directory and executed...

On Mon, Aug 16, 2004 at 02:43:05PM +0200, Ramon Gonzalez-Arroyo wrote:
> >i was thinking of the other way round, too: when
> >issuing the name "test.aiff" the system could guess that i want to
> >create an aiff file
> 
> We can do both, why not? We can have a function that parses the name 
> and checks if an extension is given. We have to think though that a 

great idea, and dividing into a lower and higher level interface is of
course much better than applying magic to the kernel.

> name of a soundfile may have a period and a subname without it meaning 
> an extension. The only problem is the order in which we evaluate the 

yes, we neither can't rely on being the part of the name after the
period an extension nor the extension being of length 3.  the only
thing we could do is to find out whether the filename ends with one of
our extensions in the database, preceded by a period.  otherwise we
didn't recognize the extension and add one (if
(foo:soundfile-name-extension?) is set).

> (foo:soundfile-name-extension?)  returns a boolean
> (foo:default-soundfile-type)  returns a symbol or rather a string
> (foo:default-soundfile-type-extensions . type) {is our database} 
> returns a string when type is given or a list of pairs when executed  
> with no arguments.
> (foo:set-default-soundfile-type-extension type extension) returns the 
> old extension, and sets the value of extension blablabla
> (foo:default-soundfile-extensions-type . extension) returns a symbol 
> (the type)  when extension is given or a list of pairs when executed  
> with no arguments.

good idea.  i completely agree, just one issue: 'snd and 'au are the
same format, ".aiff" and ".aif" are both extensions for 'aiff.  if we
had lists on both sides of the database which are used for recognizing
whether an extension is given or not (several possibilities to match),
while for setting just the (car) is used, wouldn't that be more
flexible?  i think when having this, we don't need to have too
comfortable functions for editing this database, since it gets quite
unlikely that a user has to touch it (he would rather just specify
extension and type for a single exotic case).

> > i am just wondering why we use an environment variable for the
> >initial state of foo:SFDIR?  a global scheme variable (properly
> 
> If I understand correctly your question, the answer is because it was 
> an afterthought. I included it in the distribution later, when I 

do i remember correctly that '^' was expanded to sfdir?  that's a nice
thing.  should we just switch to a scheme variable similar to the
temp-file dir instead of the environment variable?

> Now as we see make-sndname becomes somewhat more complex, and requires 
> a more global strategy, therefore my questioning whether we shouldn't 
> consider all this already at a lower level.
> 
> So first question. Assume we agree in the creation of these global 
> functionalities mentioned above. (including the SFDIR functionalities) 
> Should they be objc or scheme code?

definitely scheme code, since it's much easier to handle.  regarding
the lower-level: we could introduce a "tool" file just for soundfile
handling, creation, deletion, (may be even renaming, converting,
resampling in the future) which is on top of the kernel functions, but
below the control library, which in turn could make use of it.  not in
order to keep the user away from SP-run, just to allow for more
comfortable soundfile operation than on kernel level.

what do you think about that?

bests,

martin

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

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

On Tue, Aug 17, 2004 at 12:07:49AM +0200, Gerhard Eckel wrote:
> I am afraid I cannot propose a consistent naming strategy. For the the 
> difference was: foo:something would be a symbol where something alone 

hmm.  i like the foo: package idea.  so whereever there is something
obviously not according the naming style (since committed by me), now
is the time to fix that...

bests,

martin