[PD] readanysf~ v0.30
hallo, I made some major bug fixes to my readanysf~ external. readanysf~ is a puredata external for reading many file formats from your hard disk or via network. please check it out. http://aug.ment.org/readanysf -august. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
hi, is it possible to use it as something like soundfiler that can handle mp3-files (write the samples to a table not in realtime and not upsampled)? or is something like that out there? g. august schrieb: hallo, I made some major bug fixes to my readanysf~ external. readanysf~ is a puredata external for reading many file formats from your hard disk or via network. please check it out. http://aug.ment.org/readanysf -august. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
hi well ..that sounds brilliant - but why is it dependent on some 'gavl' ?? not something more common, like libaudiofile, for example?? is it buffered? On Wed, Apr 29, 2009 at 03:41:46AM +0200, august wrote: > > > hallo, > > > I made some major bug fixes to my readanysf~ external. > readanysf~ is a puredata external for reading many file formats from > your hard disk or via network. > > please check it out. > > > http://aug.ment.org/readanysf > > > > -august. > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
Yeah, an [anysoundfiler] would be super handy. .hc On Apr 29, 2009, at 1:24 PM, errordevelo...@gmail.com wrote: hi well ..that sounds brilliant - but why is it dependent on some 'gavl' ?? not something more common, like libaudiofile, for example?? is it buffered? On Wed, Apr 29, 2009 at 03:41:46AM +0200, august wrote: hallo, I made some major bug fixes to my readanysf~ external. readanysf~ is a puredata external for reading many file formats from your hard disk or via network. please check it out. http://aug.ment.org/readanysf -august. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> hi, > > is it possible to use it as something like soundfiler that can handle > mp3-files (write the samples to a table not in realtime and not > upsampled)? or is something like that out there? > g. > if it is not out there already, I could probably whip it together rather soon. -a. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> 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 filesmp3, 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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
august wrote: > 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) -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> > 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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
errordevelo...@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...) anyhow, Gem's HEAD has currently a soft dependency on gavl (and gmerlin_avdec) as well, so it is a must anyhow :-) fgmadsr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
august wrote: hi gavl is a really brilliant low-level library which handles the details of audio and video formats like colorspaces, samplerates, multichannel configurations etc. i basically agree. and it is super simple. it took me two days during(!) piksel (while drinking beer and stuff) to hear of gavl/gmerlin and implement support for it in Gem. gmerlin_avdecode uses gavl to deliver frames of audio and video (including conversions and resampling). It can decode all kinds of media filesmp3, 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. for me, gstreamer and gmerlin do not directly compete. while both claim to be "multimedia frameworks", the former is hard to interface on the data-level from a host application; however pipelines (within the gst-framework) are highly optimized and do not require much thinking of the host-programmes authors. otoh, gmerlin is a straighforward API to read data from a media-stream into your host application (writing is possible but more complicated) 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 :-) It IS unfortunate that they aren't yet apt-get'able, but I think that should happen soon. gavl itself has been packaged into debian since etch. unfrotunately gavl is just the interface that defines how frames of data look like, whereas the actual decoding library is in a a package called gmerlin_avdec, which is _not_ in proper debian. however, it is available through debian-multimedia by christian marillat. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
On Thu, Apr 30, 2009 at 12:09 AM, IOhannes m zmoelnig wrote: > errordevelo...@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-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> >> 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! Luke, I'd be willing to help...but I need access to a osx box with gcc and build tools. Where did you leave off? -a ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> >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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
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... ghmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> 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~. -a. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
Quoting august : 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) 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. 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 fgsdmr IOhannes This message was sent using IMP, the Internet Messaging Program. binb3a2rFdYwd.bin Description: Öffentlicher PGP-Schlüssel ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
Quoting august : 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) fgamsdr IOhannes This message was sent using IMP, the Internet Messaging Program. binRELeBUSHCz.bin Description: Öffentlicher PGP-Schlüssel ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> >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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
On Apr 30, 2009, at 10:16 AM, Frank Barknecht wrote: 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. It was not easy to find after all, there were few hits for oggfiler out there, But here it is: http://lists.puredata.info/pipermail/pd-list/2009-02/068050.html .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
On Apr 30, 2009, at 3:35 PM, zmoel...@iem.at wrote: Quoting august : 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. 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> >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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> >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? -a. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
Le mercredi 29 avril 2009 à 03:41 +0200, august a écrit : > > > hallo, > > > I made some major bug fixes to my readanysf~ external. > readanysf~ is a puredata external for reading many file formats from > your hard disk or via network. > > please check it out. > > > http://aug.ment.org/readanysf > > > > -august. 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); "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. All the best. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
Le mercredi 20 mai 2009 à 18:01 +0200, joel silvestre a écrit : > Le mercredi 29 avril 2009 à 03:41 +0200, august a écrit : > > > > > > hallo, > > > > > > I made some major bug fixes to my readanysf~ external. > > readanysf~ is a puredata external for reading many file formats from > > your hard disk or via network. > > > > please check it out. > > > > > > http://aug.ment.org/readanysf > > > > > > > > -august. > > Two new bugs: 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. When openning a new soundfile, the previous if any, is not closed properly. The memory is not freed and the whole thing crash. All the best ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> 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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> 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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> > 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~ ! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> > > 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 pleasurehope 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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30
> 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
Re: [PD] readanysf~ v0.30
> 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! cool. I'm really glad if it is useful for some people. I was just messing around with that anysndfiler patch one night to see what might be needed for such a thing. So, it is hardly complete. I looked at your patch briefly and one thing that comes to attention immediately is the resampling switch~ statement. Because readanysf~ reads from unpredictable things like your hard disk or the internet, it can never really know for sure if it will receive the intended amount of audio samples every dsp block. So, what I do is, instead of blocking the dsp call and hearing a click, I fill the missing audio samples with zeros. When you apply the switch~ statement that runs that subpatch at a higher frequency than the main pd patch, it could happen that you attempt read faster than what your computer can read and decode from your harddrive. And, this is what is happening when you see a "couldn't get a frame" message. It means readanysf~'s internal buffer is empty and needs time to fill the buffer. Every time you see that message, you can be sure that your audio has been "corrupted" with zeros. If you get rid of the loadbang to the switch statement in the patch, what happens then? It should work much better. I'm not sure, but I think what is needed here is a blocking, non-threading readanysf~ to make it work properly. I might be able to look more into this later. best -august. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] readanysf~ v0.30 // install problem
hi august i'm trying to use readanysf~ but i get the following error in the pd console: /usr/lib/pd/extra/readanysf~.pd_linux: libgavl.so.1: cannot open shared object file: No such file or directory readanysf~ ... couldn't create any idea what this could refer to? thanks. jason ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30 // install problem
j...@jasonkahn.net wrote: /usr/lib/pd/extra/readanysf~.pd_linux: libgavl.so.1: cannot open shared object file: No such file or directory readanysf~ ... couldn't create any idea what this could refer to? it refers to an external library (gavl) missing onn your system even though readanysf~ depends on it. you have to install this library. fgnasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] readanysf~ v0.30 // install problem
hi johannes thanks for your reply. /usr/lib/pd/extra/readanysf~.pd_linux: libgavl.so.1: cannot open shared object file: No such file or directory readanysf~ ... couldn't create any idea what this could refer to? it refers to an external library (gavl) missing onn your system even though readanysf~ depends on it. you have to install this library. here the answer from august: create a file /etc/ld.so.conf.d/local.conf and put "/usr/local/lib/" in there. then run "sudo ldconfig" to update the library search path. this worked for me. jason ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
