Hello list,
I was wondering if the problem of the relative path of [pix_write] under osx may be fixed soon. For reminder the actual behavior (gem compiled this morning, used with pd-extended 0.42.5, osx.6.8) is:
- if you send no filename, you have in the terminal: error: ERROR: -43 in GraphicsExportSetOutputFile() error: GEM: Unable to save image to 'gem00000.tif'
- if you send a relative filename, eg. [file toto(, you have the same error: error: ERROR: -43 in GraphicsExportSetOutputFile() error: GEM: Unable to save image to 'toto00000.tif'
- if you send a filename including the "~" home variable, it gives the same error.
It only works if you set pix_write to an absolute filename inside an existing directory, eg. [file /Users/nix/snap_pd/test (. From what i've seen in workshop, this is a major difficulty for learners. They are not specially used to explicit a directory from root, and they must not have spaces in any directory name used. It makes also a patch containing pix_write on an osx computer non directly usable on any another ...
Is there any possibility to have relative path in pix_write under osx, or can we imagine some workaround? it will be of great help thanks,
n
Le 30/11/2011 10:03, Nicolas Montgermont a écrit :
Hello list,
I was wondering if the problem of the relative path of [pix_write] under osx may be fixed soon. For reminder the actual behavior (gem compiled this morning, used with pd-extended 0.42.5, osx.6.8) is:
- if you send no filename, you have in the terminal:
error: ERROR: -43 in GraphicsExportSetOutputFile() error: GEM: Unable to save image to 'gem00000.tif'
- if you send a relative filename, eg. [file toto(, you have the same
error: error: ERROR: -43 in GraphicsExportSetOutputFile() error: GEM: Unable to save image to 'toto00000.tif'
- if you send a filename including the "~" home variable, it gives the
same error.
It only works if you set pix_write to an absolute filename inside an existing directory, eg. [file /Users/nix/snap_pd/test (. From what i've seen in workshop, this is a major difficulty for learners. They are not specially used to explicit a directory from root, and they must not have spaces in any directory name used. It makes also a patch containing pix_write on an osx computer non directly usable on any another ...
Is there any possibility to have relative path in pix_write under osx, or can we imagine some workaround?
Have you tried with [getdir] as workaround ? ++
Jack
it will be of great help thanks,
n
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 10:03, Nicolas Montgermont wrote:
Is there any possibility to have relative path in pix_write under osx, or can we imagine some workaround? it will be of great help thanks,
use something like [getdir] to get the current directory and prepend it to the filename. it's a hack but should work.
fgmasdrI IOhannes
hello,
getdir should not be included in Gem help file because it's not vanilla.
if we can't provide a pix_write help patch that is working for everybody, then it's a bug. a better workaround have to be found.
Cyrille
Le 30/11/2011 11:27, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 10:03, Nicolas Montgermont wrote:
Is there any possibility to have relative path in pix_write under osx, or can we imagine some workaround? it will be of great help thanks,
use something like [getdir] to get the current directory and prepend it to the filename. it's a hack but should work.
fgmasdrI IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7WBSwACgkQkX2Xpv6ydvQiswCggddd4YEeN81BXrSF6zcVT7dL 7ekAoMNVdjk602VQMdyOlRpNjJL0SJFz =ClA9 -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 11:52, cyrille henry wrote:
hello,
getdir should not be included in Gem help file because it's not vanilla.
sure. jack and me were mainly suggesting a workaround to get things going no.
if we can't provide a pix_write help patch that is working for everybody, then it's a bug. a better workaround have to be found.
oh sure. nobody doubts that the help-patch should be working everywhere (as long as it supposed to be a working help-patch, which not all help-patches are....looking at pix_write-help.pd is see that this is one of them)
fgmasdr IOhannes
Le 30/11/11 12:13, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 11:52, cyrille henry wrote:
hello,
getdir should not be included in Gem help file because it's not vanilla.
sure. jack and me were mainly suggesting a workaround to get things going no.
Do you think there is a way to make relative path work?
if we can't provide a pix_write help patch that is working for everybody, then it's a bug. a better workaround have to be found.
oh sure. nobody doubts that the help-patch should be working everywhere (as long as it supposed to be a working help-patch, which not all help-patches are....looking at pix_write-help.pd is see that this is one of them)
:) I'm working on it at the moment, that's why i ask this. It's on github: https://github.com/nixhol/Gem/tree/help-files
n
Le 30/11/11 12:25, Nicolas Montgermont a écrit :
Le 30/11/11 12:13, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 11:52, cyrille henry wrote:
hello,
getdir should not be included in Gem help file because it's not vanilla.
sure. jack and me were mainly suggesting a workaround to get things going no.
Do you think there is a way to make relative path work?
i was wondering myself something that is maybe stupid but: - why is it difficult to use the same way of writing files that inside vanilla? sounfiler and textfile for example work with relative path. (even in pd-extended) - otherwise, is there any obvious and good reason not to use getdir code to get the actual patch dir inside gem, to have gem use relative path? it seems to me that getdir code is only depending on m_pd.h n
hi,
i'm currently working on that at least for pix_write will be soon on git...
+ a.
We've long since dropped the vanilla requirement for help patches since there are just too many useful things outside of vanilla. Thinks like getdir and pddplink make the help patches much more useful.
pd-ggee and pd-pddp are both in Debian/Ubuntu/etc, as well as being very easy to build and install as standalone libraries for Mac OS X. It seems that there is no longer a good reason to stick with only vanilla for things like this.
.hc
On Nov 30, 2011, at 5:52 AM, cyrille henry wrote:
hello,
getdir should not be included in Gem help file because it's not vanilla.
if we can't provide a pix_write help patch that is working for everybody, then it's a bug. a better workaround have to be found.
Cyrille
Le 30/11/2011 11:27, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 10:03, Nicolas Montgermont wrote:
Is there any possibility to have relative path in pix_write under osx, or can we imagine some workaround? it will be of great help thanks,
use something like [getdir] to get the current directory and prepend it to the filename. it's a hack but should work.
fgmasdrI IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7WBSwACgkQkX2Xpv6ydvQiswCggddd4YEeN81BXrSF6zcVT7dL 7ekAoMNVdjk602VQMdyOlRpNjJL0SJFz =ClA9 -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 16:47, Hans-Christoph Steiner wrote:
We've long since dropped the vanilla requirement
well, not in Gem world. there are very few objects in help-patches that are neither in Gem nor in Pd-vanilla.
famsdr IOhannes
Le 30/11/2011 17:32, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 16:47, Hans-Christoph Steiner wrote:
We've long since dropped the vanilla requirement
well, not in Gem world. there are very few objects in help-patches that are neither in Gem nor in Pd-vanilla.
i think there are none. and i don't want to change that.
Cyrille
famsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7WWn4ACgkQkX2Xpv6ydvQgfwCgi95GXMVO6SrKNZR4RVwVQM8r SlUAoJWbOWdyPdtsibEXh6mvzhcaS6P3 =bBT4 -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Nov 30, 2011, at 1:48 PM, cyrille henry wrote:
Le 30/11/2011 17:32, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 16:47, Hans-Christoph Steiner wrote:
We've long since dropped the vanilla requirement
well, not in Gem world. there are very few objects in help-patches that are neither in Gem nor in Pd-vanilla.
i think there are none. and i don't want to change that.
Are there any specific problems? It seems silly to me to have worse help patches because of strict ideology. That will hurt people learning Gem. The people who want strict vanilla are advnaced people anyway, so they can ignore the "... cannot create" messages if they don't want to install anything else.
The fact is that there are a lot of libraries that are as easy or easier to install then Gem. And Gem could benefit by using some of those libraries, like [getdir]. You simply cannot do that with Pd-vanilla. And things like [pix_multiblob] already in effect depend on iemmatrix, since it was designed to work with that library.
I'd happily post Windows and Mac OS X binaries to puredata.info/downloads if that's what it would take.
.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
Le 01/12/2011 03:10, Hans-Christoph Steiner a écrit :
On Nov 30, 2011, at 1:48 PM, cyrille henry wrote:
Le 30/11/2011 17:32, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 16:47, Hans-Christoph Steiner wrote:
We've long since dropped the vanilla requirement
well, not in Gem world. there are very few objects in help-patches that are neither in Gem nor in Pd-vanilla.
i think there are none. and i don't want to change that.
Are there any specific problems?
lot's. stability / conservation / simplicity / compatibility
to allow help file to use pd-extended object, is opening a door on a huge chaos.
It seems silly to me to have worse help patches because of strict ideology. That will hurt people learning Gem.
Gem help patch are lot's better than most of other lib.
The people who want strict vanilla are advnaced people anyway, so they can ignore the "... cannot create" messages if they don't want to install anything else.
advanced user can deal with "cannot create" message. begging will not understand why a help patch is not working. a help file should work anywhere / any-time / whatever pd installation you have.
The fact is that there are a lot of libraries that are as easy or easier to install then Gem.
that's not a reason to install them. or to have there installation mandatory.
i did not born as a "no dependency" extremist. i became so, because in real life, dependency cause problem. this fact can't be discuss : i have lost so many time in my life because of this that i now prefer spending 10 min to make a vanilla only patch better than 3min to make a patch that work on 1 computer.
And Gem could benefit by using some of those libraries, like [getdir]. You simply cannot do that with Pd-vanilla.
that's a bug and a good solution have to be found.
And things like [pix_multiblob] already in effect depend on iemmatrix, since it was designed to work with that library.
pix_multiblob does not depend on iemmatrix. the help file do work perfectly without iemmatrix.
I'd happily post Windows and Mac OS X binaries to puredata.info/downloads if that's what it would take.
that's not a long therm solution, since it add unnecessary work.
c
.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
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i agree, but,...
On 2011-12-01 10:17, cyrille henry wrote:
And things like [pix_multiblob] already in effect depend on iemmatrix, since it was designed to work with that library.
pix_multiblob does not depend on iemmatrix. the help file do work perfectly without iemmatrix.
[pix_multiblob] has indeed no dependency on iemmatrix, but outputs data in a form that is natural to iemmatrix and less natural to the rest of Pd. in retrospect i think it was a bad idea to output the data in iemmatrix-like messages, and actually would like to change that (allowing for a flag to indicate whether one would like iemmatrix messages or ordinary lists)
however, to be fair, there is one abstraction that ships with Gem that depends on iemmatrix, and this is [pix_blobtracker]. btw, the help-patch pix_blocktracker-help.pd does not depend on iemmatrix.
fgmasdr IOhannes
On Dec 1, 2011, at 5:34 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i agree, but,...
On 2011-12-01 10:17, cyrille henry wrote:
And things like [pix_multiblob] already in effect depend on iemmatrix, since it was designed to work with that library.
pix_multiblob does not depend on iemmatrix. the help file do work perfectly without iemmatrix.
[pix_multiblob] has indeed no dependency on iemmatrix, but outputs data in a form that is natural to iemmatrix and less natural to the rest of Pd. in retrospect i think it was a bad idea to output the data in iemmatrix-like messages, and actually would like to change that (allowing for a flag to indicate whether one would like iemmatrix messages or ordinary lists)
however, to be fair, there is one abstraction that ships with Gem that depends on iemmatrix, and this is [pix_blobtracker]. btw, the help-patch pix_blocktracker-help.pd does not depend on iemmatrix.
pix_blocktracker-help.pd definitely depends on iemmatrix because it depends on pix_blocktracker.pd. So its just silly to not use iemmatrix in pix_blocktracker-help.pd.
.hc
----------------------------------------------------------------------------
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 19:55, Hans-Christoph Steiner wrote:
btw, the help-patch pix_blocktracker-help.pd does not depend on iemmatrix.
pix_blocktracker-help.pd definitely depends on iemmatrix because it depends on pix_blocktracker.pd. So its just silly to not use iemmatrix in pix_blocktracker-help.pd.
how come? pix_blobtracker-help.pd depends on [pix_blobtracker], which depends on iemmatrix. this is different from pix_blobtracker-help depending on iemmatrix.
i don't see any reason to use iemmatrix within pix_blobtracker-help.pd it's not needed.
it's plain silly to use an external where it is not needed nor providing any useful functionality.
fmasdr IOhannes
On Dec 1, 2011, at 1:59 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 19:55, Hans-Christoph Steiner wrote:
btw, the help-patch pix_blocktracker-help.pd does not depend on iemmatrix.
pix_blocktracker-help.pd definitely depends on iemmatrix because it depends on pix_blocktracker.pd. So its just silly to not use iemmatrix in pix_blocktracker-help.pd.
how come? pix_blobtracker-help.pd depends on [pix_blobtracker], which depends on iemmatrix. this is different from pix_blobtracker-help depending on iemmatrix.
i don't see any reason to use iemmatrix within pix_blobtracker-help.pd it's not needed.
it's plain silly to use an external where it is not needed nor providing any useful functionality.
Of course don't add dependencies that are not needed. You mentioned that pix_multiblob outputs data that vanilla objects don't handle well, so it seems relevant. I am saying its silly to avoid using iemmatrix in pix_blobtracker-help.pd since pix_blobtracker.pd already depends on it.
.hc
----------------------------------------------------------------------------
"Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 20:24, Hans-Christoph Steiner wrote:
Of course don't add dependencies that are not needed. You mentioned that pix_multiblob outputs data that vanilla objects don't handle well, so it seems relevant. I am saying its silly to avoid using iemmatrix in pix_blobtracker-help.pd since pix_blobtracker.pd already depends on it.
it's not deliberately avoided. there is just no need to use it.
fgmadr IOhannes
On Dec 1, 2011, at 4:17 AM, cyrille henry wrote:
Le 01/12/2011 03:10, Hans-Christoph Steiner a écrit :
On Nov 30, 2011, at 1:48 PM, cyrille henry wrote:
Le 30/11/2011 17:32, IOhannes m zmoelnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-30 16:47, Hans-Christoph Steiner wrote:
We've long since dropped the vanilla requirement
well, not in Gem world. there are very few objects in help-patches that are neither in Gem nor in Pd-vanilla.
i think there are none. and i don't want to change that.
Are there any specific problems?
lot's. stability / conservation / simplicity / compatibility
Those are general words, can you point to a specific problem?
to allow help file to use pd-extended object, is opening a door on a huge chaos.
These are libraries we are taking about, just like Gem, pmpd, zexy, etc. The only real "pd-extended object" is maybe [import].
It seems silly to me to have worse help patches because of strict ideology. That will hurt people learning Gem.
Gem help patch are lot's better than most of other lib.
The people who want strict vanilla are advnaced people anyway, so they can ignore the "... cannot create" messages if they don't want to install anything else.
advanced user can deal with "cannot create" message. begging will not understand why a help patch is not working. a help file should work anywhere / any-time / whatever pd installation you have.
The fact is that there are a lot of libraries that are as easy or easier to install then Gem.
that's not a reason to install them. or to have there installation mandatory.
i did not born as a "no dependency" extremist. i became so, because in real life, dependency cause problem. this fact can't be discuss : i have lost so many time in my life because of this that i now prefer spending 10 min to make a vanilla only patch better than 3min to make a patch that work on 1 computer.
c'est le via. We've all be there. There are certain things you simply cannot do with vanilla. Even you use Gem and zexy because you cannot do what you do without them.
And Gem could benefit by using some of those libraries, like [getdir]. You simply cannot do that with Pd-vanilla.
that's a bug and a good solution have to be found.
I am proposing a solution which you are just saying "no" to. If you want to have a useful discussion, how about proposing a different solution?
And things like [pix_multiblob] already in effect depend on iemmatrix, since it was designed to work with that library.
pix_multiblob does not depend on iemmatrix. the help file do work perfectly without iemmatrix.
I'd happily post Windows and Mac OS X binaries to puredata.info/downloads if that's what it would take.
that's not a long therm solution, since it add unnecessary work.
This is how Gem is distributed, and indeed the vast majority of software that people use is distributed like this. I think its safe to say its a proven method.
.hc
c
.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
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
-
Antoine Villeret -
cyrille henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jack -
Nicolas Montgermont