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 /Library/Pd to install. :) I'll update
gavl and gmerlin on Mac OS X once Pd-extended 0.42.5 is released.
.hc
On Jul 10, 2010, at 6:07 AM, august wrote:
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 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/developer/PdLab
.hc
On Jul 8, 2010, at 4:25 AM, august wrote:
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 code)?
Do
you have a build system for putting it all together?
-a
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 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!
Derek
On 6/15/10 5:31 PM, august wrote:
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 tough
bug to
find, unless you see some sort of regularity in how the sound
turns
to noise for you and can report that to me?
can you make a simple patch that isolates the bug?
Also, when the sound goes to noise, is it just that one
particular
soundfile that is used in readanysf or is it PD's entire
output.
In
other words, when you hear noise, can you also hear the other
readanysf's playing....or can you also make a simple osc~ and
hear it
play correctly?
The "Current file is either invalid or an unsupported codec."
warning
can also come if you send "play" to the readanysf object
without it
having a file loaded. I assume this is what is happening.
-a.
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 length of time, the readanysf~
objects
output noise rather than the soundfile. It is not the result
of any
single soundfile, and many or all of the readanysf~ objects
can be
affected by this simultaneously.
I have attached the abstraction in question. The object is
instantiated
as [readanysf~ 1], in other words the block size and and buffer
size are
defaults.
Sample terminal output is as follows while the patch is
running:
Created new readanysf~ with 1 channels and internal buffer of
24
* 64 = 1536
Current file is either invalid or an unsupported codec.
Current file is either invalid or an unsupported codec.
Current file is either invalid or an unsupported codec.
Current file is either invalid or an unsupported codec.
Current file is either invalid or an unsupported codec.
Current file is either invalid or an unsupported codec.
Current file is either invalid or an unsupported codec.
Opening each soundfile individually with readanysf~ and sending
"play"
and "pause" messages reports no errors whatsoever, however.
I have sndfile-info data for all of the soundfiles. The only
irregularity I see in this is one file which reports:
Unknown chunk marker at position 6087587. Resynching.
Besides that, most of the files report something like this:
File : F_DOK6.wav
Length : 146725772
RIFF : 146725764
WAVE
bext : 602
fmt : 16
Format : 0x1 => WAVE_FORMAT_PCM
Channels : 1
Sample Rate : 44100
Block Align : 2
Bit Width : 16
Bytes/sec : 88200
*** minf : 16 (unknown marker)
*** elm1 : 7506 (unknown marker)
data : 140114520
*** regn : 92 (unknown marker)
*** umid : 24 (unknown marker)
*** DGDA : 6602919 (unknown marker)
End
----------------------------------------
Sample Rate : 44100
Frames : 70057260
Channels : 1
Format : 0x00010002
Sections : 1
Seekable : TRUE
Duration : 00:26:28.600
Signal Max : 11627 (-9.00 dB)
Someone suggested the noisy output may be the result of a
buffer
problem, but I am not sure who I could verify or correct this.
I checked with "top" while the noise was happening and saw no
evidence
that Pd was using any more memory than usual, and the CPU meter
reported
30%.
Hardware is an Intel Mac Mini, software is Pd-Extended 0.41.4.
Any suggestions or other diagnostics I could run are
appreciated.
Best!
Derek
----------------------------------------------------------------------------
All mankind is of one author, and is one volume; when one man dies,
one
chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
--
-------------------
http://aug.ment.org
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
