Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

Yeah, an [anysoundfiler] would be super handy.

Almost there already: Search the archive for [oggfiler]: It's an abstraction I once wrote that uses [oggread~] to read oggfiles into tables in an upsampled subpatch. Should be trivial to adapt to readanysf~, and if readanysf~ also reports total length, you can even resize the table if you want.

Ciao

Frank

hi

well ..that sounds brilliant - but why is it dependent on some 'gavl' ??

not something more common, like libaudiofile, for example??

libaudiofile is not much different from the more common libsndfile. Both only read "uncompressed" formats.

gavl is a really brilliant low-level library which handles the details of audio and video formats like colorspaces, samplerates, multichannel configurations etc.

gmerlin_avdecode uses gavl to deliver frames of audio and video (including conversions and resampling). It can decode all kinds of media files....mp3, ogg, flac, mp4, x264..etc. Pretty much everything that can be played with mplayer.

Together, they are as close to a full-fledged multi-media api that I have seen yet on linux. gstreamer comes close, but has a really large and complex design.

I think you will see gavl/gmerlin become more standard in the future. Lumiera, the new video editing software from the cinelerra-cv folks, is based on it.

It IS unfortunate that they aren't yet apt-get'able, but I think that should happen soon.

is it buffered?

it is buffered and threaded. you can set the bugger size as specified in the readanysf-help.pd file.

-a.

...

libaudiofile is not much different from the more common libsndfile. Both only read "uncompressed" formats.

Not quite right. libsndfile file reads a number of compressed formats such as WAV and AIFF files (containing A-law, u-law, GSM 6.10, IMA ADPCM, MS ADPCM and some G7xx formats) was well as FLAC and Ogg/Vorbis.

Erik (main libsndfile author)

yes, that is why I put uncompressed in "quote,unquotes".

sorry for any confusion.

-a.

...

I think you will see gavl/gmerlin become more standard in the future. Lumiera, the new video editing software from the cinelerra-cv folks, is based on it.

and Gem :-)

ah, this is good news (for the gavl advocates at least). Are you planning on using it just in linux then? Or, are you looking to make builds for mac and win as well?

-a.

On Apr 30, 2009, at 8:46 AM, IOhannes m zmoelnig wrote:

august wrote:

...

ah, this is good news (for the gavl advocates at least). Are you
planning on using it just in linux then? Or, are you looking to make builds for mac and
win as well?

well, i'm planning to use it on every platform that supports it :-) currently i don't have any plans (nor time to invest), to make gavl/ gmerlin work on anything it doesn't already work on (e.g. i will not
port gavl to w32) since Gem uses QuckTime on both w32 and osx, i (from my Gem pov)
don't see a big need for having gavl on other systems than linux...

I don't know gavl, but it if it is close to as good as vlc/mplayer/ ffmpeg for reading codecs, it would be an improvement over Quicktime.
gavl is already in macports so making a fink package should be easy,
then it could be part of the nightly builds.

What about using ffmpeg for something like readanysf~? Its much more
widely deployed, its even on Windows.

Another option is to check in a version of gavl and the related
packages to the pure-data SVN and have it build the library then build
readanysf~. Since gavl/gmerlin is not fully packaged on any platform,
I think this makes sense.

.hc

If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess himself
of it. - Thomas Jefferson

On Apr 30, 2009, at 1:14 PM, august wrote:

...

I don't know gavl, but it if it is close to as good as vlc/mplayer/ ffmpeg for reading codecs, it would be an improvement over Quicktime.

it is very close to vlc/mplayer/ffmpeg. in fact, it might even read more formats depending on what options you compile in.

...

gavl is already in macports so making a fink package should be easy, then it could be part of the nightly builds.

What about using ffmpeg for something like readanysf~? Its much more widely deployed, its even on Windows.

the gavl/gmerlin_avdecoder combo uses libavcodec and libavformat from ffmpeg (as does mplayer) to play a lot of encoded audio/video streams. In addition to that, (like mplayer and I assuem VLC) it links in other libs to decode even more types of audio/video streams.

...

Another option is to check in a version of gavl and the related packages to the pure-data SVN and have it build the library then
build readanysf~. Since gavl/gmerlin is not fully packaged on any
platform, I think this makes sense.

yes, and AFAIK the gavl package in debian is already over a year old
and is not compatible with readanysf~.

I forgot to mention, the list of libs installed on the MinGW build
machine is here:

http://puredata.info/docs/developer/mingw

It is possible to add more. Basically, you need to import the sources
into the 'pure-data/sources' tree in pure-data SVN. That's the tree
for the MinGW setup. You can check the import-tarball.sh script to
see the process for importing a tarball there. When adding libs, the
build-libs-on-mingw.sh script should build and install everything
needed.

And lastly, on Windows, its best to do SVN operations in Cygwin via
ssh, then run builds using MinGW via rdesktop.

.hc

-a.

Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith

On Apr 30, 2009, at 3:35 PM, zmoelnig@iem.at wrote:

Quoting august august@alien.mur.at:

...

...

I don't know gavl, but it if it is close to as good as vlc/mplayer/ ffmpeg for reading codecs, it would be an improvement over
Quicktime.

you mean "QuickTime" or "libquicktime" (4linux)?

as a matter of fact, the author of gavl/gmerlin is also the author
of libquicktime (after the fork from heroinewarrior)

I mean Apple Quicktime. VLC and mplayer are already much better for
playing movies than Quicktime on Mac OS X so it would be nice if Gem
on Mac OS X took advantage of that.

...

it is very close to vlc/mplayer/ffmpeg. in fact, it might even read more formats depending on what options you compile in.

...

gavl is already in macports so making a fink package should be easy, then it could be part of the nightly builds.

What about using ffmpeg for something like readanysf~? Its much
more widely deployed, its even on Windows.

gavl/gmerlin is designed as a stable API that uses a number of
available backends. writing code for ffmpeg is a nightmare. the API changes every week. writing code for gavl/gmerlin is simple. the ffmpeg-nightmare is
delegated to a single-point: gavl.

Ah ok, alles klar, makes sense.

...

...

Another option is to check in a version of gavl and the related packages to the pure-data SVN and have it build the library then
build readanysf~. Since gavl/gmerlin is not fully packaged on any
platform, I think this makes sense.

yes, and AFAIK the gavl package in debian is already over a year
old and is not compatible with readanysf~.

i hope that gavl/gmerlin will be included in (more) distros soon

In the meantime, I think it would be worth it to have gavl/gmerlin
build out of the pure-data SVN. Then we can remove it once its widely
packaged.

.hc

fgsdmr IOhannes

---

This message was sent using IMP, the Internet Messaging Program.

<mime-attachment>

I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup

On Apr 30, 2009, at 7:19 PM, august wrote:

...

...

i hope that gavl/gmerlin will be included in (more) distros soon

In the meantime, I think it would be worth it to have gavl/gmerlin build out of the pure-data SVN. Then we can remove it once its
widely packaged.

.hc

what exactly does that mean? Do you mean compiling it in statically? Or, do you mean compiling and installing the libraries? If you mean statically, I'm not sure, but I think it will be difficult since it is gmerlin based on a plugin architecture of shared objects.

-a

Static is one option, but not the only. You can also compile it as a
dynamic lib and included it with the external. That makes it harder
to distribute though. With Windows and Mac OS X distros of Pd- extended, there are many included dynamic libs. If there were fink
packages for gmerlin/gavl then this happens automatically as part of
the build system.

Basically what I mean in something like this:

externals/readanysf externals/readanysf/readanysf~.c externals/readanysf/gavl externals/readanysf/gmerlin

Then in the Makefile for readanysf, build gavl and gmerlin, then use
something like "-I./gavl -I./gmerlin" for CFLAGS and "-L./gavl -L./ gmerlin" for LDFLAGS. Using automake would make that process easier.
Then whereever the readanysf~.pd_linux is, the .so would be included
(or .pd_darwin/.dylib, or .dll/dll).

.hc

"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you." - Richard M. Stallman

On May 1, 2009, at 3:12 AM, august wrote:

...

...

what exactly does that mean? Do you mean compiling it in
statically? Or, do you mean compiling and installing the libraries? If you mean statically, I'm not sure, but I think it will be difficult since
it is gmerlin based on a plugin architecture of shared objects.

-a

Static is one option, but not the only. You can also compile it as a dynamic lib and included it with the external. That makes it harder to distribute though. With Windows and Mac OS X distros of Pd- extended, there are many included dynamic libs. If there were fink packages for gmerlin/gavl then this happens automatically as part of the build system.

Basically what I mean in something like this:

externals/readanysf externals/readanysf/readanysf~.c externals/readanysf/gavl externals/readanysf/gmerlin

Then in the Makefile for readanysf, build gavl and gmerlin, then use something like "-I./gavl -I./gmerlin" for CFLAGS and "-L./gavl -L./ gmerlin" for LDFLAGS. Using automake would make that process easier. Then whereever the readanysf~.pd_linux is, the .so would be included (or .pd_darwin/.dylib, or .dll/dll).

I'm not sure it can work like that. For one, and correct me if I am wrong...cause I am certainly not the master of dynamic linking, but
just because you compile an app with -L/gavl doesn't mean your system
will be able to load that needed dynamic library with the app. You need to
tell the system that the dynamic library is somewhere where it can find it. The second problem is that the gmerlin_avdecode library itself is
based on dynamic object plugins (one for madlib, one for theora, etc.) and those object need to be in a findable place as well.

please correct me if I am missing something about how you are
packaging PD. Is there a folder somewhere that you are installing shared libs
that are used by pd or externals?

This kind of thing various a lot by platform:

• Windows will use .dlls in ".", it will also look in the same folder

as the pd.exe. With the Pd-extended installer, the dlls can be
installed and managed in the "system32" folder too.

• I think GNU/Linux can also look in "." for .so files, but I haven't

really tried much because I haven't had too, I just statically link,
or use packaged libraries there.

• Mac OS X is the hardest. The .dylibs need to have their path coded

in them. I don't think "." will work, but it might. In Pd-extended,
I wrote a script that looks for Fink libs (based on the /sw base path)
then it copies them into the Pd-extended.app/Contents/lib and rewrites
their path using the @executable_path variable that allows some kind
of relative path. This is fully automated for years now, so I think
making fink packages for this stuff will be the easiest path on Mac OS
X. But it would be good to figure out how to automatically
load .dylibs from '.' so they can be included in any standalone
libdirs. By the way, libquicktime also has plugins, but they are also
included in the Pd-extended.app package. That required setting an
envvar with the location.

After writing all that, I am thinking that linking everything
statically on all platforms is probably going to be the easiest thing
to do for now... it would be the same makefile, more or less, on all
platforms. The dynamic lib stuff will all be totally different on
each platform.

.hc

"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White

...

yes, and AFAIK the gavl package in debian is already over a year old and is not compatible with readanysf~.

while the former is true, is the latter also true? iirc, i can compile Gem against both the debian-package and my cvs
checkout of gmerlin (though i haven't followed changes in the last
month or so)

yes, it is true. I made some contributions to gavl last August/September that allows you change the samplerate on the fly.

new packages that include this change have not yet been made.

On Thu, Apr 30, 2009 at 12:09 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:

errordeveloper@gmail.com wrote:

...

hi

well ..that sounds brilliant - but why is it dependent on some 'gavl' ??

hmm, that's interesting as a hard dependency on gavl makes readanysf~ be pretty much linux only at the moment (despite of what is discussed on other lists...)

Yeah, indeed. I was very excited about readanysf~ as I'd huuugely like to be able to load and manipulate MP3s from my library into Pd (I'm quite shocked that this is impossible without manually decoding them outside of Pd right now :O )

Thus I spent a good 4 or 5 hours trying to get gavl/gmerlin_avdec to compile on OS X a few weeks ago with a result of very frustrating failure...

Here's hoping that changes one day : | If anyone else is up for working on it together I'd happily put in some more time just so that my hours thus far don't go to waste! Best Luke

anyhow, Gem's HEAD has currently a soft dependency on gavl (and gmerlin_avdec) as well, so it is a must anyhow :-)

fgmadsr IOhannes

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Pd crash if Readanysf is asked to play before Pd dsp is turned on. Once turned on, dsp can be turned back off without crash when readanysf is asked to play.

thanks again for the report.

the new version 0.35 should handle this correctly now. was a stupid mistake.

download here:

http://aug.ment.org/software/readanysf~0.35.tar.gz

When openning a new soundfile, the previous if any, is not closed properly. The memory is not freed and the whole thing crash.

hmm. I think this was a bug I fixed from an older version. Can you try the latest version now and let me know if you still experience this problem?

-august.

...

...

When openning a new soundfile, the previous if any, is not closed properly. The memory is not freed and the whole thing crash.

hmm. I think this was a bug I fixed from an older version. Can you try the latest version now and let me know if you still experience this problem?

-august.

Still the same with the latest version. Each time a sound file is opened the memory use by Pd increase.

for the record previous and now fixed reported bugs were against version 0.33 and not 0.30 as indicated by mistake in the subject.

Thanks for readanysf~ !

my pleasure....hope it is useful.

please see here for the memory leak fix:

http://aug.ment.org/readanysf/download.php

it's still leaking a little bit, but I don't think it is due to my code. It should be much better now. Please let me know how it seems.

-august.

Yo august - I'm working on a variant of the anysndfiler patch you included that can function as a drop-in replacement for soundfiler. I'm experiencing some weirdness though - it seems to work ~50% of the time but the other times it hard-locks my system and spits out "couldn't get a frame" messages to the console (with syslogd taking up most of my CPU).

I'm generally opening MP3 files from my collection. Printing the "time so far" message, it seems to hang at some period and just stick there (e.g. 40s).

Let me know if I can provide any other info - I'll see what else I can figure out in the meantime.

Patches attached... I'm super excited to be so close to having this : ) Thanks again for your work on it thus far! Best Luke

On Sun, May 24, 2009 at 4:45 PM, joel silvestre j.silvestre@wanadoo.fr wrote:

...

please see here for the memory leak fix:

http://aug.ment.org/readanysf/download.php

it's still leaking a little bit, but I don't think it is due to my code. It should be much better now.  Please let me know how it seems.

-august.

Yes it's much better! And opening a sound file doesn't give any audio dropouts anymore Wonderfull!

Thank's a lot.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

hi august,

a very little bug: the length of file is outputed as an int number, nothing after the decimal point.

Line 252 in Readsf.cpp is : return (float)(gavl_time_to_samples( input_audio_format.samplerate, t) / input_audio_format.samplerate);

and if I'm not wrong, should be something like : return (float)(gavl_time_to_samples( input_audio_format.samplerate, t) / (float) input_audio_format.samplerate);

thanks for the bug report.

I see you are using an older version. I caught that bug a little while ago.

"Length in second that have been played so far" is updated every 1000 dsp blocks. I think it's to much. Loops and events triggering will benefit a lot of a higher timing resolution, maybe a single dsp block.

the new readanysf~, available here - http://aug.ment.org/readanysf/download.php - is able to take a "tick" message to set how often to send out the cache and length info.

"tick 1" will send it every dsp cycle.

"tick 1000" will send it every 1000 cycles. this is good for people who don't need that kind of resolution. it can eat cpu if you are showing it in a number box or something.

-august.