there is one little issue left in the makefile:

• $(LD) $(LD_DARWIN) -o $*.pd_linux $*.o $(LIB)

• $(LD) $(LD_DARWIN) -o $*.pd_darwin $*.o $(LIB)

last night i did my tests with pd-miller-0.39-1, the one with the
memory leak in portaudio. i i'll do a proper build now (using gcc 4
and the leakfix) and try to crash it tonight with your sndfiler using
my bergen patches :)

lorenz

Am 21.11.2005 um 10:06 schrieb Georg Holzmann:

Hallo!

...

line 98: here you should give at least -lsndfile. -L/sw/lib and - L/ opt/local/lib are for fink/darwinports. perhaps this could be
somewhere else (LDPATH). LD_DARWIN = -bundle -undefined suppress -flat_namespace
-bundle_loader $(PD_PATH)/bin/pd --export-dynamic
-L/sw/lib -L/opt/local/lib -lsndfile

thanks for the makefile fix ! (didn't try it on osx ;) btw: you also have to link against threadlib.pd_darwin (so you
don't have to load it before ... - makefile attached)

...

probably this was caused by me loading files, resizing arrays and
trying to tabread~ them at the same time :). probably it's because
i compiled them with gcc 4, i'll try 3.3 tomorrow. anyway great
work.

no, I also use gcc4 - also tried the same now (read - resize -
tabplay) but didn't get a crash ... can you reproduce this
behaviour somehow and send me an example patch?

thanks ... LG Georg # ----------------------------------------------------------

# adjust the next pathes to your system:

# this should point to the directory which contains # m_pd.h and g_canvas.h PD_SCR = /home/holzi/pd-0.39-1/src #PD_SCR = c:/pd/src

# this is the pd directory, usually /usr/lib/pd # or c:/pd etc. PD_PATH = /usr/lib/pd #PD_PATH = c:/pd

# path of sndfile.h from libsndfile, usually it's in # /usr/include and so detected automatically SNDFILE_SRC = /usr/include

# the directory, where libsndfile is located # (in linux it' normally not necessary, in windows it's # normally in c:/windwos/system or so) SNDFILE_PATH = c:/windows/system

# path to threadlib.h THREADLIB_SRC = /home/Georg/pd-cvs/externals/grh/threadlib/src #THREADLIB_SRC = c:/Georg/pd-cvs/externals/grh/threadlib/src

# path to threadlib.pd_linux/dll/pd_darwin # (usually path/to/pd/extra) THREADLIB_PATH = $(PD_PATH)/extra

# ----------------------------------------------------------

NAME=sndfiler

CC = gcc LD = gcc INCLUDE= -I. -I$(PD_SCR) -I$(SNDFILE_SRC) -I$(THREADLIB_SRC) CC_FLAGS = -DPD -DUSE_PD_MAIN -O3 -funroll-loops
-Wall -W -Wshadow -Wno-parentheses -Wno-switch
-Wno-unused -fomit-frame-pointer LD_FLAGS = --export-dynamic -shared -o

current: @echo ---------------------------- @echo USAGE: @echo linux: make pd_linux @echo windows: make pd_win @echo darwin: make pd_darwin @echo ----------------------------

# ----------------------- LINUX i386 -----------------------

pd_linux: $(NAME).pd_linux

.SUFFIXES: .pd_linux

CC_UNIX = -DUNIX -fPIC -pthread LIB_UNIX = -lc -lm -lsndfile $(THREADLIB_PATH)/threadlib.pd_linux

.c.pd_linux: $(CC) $(CC_UNIX) $(CC_FLAGS) $(INCLUDE) -o $*.o -c $*.c $(LD) $(LD_FLAGS) $*.pd_linux $*.o $(LIB_UNIX) strip --strip-unneeded $*.pd_linux chmod 755 $*.pd_linux @test -d ../bin || mkdir -p ../bin cp $*.pd_linux ../bin rm -f $*.o

# ------------------------ WIN MinGW -----------------------

pd_win: $(NAME).dll

.SUFFIXES: .dll

CC_WIN = -DMSW -mms-bitfields LIB_WIN = $(PD_PATH)/bin/pd.dll
$(SNDFILE_PATH)/pthreadGC.dll
$(SNDFILE_PATH)/libsndfile.dll
$(THREADLIB_PATH)/threadlib.dll

.c.dll: $(CC) $(CC_WIN) $(CC_FLAGS) $(INCLUDE) -o $*.o -c $*.c $(LD) $(LD_FLAGS) $*.dll $*.o $(LIB_WIN) strip --strip-unneeded $*.dll chmod 755 $*.dll @test -d ../bin || mkdir -p ../bin cp $*.dll ../bin rm -f $*.o

# ----------------------- Mac OSX -----------------------

pd_darwin: $(NAME).pd_darwin

.SUFFIXES: .pd_darwin

CC_DARWIN = -pthread LD_DARWIN = -bundle -undefined suppress -flat_namespace
-bundle_loader $(PD_PATH)/bin/pd --export-dynamic
-L/sw/lib -L/opt/local/lib -lsndfile
$(THREADLIB_PATH)/threadlib.pd_darwin

.c.pd_darwin: $(CC) $(CC_FLAGS) $(CC_DARWIN) $(INCLUDE) -o $*.o -c $*.c $(LD) $(LD_DARWIN) -o $*.pd_linux $*.o $(LIB) chmod 755 $*.pd_darwin @test -d ../bin || mkdir -p ../bin cp $*.pd_darwin ../bin rm -f $*.o

# ----------------------------------------------------------

clean: rm -f *.o *.pd_darwin *.pd_linux *.dll

install: install ../bin/$(NAME).* $(PD_PATH)/extra install ../doc/*.pd $(PD_PATH)/doc/5.reference

Hallo!

Could the new soundfiler be included in the next pd release?

would be useful - but then the lockfree fifo of pd_devel must be in main main pd (which would be really cool), but I doubt that this will happen ...

LG Georg

Hallo!

...

would be useful - but then the lockfree fifo of pd_devel must be in main main pd (which would be really cool), but I doubt that this will happen ...

Did I miss something? sndfiler doesn't need pd-devel, does it? I got it to work with your binary package and libsndfile packages on main pd...

yes - that's what the threadlib is for ... (there is the lockfree fifo and etc.)

BTW: what about the -resize problem I mentioned? Is it just a user (=my) problem? ;-)

yes :) it's a seperate message: [resize arrayname size( ... (see help file) but anyway, maybe this should be also in the read message, to be compatible with millers soundfiler ...

LG Georg

may I make the official dumb question? what is a threaded soundfiler?
what's the difference between a, uhhh, non-threaded soundfiler, audio or
just resources management?

what I forgot to say: [read filename array( will automatically resize the array to the size
of the audiofile ...

does this change anything about the existing size limit of the array size?
(don't remember how much it was, but not suited to long files)

joao

...

may I make the official dumb question? what is a threaded soundfiler? what's the difference between a, uhhh, non-threaded soundfiler, audio
or just resources management?

if you load a large soundfile with [soundfiler], while you are playing
some music, you will hear a (short or long - depends on the soundfile
size) audio drop out - because loading takes quite some time and will so
block pd's main thread. In [sndfiler] the loading is done in a helper thread - so it will be a
little bit longer, but shouldn't block audio ...

sounds quite handy (as the reactions of other users proved). any windose
relaese scheduled?

...

does this change anything about the existing size limit of the array
size? (don't remember how much it was, but not suited to long files)

yes - the size is much bigger ... (don't remember now the exact nr.) but anyway, that's only a define and can be changed ...

like everything in pd. I had already sometime ago wrote about it, but
there was no big desire to change this parameter. I can't do it myself, I
don't speak C, although lots of languages like english, german, french,
portuguese, etc...

...

sounds quite handy (as the reactions of other users proved). any
windose relaese scheduled?

this _is_ also a windows release ...

well, I managed to do the second official dumb question. and everything
with one post!

well, german or english is okay :) ... just write your wish to the list
or myself and I can change this define ...

well, that's swell. I'll try the external, but I guess that the
possibility to have greater arrays would be good. if it's used or not it
will be the decision of each user.

one general question: at least in windows, it is easy to notice the
limitations of tcl-tk as a gui, namely the slowing down of audio when too
many arrays are visible or dragged, or even several gui objects that are
banged almost at s-rate. has anyone thought about getting a faster
interface? or should this question also be posted in an own post?

joao