Hans,
if you download the latest code here
http://aug.ment.org/software/readanysf~0.40.tar.gz
..or, just go to the build lab and cd to
/Users/pddev/pure-data/trunk/externals/august/test/readanysf~0.40
you should be able to just type 'make'
I've c
So I looked at the files again, this worked for me (I just added the
last step):
cd externals/august/readanysf~
make -f Makefile.darwin
./embed-MacOSX-dependencies.sh
If you want to make the same package as me, then just:
cd ..
zip -9r readanysf~.zip readanysf~
That folder just drops into /
No, I didn't receive the build system changes. Do you remember how you
packaged everything into one Mac bundle? I should be able to just
reuse the gavl, gemerlin, ffmpeg, etc libs.
I'll write to the dev list and ask for access to the pdlab.
-a
> I don't remember, hopefully I sent you my b
I don't remember, hopefully I sent you my build system changes. I
won't have time to do it in the near future, but I can answer
questions. Also, you could request access to the PdLab build machines
if you need to build on Mac OS X, Debian, Ubuntu and Windows.
http://puredata.info/docs/d
It may take a little while for Burkhard to update his stuff. I have a
feeling he is busy now with work, and also with adding webm and other
features to gmerlin_avdec.
How about compiling a new readanysf~ for Mac? Do you still have it
set up to do it (is it just a matter of putting in the new c
Any idea when this will be released? I can update the Fink package
then.
.hc
On Jul 3, 2010, at 5:50 AM, august wrote:
okay,
This error should no longer occur in the next release of
gavl/gmerlin_avdecode.
-august.
Hi August,
thanks for your quick reply and so
> > so, I tracked down this bug. File handles were being inadvertently left
> > open.
> >
> > I made a new version of readanysf~ with reworking of the code based on
> > adjustments I had been making for other stuff I am working . It should
> > provide for more stable and modular code. Seeking
Hi August
On Sat, 2010-07-03 at 12:00 +0200, august wrote:
>
> so, I tracked down this bug. File handles were being inadvertently left
> open.
>
> I made a new version of readanysf~ with reworking of the code based on
> adjustments I had been making for other stuff I am working . It should
> p
Great news, August !
I look forward to testing this brand new version.
A pity I can't help with mac compiling ...
Pierre
Le 3 juil. 2010 à 12:00, august a écrit :
>
>
> so, I tracked down this bug. File handles were being inadvertently left
> open.
>
> I made a new version of readanysf~ with
okay,
This error should no longer occur in the next release of
gavl/gmerlin_avdecode.
-august.
> Hi August,
>
> thanks for your quick reply and sorry for my slow one ;-) The short
> answer is that cleaning up the headers of the soundfiles by re-encoding
> with sndfile
so, I tracked down this bug. File handles were being inadvertently left
open.
I made a new version of readanysf~ with reworking of the code based on
adjustments I had been making for other stuff I am working . It should
provide for more stable and modular code. Seeking should also be
non-blo
On Wed, 23 Jun 2010, august wrote:
I've tried all (prior "pause", "stop" and straight "open") and haven't noticed
any change.
It really shouldn't matter if you send "pause" or "stop" before "open".
I asked the question to verify that it really shouldn't matter.
I also tracked down the "To
Le 23 juin 2010 à 12:41, august a écrit :
> I've tried all (prior "pause", "stop" and straight "open") and haven't
> noticed any change.
>
>
> It really shouldn't matter if you send "pause" or "stop" before "open".
>
>
> I also tracked down the "Too many open files" error message.
> >>> I've tried all (prior "pause", "stop" and straight "open") and haven't
> >>> noticed any change.
It really shouldn't matter if you send "pause" or "stop" before "open".
I also tracked down the "Too many open files" error message. It DOES
come from readanysf~, .from the gmerlin_av
Le 22 juin 2010 à 23:13, Mathieu Bouchard a écrit :
> On Tue, 22 Jun 2010, Pierre Cage wrote:
>
>>> I've tried all (prior "pause", "stop" and straight "open") and haven't
>>> noticed any change.
>
> Do you get any messages in the Terminal, when you start Pd from the Terminal ?
>
> (the "open"
On Tue, 22 Jun 2010, Pierre Cage wrote:
I've tried all (prior "pause", "stop" and straight "open") and haven't
noticed any change.
Do you get any messages in the Terminal, when you start Pd from the
Terminal ?
(the "open" command of the Terminal doesn't count, as it only asks the
Finder to
> Hi Mathieu,
>
>
> Le 22 juin 2010 à 22:30, Mathieu Bouchard a écrit :
>
>> On Tue, 22 Jun 2010, pierre cage wrote:
>>
>>> On my system (osx 10.6, Pd-Ext 0.42.5-RC2, hcs' readanysf intel binary),
>>> and no matter the format and the size of the files, 240 successive openings
>>> lead to: "In
On Tue, 22 Jun 2010, pierre cage wrote:
Seems that my first post has been truncated ...
I didn't see any truncation in the first post. Actually, your second post
was the shorter one, because it quoted much less text from previous mails.
_ _ __ ___ _ _ _
On Tue, 22 Jun 2010, pierre cage wrote:
On my system (osx 10.6, Pd-Ext 0.42.5-RC2, hcs' readanysf intel binary),
and no matter the format and the size of the files, 240 successive
openings lead to: "Invalid file or unsupported codec. Current file is
either invalid or an unsupported codec"
Lo
Hi August,
Well, no unexpected noise here. I've tested with many various files
(pd/doc/sound/voice.wav & bell.aiff included !) and the behaviour is always the
same.
At 240th opening, readanysf begins to report "invalid etc..." and then (after 2
or 3 more iterations) playback just stops.
As alre
This may or may not be related or useful, but:
I got this 'too many files open' error a while ago in a patch with many
readsf~ (without 'any') objects.
I did this:
edit /etc/security/limits.conf
and add :
[username] soft nofile 4096
[username] hard nofile 4096
(see http://ubuntuforums.org/showth
> Seems that my first post has been truncated ...
>
> -- Forwarded message --
>
> Hi everyone,
>
> Sorry to interfere but I'm experiencing similar issues and cleaning up
> the headers doesn't seem to solve the problem ...
>
> >From user's point of view (no dev skills in here !),
Seems that my first post has been truncated ...
-- Forwarded message --
Hi everyone,
Sorry to interfere but I'm experiencing similar issues and cleaning up
the headers doesn't seem to solve the problem ...
>From user's point of view (no dev skills in here !), it seems that pd
ge
Hi everyone,
Sorry to interfere but I'm experiencing similar issues and cleaning up
the headers doesn't seem to solve the problem ...
>From user's point of view (no dev skills in here !), it seems that pd
gets overloaded by too many file's openings.
On my system (osx 10.6, Pd-Ext 0.42.5-RC2, hcs
Okay, glad to hear you have it solved.
If you can, please post an example of the soundfile that didn't work so
that I can test it.
thanks-august.
> Hi August,
>
> thanks for your quick reply and sorry for my slow one ;-) The short
> answer is that cleaning up the headers of the soundfiles b
Hi August,
thanks for your quick reply and sorry for my slow one ;-) The short
answer is that cleaning up the headers of the soundfiles by
re-encoding with sndfile-convert did the trick. Celine, the student I
am working with, promised to write you a bit later with more details.
Best!
Dere
Yes, I went and did this by simply re-encoding with sndfile-convert
(which probably just rewrites the headers when converting wav to wav).
I wasn't sure what they were, thanks for explaining! Will report back
when the student lets me know how it went...
D.
On 6/15/10 7:21 PM, Kim Cascone w
*** minf : 16 (unknown marker)
*** elm1 : 7506 (unknown marker)
data : 140114520
*** regn : 92 (unknown marker)
*** umid : 24 (unknown marker)
*** DGDA : 6602919 (unknown marker)
also, go in and remove any/all markers in the wav file that may have
been created in an editing app beforehand
__
Derek
just taking a shot in the dark here but check the endianess of the wav files
sometimes different OS X apps will save out .wavs with big-bndian vs
little-endian
The default byte ordering assumed for WAVE data files is
little-endian. Files written using the big-endian byte ordering scheme
Derek,
Are you using MacOS X? What version of readanysf~? What version
of gavl and gmerlin_avdec are packaged with it/used with it?
I don't suspect it is the soundfile itself, but just in case, can you
put an example online for me. This is going to be a to
Hello August, list
I'm helping a student's installation, and we have created a patch
which uses 24 instances of readanysf~ to read from 24 different
soundfiles between 15min and one hour in length. All sound files are
mono, 16 bit, 44.1KHz WAV_PCM format.
The problem is that, after a
31 matches
Mail list logo
