Re: [PD] graph on parent problem?
If I understood your problem correctly, this might be because pd redraws array contents very inefficiently, so if you are constantly changing array contents that can prove quite cpu intensive. I don't think that is the problem - I'm not changing the array just load it once the play from it. Thanks Oded ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use extensions .l_i386 and .l_ia64 for Linux externals
OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will. Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd. I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs. Katja On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner h...@at.or.atwrote: Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them. I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way. .hc On Dec 7, 2012, at 6:50 PM, katja wrote: Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux. I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd? Thanks, Katja ___ 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] pd~ for MAX/MSP - is it for real?
I could not get it to run in version 5 either. AFAIK pd~ was developed when Max was at version 4.something Also it is now removed on Ted Apel's site http://crca.ucsd.edu/~tapel/software.html Am 08.12.2012 um 08:34 schrieb Alexandre Torres Porres por...@gmail.com: Hello, how's it going? Recently I thought this computer music course and told MAX users they could open Pd in it with the [pd~] object for MAX. We just couldn't make it happen. I don't have MAX, but I had tried a while ago without success either, thinking I might have been doing something wrong. Well, this time I was trying this with a few MAX users and it turns out the object doesn't really instantiate. I wonder if anyone has ever successfuly used this. I ask if it doesn't work on version 6 only. Anyway, it seems to me no one is actually tweaking and playing with Pd inside MAX. Bummer. cheers ___ 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] pd~ for MAX/MSP - is it for real?
it's at miller's page now: http://crca.ucsd.edu/%7Emsp/software.html but I think it came out when MAX 5 was around. cheers 2012/12/8 Max abonneme...@revolwear.com I could not get it to run in version 5 either. AFAIK pd~ was developed when Max was at version 4.something Also it is now removed on Ted Apel's site http://crca.ucsd.edu/~tapel/software.html Am 08.12.2012 um 08:34 schrieb Alexandre Torres Porres por...@gmail.com: Hello, how's it going? Recently I thought this computer music course and told MAX users they could open Pd in it with the [pd~] object for MAX. We just couldn't make it happen. I don't have MAX, but I had tried a while ago without success either, thinking I might have been doing something wrong. Well, this time I was trying this with a few MAX users and it turns out the object doesn't really instantiate. I wonder if anyone has ever successfuly used this. I ask if it doesn't work on version 6 only. Anyway, it seems to me no one is actually tweaking and playing with Pd inside MAX. Bummer. cheers ___ 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
[PD] Pb with readanysf compilation.
Hello,
i try compile readanyfs, on a debian squezze 64 bits, but i have an
error. I have the gmerlin and gavl library installed.
Thank's
François-Marie
Error message afet make:
mkdir objs
g++ -c -o objs/FifoVideoFrames.o src/FifoVideoFrames.cpp -I./
-I/usr/local/include -I/usr/local/include/gavl -I/usr/local/include/gmerlin
-I/usr/include -fPIC -Wall
In file included from src/FifoVideoFrames.cpp:20:
src/FifoVideoFrames.h:30:27: error: gmerlin/avdec.h: Aucun fichier ou dossier
de ce type
In file included from src/FifoVideoFrames.cpp:20:
src/FifoVideoFrames.h:36: error: ‘gavl_video_format_t’ has not been declared
src/FifoVideoFrames.h:38: error: ‘gavl_video_frame_t’ has not been declared
src/FifoVideoFrames.h:39: error: ‘gavl_video_frame_t’ has not been declared
src/FifoVideoFrames.h:47: error: ISO C++ forbids declaration of
‘gavl_video_format_t’ with no type
src/FifoVideoFrames.h:47: error: expected ‘;’ before ‘*’ token
src/FifoVideoFrames.h:55: error: ISO C++ forbids declaration of
‘gavl_video_frame_t’ with no type
src/FifoVideoFrames.h:55: error: expected ‘;’ before ‘*’ token
src/FifoVideoFrames.h:56: error: ISO C++ forbids declaration of
‘gavl_video_format_t’ with no type
src/FifoVideoFrames.h:56: error: expected ‘;’ before ‘*’ token
src/FifoVideoFrames.cpp:22: error: ‘gavl_video_format_t’ has not been declared
src/FifoVideoFrames.cpp: In constructor ‘FifoVideoFrames::FifoVideoFrames(int,
int*)’:
src/FifoVideoFrames.cpp:27: error: ‘format’ was not declared in this scope
src/FifoVideoFrames.cpp:27: error: expected type-specifier before
‘gavl_video_format_t’
src/FifoVideoFrames.cpp:27: error: expected ‘;’ before ‘gavl_video_format_t’
src/FifoVideoFrames.cpp:28: error: ‘gavl_video_format_copy’ was not declared in
this scope
src/FifoVideoFrames.cpp:29: error: ‘fifoPtr’ was not declared in this scope
src/FifoVideoFrames.cpp:29: error: expected type-specifier before
‘gavl_video_frame_t’
src/FifoVideoFrames.cpp:29: error: expected ‘;’ before ‘gavl_video_frame_t’
src/FifoVideoFrames.cpp:31: error: ‘gavl_video_frame_create’ was not declared
in this scope
src/FifoVideoFrames.cpp: In destructor ‘FifoVideoFrames::~FifoVideoFrames()’:
src/FifoVideoFrames.cpp:39: error: ‘fifoPtr’ was not declared in this scope
src/FifoVideoFrames.cpp:39: error: ‘gavl_video_frame_destroy’ was not declared
in this scope
src/FifoVideoFrames.cpp:41: error: ‘format’ was not declared in this scope
src/FifoVideoFrames.cpp:42: error: ‘fifoPtr’ was not declared in this scope
src/FifoVideoFrames.cpp: At global scope:
src/FifoVideoFrames.cpp:58: error: ‘bool FifoVideoFrames::Append’ is not a
static member of ‘class FifoVideoFrames’
src/FifoVideoFrames.cpp:58: error: ‘gavl_video_frame_t’ was not declared in
this scope
src/FifoVideoFrames.cpp:58: error: ‘source’ was not declared in this scope
src/FifoVideoFrames.cpp:58: error: expected ‘,’ or ‘;’ before ‘{’ token
make: *** [objs/FifoVideoFrames.o] Erreur 1
attachment: contact.vcf___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pb with readanysf compilation.
src/FifoVideoFrames.h:30:27: error: gmerlin/avdec.h: Aucun fichier ou dossier
de ce type
In file included from src/FifoVideoFrames.cpp:20:
You need the -dev package, I think its called libgmerlin-avdec-dev or something
like that.
.hc
On Dec 8, 2012, at 11:15 AM, contact wrote:
Hello,
i try compile readanyfs, on a debian squezze 64 bits, but i have an error. I
have the gmerlin and gavl library installed.
Thank's
François-Marie
Error message afet make:
mkdir objs
g++ -c -o objs/FifoVideoFrames.o src/FifoVideoFrames.cpp -I./
-I/usr/local/include -I/usr/local/include/gavl -I/usr/local/include/gmerlin
-I/usr/include -fPIC -Wall
In file included from src/FifoVideoFrames.cpp:20:
src/FifoVideoFrames.h:30:27: error: gmerlin/avdec.h: Aucun fichier ou
dossier de ce type
In file included from src/FifoVideoFrames.cpp:20:
src/FifoVideoFrames.h:36: error: ‘gavl_video_format_t’ has not been declared
src/FifoVideoFrames.h:38: error: ‘gavl_video_frame_t’ has not been declared
src/FifoVideoFrames.h:39: error: ‘gavl_video_frame_t’ has not been declared
src/FifoVideoFrames.h:47: error: ISO C++ forbids declaration of
‘gavl_video_format_t’ with no type
src/FifoVideoFrames.h:47: error: expected ‘;’ before ‘*’ token
src/FifoVideoFrames.h:55: error: ISO C++ forbids declaration of
‘gavl_video_frame_t’ with no type
src/FifoVideoFrames.h:55: error: expected ‘;’ before ‘*’ token
src/FifoVideoFrames.h:56: error: ISO C++ forbids declaration of
‘gavl_video_format_t’ with no type
src/FifoVideoFrames.h:56: error: expected ‘;’ before ‘*’ token
src/FifoVideoFrames.cpp:22: error: ‘gavl_video_format_t’ has not been
declared
src/FifoVideoFrames.cpp: In constructor
‘FifoVideoFrames::FifoVideoFrames(int, int*)’:
src/FifoVideoFrames.cpp:27: error: ‘format’ was not declared in this scope
src/FifoVideoFrames.cpp:27: error: expected type-specifier before
‘gavl_video_format_t’
src/FifoVideoFrames.cpp:27: error: expected ‘;’ before ‘gavl_video_format_t’
src/FifoVideoFrames.cpp:28: error: ‘gavl_video_format_copy’ was not declared
in this scope
src/FifoVideoFrames.cpp:29: error: ‘fifoPtr’ was not declared in this scope
src/FifoVideoFrames.cpp:29: error: expected type-specifier before
‘gavl_video_frame_t’
src/FifoVideoFrames.cpp:29: error: expected ‘;’ before ‘gavl_video_frame_t’
src/FifoVideoFrames.cpp:31: error: ‘gavl_video_frame_create’ was not
declared in this scope
src/FifoVideoFrames.cpp: In destructor ‘FifoVideoFrames::~FifoVideoFrames()’:
src/FifoVideoFrames.cpp:39: error: ‘fifoPtr’ was not declared in this scope
src/FifoVideoFrames.cpp:39: error: ‘gavl_video_frame_destroy’ was not
declared in this scope
src/FifoVideoFrames.cpp:41: error: ‘format’ was not declared in this scope
src/FifoVideoFrames.cpp:42: error: ‘fifoPtr’ was not declared in this scope
src/FifoVideoFrames.cpp: At global scope:
src/FifoVideoFrames.cpp:58: error: ‘bool FifoVideoFrames::Append’ is not a
static member of ‘class FifoVideoFrames’
src/FifoVideoFrames.cpp:58: error: ‘gavl_video_frame_t’ was not declared in
this scope
src/FifoVideoFrames.cpp:58: error: ‘source’ was not declared in this scope
src/FifoVideoFrames.cpp:58: error: expected ‘,’ or ‘;’ before ‘{’ token
make: *** [objs/FifoVideoFrames.o] Erreur 1
contact.vcf___
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] graph on parent problem?
On 12/08/2012 04:18 AM, Oded Ben-Tal wrote: If I understood your problem correctly, this might be because pd redraws array contents very inefficiently, so if you are constantly changing array contents that can prove quite cpu intensive. I don't think that is the problem - I'm not changing the array just load it once the play from it. Thanks Oded In that case, can you try the patch in pd-l2ork to see if it has problems there? Alternately, please post the abstraction/patch and I can test it. Also, are you experiening problems when you are moving the abstraction around canvas or at all times? -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use extensions .l_i386 and .l_ia64 for Linux externals
... or indeed, to distribute a patch with a piece of music, for example - it's best if the patch works cross-platform, and for that, any externs should be bundled with a variety of compiled versions, which then need individual filenames. I think in general, if you're distributing software, compiling it specificly and separately for different platforms (as is Pd extended) is the best way to go, but when distributing something that functions as a document, you'd like one version to work the same everywhere. So it's appropriate that Pd supports (or at least tries to support) both models. cheers Miller On Sat, Dec 08, 2012 at 11:40:21AM +0100, katja wrote: OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will. Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd. I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs. Katja On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner h...@at.or.atwrote: Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them. I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way. .hc On Dec 7, 2012, at 6:50 PM, katja wrote: Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux. I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd? Thanks, Katja ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use extensions .l_i386 and .l_ia64 for Linux externals
Bundling externals for all the different platforms is workable at them moment for those who can handle building software, and have access to machines that can build for all the target environments. Along those lines, I think we can make it easy to take that idea all the way by smoothing the process of getting artworks into Debian or at least packaged so that people can either 'apt-get install myworkofgenius' or easily build a live CD that boots straight into 'myworkofgenius' on just about any x86 computer. I think this approach is much easier to automate and therefore easier to make straightforward for non-technical people. Plus there are already lots of people working on making live CDs that work (puredyne, Fedora, Ubuntu, Knoppix, Debian, etc. etc.). Pd-extended on Mac OS X will also build a double-clickable MyWorkOfGenius.app with all the libraries embedded inside. I haven't heard much feedback about it, so I wonder how its working for people. .hc On Dec 8, 2012, at 12:40 PM, Miller Puckette wrote: ... or indeed, to distribute a patch with a piece of music, for example - it's best if the patch works cross-platform, and for that, any externs should be bundled with a variety of compiled versions, which then need individual filenames. I think in general, if you're distributing software, compiling it specificly and separately for different platforms (as is Pd extended) is the best way to go, but when distributing something that functions as a document, you'd like one version to work the same everywhere. So it's appropriate that Pd supports (or at least tries to support) both models. cheers Miller On Sat, Dec 08, 2012 at 11:40:21AM +0100, katja wrote: OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will. Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd. I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs. Katja On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner h...@at.or.atwrote: Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them. I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way. .hc On Dec 7, 2012, at 6:50 PM, katja wrote: Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux. I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd? Thanks, Katja ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use extensions .l_i386 and .l_ia64 for Linux externals
On 12/8/12, Hans-Christoph Steiner h...@at.or.at wrote: Pd-extended on Mac OS X will also build a double-clickable MyWorkOfGenius.app with all the libraries embedded inside. I haven't heard much feedback about it, so I wonder how its working for people. .hc I did use the 'make-an-app' option, it works great but it makes a large app file which is not easy to distribute from a homepage with 'fair use policy' and certainly not via a forum or mailing list. For that reason I prefer to package patches plus specific source files and binaries only. With the advantage that it works on 'all' platforms. And the disadvantage that I have to build on all platforms. This poses a natural limit on my ambitions to publish new projects. Maybe not so bad after all... Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pb with readanysf compilation.
On 12/08/2012 17:15, contact wrote: In file included from src/FifoVideoFrames.cpp:20: src/FifoVideoFrames.h:30:27: error: gmerlin/avdec.h: Aucun fichier ou dossier de ce type while it is sometimes simple for speakers of different languages to guess what a localized error-message means, it is often unintelligible. it would therefore be great, if you could try to provide english error messages. try temporarily setting your locale to C before running the failing build. e.g. $ LANG=C make apart from that, hans is probably right and you should install the libgmerlin-avdec-dev package. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
