Hey August,
I'm really enjoying readanysf~, its been doing a good job of playing
streams, movies, audio files, etc. The original .mov files that were
crashing Pd no longer do, they give me this text to the Pd window
instead. I don't know what kind of feedback you get from gavl, but I
think it would be really useful if there were separate error/warning
messages for "still buffering" of a stream versus the "unsupported
codec" from these movies. Here's the current text:
Current file is either invalid or still starting. 0
This probably means that it is a stream and it needs to buffer in from
the network.
Also, I found a new movie that crashes things. It plays in VLC and
mplayer, so maybe its a separate issue:
http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
.hc
There is no way to peace, peace is the way. -A.J. Muste
Hey August,
I'm really enjoying readanysf~, its been doing a good job of playing
streams, movies, audio files, etc. The original .mov files that were
crashing Pd no longer do, they give me this text to the Pd window
instead. I don't know what kind of feedback you get from gavl, but I
think it would be really useful if there were separate error/warning
messages for "still buffering" of a stream versus the "unsupported
codec" from these movies. Here's the current text:Current file is either invalid or still starting. 0 This probably means that it is a stream and it needs to buffer in from
the network.
current 0.35 version should give a more accurate feedback.
Also, I found a new movie that crashes things. It plays in VLC and
mplayer, so maybe its a separate issue:http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
I sent this along to the gmerlin developer. he's usually really quick with fixes like this.
-a.
Also, I found a new movie that crashes things. It plays in VLC and
mplayer, so maybe its a separate issue:http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
fixed in latest CVS for gmerlin_avdecoder.
On May 22, 2009, at 8:24 AM, august wrote:
Also, I found a new movie that crashes things. It plays in VLC and mplayer, so maybe its a separate issue:
http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
fixed in latest CVS for gmerlin_avdecoder.
Excellent! Do you know if there are plans for a gmerlin_avdecoder
release any time soon? That will make the Fink/Mac OS X packaging a
lot easier. It might make it more likely that the Debian/Multimedia
package gets updated too.
.hc
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Also, I found a new movie that crashes things. It plays in VLC and mplayer, so maybe its a separate issue:
http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
fixed in latest CVS for gmerlin_avdecoder.
Excellent! Do you know if there are plans for a gmerlin_avdecoder
release any time soon? That will make the Fink/Mac OS X packaging a lot easier. It might make it more likely that the Debian/Multimedia package gets updated too.
I don't think there are any plans to make a release any time soon. leider.
On May 22, 2009, at 3:05 PM, august wrote:
Also, I found a new movie that crashes things. It plays in VLC and mplayer, so maybe its a separate issue:
http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
fixed in latest CVS for gmerlin_avdecoder.
Excellent! Do you know if there are plans for a gmerlin_avdecoder release any time soon? That will make the Fink/Mac OS X packaging
a lot easier. It might make it more likely that the Debian/Multimedia
package gets updated too.I don't think there are any plans to make a release any time soon. leider.
Hmm, I think its probably best to then to check the avdec sources into
the same folder as readanysf~ and build it from there. Its not
included in Debian, Ubuntu, or Fedora. Then once it is included, that
source can be removed. The rest of the dependencies are in Debian,
Ubuntu, Fedora, and Fink, I think, so they can be used that way.
.hc
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
mplayer, so maybe its a separate issue:
http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
fixed in latest CVS for gmerlin_avdecoder.
Excellent! Do you know if there are plans for a gmerlin_avdecoder release any time soon? That will make the Fink/Mac OS X packaging a lot easier. It might make it more likely that the Debian/Multimedia
package gets updated too.I don't think there are any plans to make a release any time soon. leider.
Hmm, I think its probably best to then to check the avdec sources into
the same folder as readanysf~ and build it from there. Its not included in Debian, Ubuntu, or Fedora. Then once it is included, that source can be removed. The rest of the dependencies are in Debian, Ubuntu, Fedora, and Fink, I think, so they can be used that way.
What would be the advantage of doing that?
we just put in a lot of effort to make the fink packages...and they should work just fine. why don't we keep it like it is and not do extra work, extra svn magic. the latest commits to gmerlin_avdec will be released soon enough.
also, debian users can use debian packages from http://debian-multimedia.org
or better yet, how about making a package for Mac and win that includes the linked libraries as binaries? Or, do you want to make a giant static build? I still don't understand how the binary packages are made on mac and win.
-a.
On May 22, 2009, at 6:11 PM, august wrote:
mplayer, so maybe its a separate issue:
http://eds.org/~hans/MadagascarInstituteDeathRattler_short.mov
fixed in latest CVS for gmerlin_avdecoder.
Excellent! Do you know if there are plans for a gmerlin_avdecoder release any time soon? That will make the Fink/Mac OS X
packaging a lot easier. It might make it more likely that the Debian/Multimedia package gets updated too.I don't think there are any plans to make a release any time soon. leider.
Hmm, I think its probably best to then to check the avdec sources
into the same folder as readanysf~ and build it from there. Its not
included in Debian, Ubuntu, or Fedora. Then once it is included, that
source can be removed. The rest of the dependencies are in Debian, Ubuntu,
Fedora, and Fink, I think, so they can be used that way.What would be the advantage of doing that?
we just put in a lot of effort to make the fink packages...and they should work just fine. why don't we keep it like it is and not do extra work, extra svn magic. the latest commits to gmerlin_avdec will be released soon enough.
also, debian users can use debian packages from http://debian-multimedia.org
or better yet, how about making a package for Mac and win that
includes the linked libraries as binaries? Or, do you want to make a giant static build? I still don't understand how the binary packages are made on mac and win.
We could check the CVS code into the 'sources' and build that for
Windows, and we could also make a Fink package based on a CVS
tarball. But then we'd be without avdec packages for Fedora and
Ubuntu, and Debian users would be required to setup Debian Multimedia
to use Pd-extended. And the Debian Multimedia packages wouldn't have
the movie crasher bug fix either.
So for about the same work as importing the source code and building
it for Windows, we can have the most recent avdec on all platforms.
Then once there is another release of avdec, I'll happily update the
Fink package. And once avdec makes it into Debian, Ubuntu and Fedora,
we can use it there.
From my experience, the easiest path to supporting readanysf~ on all
of the Pd-extended platforms would be to import the avdec code into
the pure-data SVN and then set it up to build there. That is, unless
IOhannes wants to deploy Gem using gmerlin_avdec sooner rather than
later. That might change things somewhat. But then it might be
easier to use the old "GemLibs" style of including an external lib.
.hc
There is no way to peace, peace is the way. -A.J. Muste
hi
Hans-Christoph Steiner wrote:
From my experience, the easiest path to supporting readanysf~ on all of the Pd-extended platforms would be to import the avdec code into the pure-data SVN and then set it up to build there. That is, unless IOhannes wants to deploy Gem using gmerlin_avdec sooner rather than later. That might change things somewhat. But then it might be easier to use the old "GemLibs" style of including an external lib.
hmm, i cannot entirely follow here.
my point has always been quite clear, that i do not especially like the idea putting every single line of source we can get our hands on and which some piece of software eventually included by Pd-extended depends on into the repository.
i'd purge GemLibs alltogether rather sooner than later (afaik it is currently entirely dysfunctional; but you never know and that is the main reason why it is still there...) and instead revive the idea of providing GemLib-packages with pre-compiled binaries of the dependencies.
finally, i was wondering what i have to do in order to use gmerlin_avdec in Gem (which has not been yet done; i suppose you did not break the entire code-base on your way to porting it to osx/w32 ;-))
fgamdr IOhannes
On May 23, 2009, at 4:51 AM, IOhannes m zmoelnig wrote:
hi
Hans-Christoph Steiner wrote:
From my experience, the easiest path to supporting readanysf~ on
all of the Pd-extended platforms would be to import the avdec code into the pure-data SVN and then set it up to build there. That is, unless IOhannes wants to deploy Gem using gmerlin_avdec sooner rather than later. That might change things somewhat. But then it might be
easier to use the old "GemLibs" style of including an external lib.hmm, i cannot entirely follow here.
my point has always been quite clear, that i do not especially like
the idea putting every single line of source we can get our hands on and which some piece of software eventually included by Pd-extended
depends on into the repository.
i'd purge GemLibs alltogether rather sooner than later (afaik it is currently entirely dysfunctional; but you never know and that is the main reason why it is still there...) and instead revive the idea of providing GemLib-packages with pre-compiled binaries of the
dependencies.
I am suggesting managing the avdec source code in our SVN, not
binaries. That's what I thought GemLibs was for. I agree managing
binaries in SVN is not a very good idea as a general practice. That
said, I feel I must reiterate: SVN is a very useful tool for managing
source code, and that's what we are talking about. Package management
is also, but there isn't package management for Windows and avdec
isn't in Debian, Ubuntu or Fedora. The SVN developers think that
importing other source code into your own SVN is useful enough to
devote a whole chapter to it, as well as specialized tools:
http://svnbook.red-bean.com/en/1.1/ch07s05.html
CVS also has similar documentation: http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_13.html
For the build farm, I am currently managing 3 Debian boxes, 2 Ubuntu
boxes, a Fedora box, 3 Mac OS X boxes, and a Windows box. I maintain
Pd packages for Debian/Ubuntu, Mac OS X and Windows. I am a
contributor to the Fink distribution. I have also built custom WRT
firmwares using the EWRT, which has lots of imported source code.
Bottom line, I have seen, worked with, and used many different
techniques for managing code. IMHO based on this experience, I think
that it will be the least work to import avdec into our SVN and use it
from there until it is in the package management of the supported
platforms.
Can we put this issue of importing source code to rest? This is
standard, very common, and indeed a very labor saving practice.
finally, i was wondering what i have to do in order to use
gmerlin_avdec in Gem (which has not been yet done; i suppose you did not break the entire code-base on your way to porting it to osx/w32 ;-))
Its installed on the Mac OS X build farm machines already. We are
working on getting into the Windows build machine.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Hans-Christoph Steiner wrote:
my point has always been quite clear, that i do not especially like the idea putting every single line of source we can get our hands on and which some piece of software eventually included by Pd-extended depends on into the repository.
i'd purge GemLibs alltogether rather sooner than later (afaik it is currently entirely dysfunctional; but you never know and that is the main reason why it is still there...) and instead revive the idea of providing GemLib-packages with pre-compiled binaries of the dependencies.
I am suggesting managing the avdec source code in our SVN, not binaries. That's what I thought GemLibs was for.
yes, that what GemLib is/was for and and i still want to get rid of the pd-gem svn part of GemLib.
I agree managing binaries in SVN is not a very good idea as a general practice.
yes, i guess we are totally in accordance here.
That said, I feel I must reiterate: SVN is a very useful tool for managing source code, and that's what we are talking about.
indeed.
I am
[...]
I have
[...]
Bottom line, I have
[...]
i have (and had) no intention to question your qualifications. sorry if i sound a bit mr.know-it-all.
I think that it will be the least work to import avdec into our SVN and use it from there until it is in the package management of the supported platforms.
Can we put this issue of importing source code to rest? This is standard, very common, and indeed a very labor saving practice.
please hold on. i thought you was asking people (including me) for their opinion. if you don't care about aberrant opinions, then please don't ask.
i was always joking about "putting the linux-kernel into the /sources section, since the entire linux-part of Pd-extended certainly depends on the kernel". this punchline of this joke was of course, that the linux-kernel is rather big compared to the entire Pd-extended source-base, and that this practice tends to include the entire world, which i think is a waste of ressources (probably a european green attitude). i am shocked, that the punchline no longer holds: the current /source folder holds about 322 Megabyte (without any revisions or such) of sources which have absolutely nothing to do with Pd (in a sense that probably none of the main developers of any of the included packages have ever heard of Pure data)
the linux sources for 2.6.26 (with all debian patches applied) is about 317MB...
finally, i was wondering what i have to do in order to use gmerlin_avdec in Gem (which has not been yet done; i suppose you did not break the entire code-base on your way to porting it to osx/w32 ;-))
Its installed on the Mac OS X build farm machines already. We are working on getting into the Windows build machine.
ah i see. so it's mainly about getting Gem compiling on w32 with gcc/autotools. this reminds me: sorry that i was unable to attend the mingw hack party on IRC; i had forgotten that i had another long-planned date...
gmsadft IOhannes
On May 24, 2009, at 3:54 PM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
my point has always been quite clear, that i do not especially
like the idea putting every single line of source we can get our hands on and which some piece of software eventually included by Pd-extended
depends on into the repository. i'd purge GemLibs alltogether rather sooner than later (afaik it is currently entirely dysfunctional; but you never know and that is the main reason why it is still there...) and instead revive the idea of providing GemLib-packages with pre-compiled binaries of the
dependencies.I am suggesting managing the avdec source code in our SVN, not
binaries. That's what I thought GemLibs was for.yes, that what GemLib is/was for and and i still want to get rid of
the pd-gem svn part of GemLib.I agree managing binaries in SVN is not a very good idea as a
general practice.yes, i guess we are totally in accordance here.
That said, I feel I must reiterate: SVN is a very useful tool for
managing source code, and that's what we are talking about.indeed.
I am
[...]
I have
[...]
Bottom line, I have
[...]
i have (and had) no intention to question your qualifications. sorry if i sound a bit mr.know-it-all.
I think that it will be the least work to import avdec into our SVN
and use it from there until it is in the package management of the
supported platforms. Can we put this issue of importing source code to rest? This is
standard, very common, and indeed a very labor saving practice.please hold on. i thought you was asking people (including me) for their opinion. if you don't care about aberrant opinions, then please don't ask.
i was always joking about "putting the linux-kernel into the / sources section, since the entire linux-part of Pd-extended
certainly depends on the kernel". this punchline of this joke was of course, that the linux-kernel is
rather big compared to the entire Pd-extended source-base, and that
this practice tends to include the entire world, which i think is a
waste of ressources (probably a european green attitude). i am shocked, that the punchline no longer holds: the current / source folder holds about 322 Megabyte (without any revisions or
such) of sources which have absolutely nothing to do with Pd (in a
sense that probably none of the main developers of any of the
included packages have ever heard of Pure data)the linux sources for 2.6.26 (with all debian patches applied) is
about 317MB...finally, i was wondering what i have to do in order to use
gmerlin_avdec in Gem (which has not been yet done; i suppose you did not break the entire code-base on your way to porting it to osx/w32 ;-))Its installed on the Mac OS X build farm machines already. We are
working on getting into the Windows build machine.ah i see. so it's mainly about getting Gem compiling on w32 with gcc/ autotools. this reminds me: sorry that i was unable to attend the mingw hack
party on IRC; i had forgotten that i had another long-planned date...
Jokes are all fine and good, I guess I was being too earnest. I was
trying to have a productive conversation. So we both just spent a
fair amount of time on this discussion and as far as I can tell, we
are not any closer a solution for managing gmerlin-avdec.
So, anyone have any specific objections about how importing gmerlin-
avdec code into the pure-data SVN might cause harm? Or any better
solutions for managing gmerlin-avdec?
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
Hans-Christoph Steiner wrote:
my point has always been quite clear, that i do not especially like the idea putting every single line of source we can get our hands on and which some piece of software eventually included by Pd-extended depends on into the repository.
i'd purge GemLibs alltogether rather sooner than later (afaik it is currently entirely dysfunctional; but you never know and that is the main reason why it is still there...) and instead revive the idea of providing GemLib-packages with pre-compiled binaries of the dependencies.
I am suggesting managing the avdec source code in our SVN, not binaries. That's what I thought GemLibs was for.
yes, that what GemLib is/was for and and i still want to get rid of the pd-gem svn part of GemLib.
I agree managing binaries in SVN is not a very good idea as a general practice.
yes, i guess we are totally in accordance here.
That said, I feel I must reiterate: SVN is a very useful tool for managing source code, and that's what we are talking about.
indeed.
I am
[...]
I have
[...]
Bottom line, I have
[...]
i have (and had) no intention to question your qualifications. sorry if i sound a bit mr.know-it-all.
I think that it will be the least work to import avdec into our SVN and use it from there until it is in the package management of the supported platforms.
Can we put this issue of importing source code to rest? This is standard, very common, and indeed a very labor saving practice.
please hold on. i thought you was asking people (including me) for their opinion. if you don't care about aberrant opinions, then please don't ask.
i was always joking about "putting the linux-kernel into the /sources section, since the entire linux-part of Pd-extended certainly depends on the kernel". this punchline of this joke was of course, that the linux-kernel is rather big compared to the entire Pd-extended source-base, and that this practice tends to include the entire world, which i think is a waste of ressources (probably a european green attitude). i am shocked, that the punchline no longer holds: the current /source folder holds about 322 Megabyte (without any revisions or such) of sources which have absolutely nothing to do with Pd (in a sense that probably none of the main developers of any of the included packages have ever heard of Pure data)
the linux sources for 2.6.26 (with all debian patches applied) is about 317MB...
finally, i was wondering what i have to do in order to use gmerlin_avdec in Gem (which has not been yet done; i suppose you did not break the entire code-base on your way to porting it to osx/w32 ;-))
Its installed on the Mac OS X build farm machines already. We are working on getting into the Windows build machine.
ah i see. so it's mainly about getting Gem compiling on w32 with gcc/autotools. this reminds me: sorry that i was unable to attend the mingw hack party on IRC; i had forgotten that i had another long-planned date...
gmsadft IOhannes