Since pd-0.27 I found it impossible to use the "-open" start-up argument on Win95. When using p.e. "pd -open hallo", pd is looking for "hallo.dll" which cannot be found (that's because I want to open "hallo.pd"; trying "pd -open hallo.pd", pd looked for "hallo.pd.dll", which makes me laugh on one hand and cry on the other.
I thought of it only as a Win32 problem, so I tried it on debian, getting "hallo : can't load library" vs. "hallo.pd : can't load library"
Am I missing something really important ?
mfg.bws.aeg hannes
forum::=?iso-8859-1?Q?f=FCr?=::=?iso-8859-1?Q?uml=E4ute?= writes:
Since pd-0.27 I found it impossible to use the "-open" start-up argument on Win95. When using p.e. "pd -open hallo", pd is looking for "hallo.dll" which cannot be found (that's because I want to open "hallo.pd"; trying "pd -open hallo.pd", pd looked for "hallo.pd.dll", which makes me laugh on one hand and cry on the other.
I thought of it only as a Win32 problem, so I tried it on debian, getting "hallo : can't load library" vs. "hallo.pd : can't load library"
Am I missing something really important ?
pd something.pd "opens" something.pd ......
"-open is a synonym for -lib" .... this is not documented correctly.
Guenter
mfg.bws.aeg hannes
pd something.pd "opens" something.pd ......
"-open is a synonym for -lib" .... this is not documented correctly.
ah i see; the docs were really confusing; by the way, since "-open" has not been a synonym for "-lib" all the time (I remember, that in pd-0.24 or so, you could really open patches with it !), how about deleting it entirely from the arg-list ?
But this might be a minor problem...
Guenter
mfg.bws.aeg hannes
Well, one doesn't really 'open' a library...and do we really need synonyms for arguments?
anyway, there is an issue under Windows which I have been fiddling with
- file-association based launching, i.e. double-clicking a pd file to
launch it in PD. the default Windows mechanism is to send a program the command "open" as a command-line argument, together with the selected filename. This can of course be customized (as can dragging a file to the icon), so that, for example, I have set my system up so that in addition to opening the requested file, it loads the GEM library too using the -lib argument. Windows requires at leat one command to be sent
- you can't just delete "open" and send nothing. So even if "open" is a
dummy which does nothing, it still needs to be there.
I was planning to write up a small FAQ about this sort of thing - but of course the usage for the "open" argument needs to be resolved first!
Having to enter command-line arguments within the Windows file association mechanism is not the idiomatic way of doing things anyway; every time you want to load different libraries you have to rewrite the command-line for the association. An environment variable or registry entry for a 'LIB' directory would be much more flexible, as I have suggested previously.
Richard Dobson
Guenter Geiger wrote:
forum::=?iso-8859-1?Q?f=FCr?=::=?iso-8859-1?Q?uml=E4ute?= writes:
Since pd-0.27 I found it impossible to use the "-open" start-up argument on Win95. When using p.e. "pd -open hallo", pd is looking for "hallo.dll" which cannot be found (that's because I want to open "hallo.pd"; trying "pd -open hallo.pd", pd looked for "hallo.pd.dll", which makes me laugh on one hand and cry on the other.
I thought of it only as a Win32 problem, so I tried it on debian, getting "hallo : can't load library" vs. "hallo.pd : can't load library"
Am I missing something really important ?
pd something.pd "opens" something.pd ......
"-open is a synonym for -lib" .... this is not documented correctly.
Guenter
mfg.bws.aeg hannes
Having to enter command-line arguments within the Windows file association mechanism is not the idiomatic way of doing things anyway; every time you want to load different libraries you have to rewrite the command-line for the association. An environment variable or registry entry for a 'LIB' directory would be much more flexible, as I have suggested previously.
As PD is cross platform I would really hate to see any platform specific attributes added. This would take away what I think is a strong point. In particular I think that any use of the registry should be avoided. As part of my job I help support several hundred windows desktop systems and I can't tell you how many problems are caused by this windows 'feature'. It works so poorly many large software companies refuse to code for it. I agree with Richard that environment variables are not an elegant solution under windows - I am not even a fan of application specific enviroment variables under unix. Plain text file .pdrc (unix) or pd.ini (windows) seem like the best choice to me. Many of us really dislike the windows way of doing things - probably as much as many people dislike the unix way of doing things. Any solution that steers clear of either direction is probably good and I think that .rc and .ini files are pretty neutral. Just my two cents.
Karl
Guenter Geiger wrote:
forum::=?iso-8859-1?Q?f=FCr?=::=?iso-8859-1?Q?uml=E4ute?= writes:
Since pd-0.27 I found it impossible to use the "-open" start-up argument on Win95. When using p.e. "pd -open hallo", pd is looking for "hallo.dll" which cannot be found (that's because I want to open "hallo.pd"; trying "pd -open hallo.pd", pd looked for "hallo.pd.dll", which makes me laugh on one hand and cry on the other.
I thought of it only as a Win32 problem, so I tried it on debian, getting "hallo : can't load library" vs. "hallo.pd : can't load library"
Am I missing something really important ?
pd something.pd "opens" something.pd ......
"-open is a synonym for -lib" .... this is not documented correctly.
Guenter
mfg.bws.aeg hannes
-- Test your DAW with my Soundcard Attrition Page! http://wkweb5.cableinet.co.uk/rwd (LU: 23rd August 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 14th June 1999)
I am fully sympathetic towards the cross-platform compatibility, and not asking for anything to be put into the main sources which would threaten that. However, some small refinements to the current system would I think benefit all platforms. The .pdrc is an entirely acceptable solution - though it will serve the cross-platform paradigm if accesses to it are abstracted, as I suggested in an earler post, so that people like me can implement Windows-specific patches (rather as happens in Csound) without breaking the underlying code. My goal is as user-friendly a Windows version as possible, so that composers who never want even to see a compiler, much less use one, can use PD with as much ease as possible.
My only real ~problem~ was having to have dlls in the working directory
- this is not a Windows issue but a generic issue for all platforms.
Under Windows, basic code to access the .ini file to read/write user settings is virtually identical to the Registry mode. I am not proposing, or planning, the sort of intense Registry usage that leads to the problems you describe. We still use the .ini file mechanism in Windows Csound, as it happens, for compatibility with Windows 3.1. It is not really a multi-user solution though.
Richard Dobson
Karl MacMillan wrote:
Having to enter command-line arguments within the Windows file association mechanism is not the idiomatic way of doing things anyway; every time you want to load different libraries you have to rewrite the command-line for the association. An environment variable or registry entry for a 'LIB' directory would be much more flexible, as I have suggested previously.
As PD is cross platform I would really hate to see any platform specific attributes added. This would take away what I think is a strong point. In particular I think that any use of the registry should be avoided. As part of my job I help support several hundred windows desktop systems and I can't tell you how many problems are caused by this windows 'feature'. It works so poorly many large software companies refuse to code for it. I agree with Richard that environment variables are not an elegant solution under windows - I am not even a fan of application specific enviroment variables under unix. Plain text file .pdrc (unix) or pd.ini (windows) seem like the best choice to me. Many of us really dislike the windows way of doing things - probably as much as many people dislike the unix way of doing things. Any solution that steers clear of either direction is probably good and I think that .rc and .ini files are pretty neutral. Just my two cents.
Karl
I agree....
m On Mon, 15 Nov 1999, Karl MacMillan wrote:
As PD is cross platform I would really hate to see any platform specific attributes added. This would take away what I think is a strong point. In particular I think that any use of the registry should be avoided. As part of my job I help support several hundred windows desktop systems and I can't tell you how many problems are caused by this windows 'feature'. It works so poorly many large software companies refuse to code for it. I agree with Richard that environment variables are not an elegant solution under windows - I am not even a fan of application specific enviroment variables under unix. Plain text file .pdrc (unix) or pd.ini (windows) seem like the best choice to me. Many of us really dislike the windows way of doing things - probably as much as many people dislike the unix way of doing things. Any solution that steers clear of either direction is probably good and I think that .rc and .ini files are pretty neutral. Just my two cents.
Karl
Guenter Geiger wrote:
forum::=?iso-8859-1?Q?f=FCr?=::=?iso-8859-1?Q?uml=E4ute?= writes:
Since pd-0.27 I found it impossible to use the "-open" start-up argument on Win95. When using p.e. "pd -open hallo", pd is looking for "hallo.dll" which cannot be found (that's because I want to open "hallo.pd"; trying "pd -open hallo.pd", pd looked for "hallo.pd.dll", which makes me laugh on one hand and cry on the other.
I thought of it only as a Win32 problem, so I tried it on debian, getting "hallo : can't load library" vs. "hallo.pd : can't load library"
Am I missing something really important ?
pd something.pd "opens" something.pd ......
"-open is a synonym for -lib" .... this is not documented correctly.
Guenter
mfg.bws.aeg hannes
-- Test your DAW with my Soundcard Attrition Page! http://wkweb5.cableinet.co.uk/rwd (LU: 23rd August 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 14th June 1999)
-- _____________________________________________________ | Karl W. MacMillan | | Peabody Institute of the Johns Hopkins University | | Network and Telecommunications Services | | karlmac@peabody.jhu.edu | | 410/659-8297 |
Michael A. Thompson
Unix SysAdmin.
[IRIX - NeXTStep - Linux - MacOS - Windows]
Home: (940)382-2086
Richard Dobson writes:
Well, one doesn't really 'open' a library...and do we really need synonyms for arguments?
No, we don't need them. I just wanted to tell what's the fact currently.
In fact Miller's word is the last on this, but I think he will agree with any reasonable solution.
About the registry, environment topic, I too think that some startup file parsing is appropriate. (A form of this is already implemented, but it is really rudimentary).
Guenter
I now find that after all flag options are dealt with, what's left is presumed to be the .pd file to open, so that just typing "pd adsr.pd" opens the patch as one would expect. So that so long as "open" is clearly documented as an alias for "lib" (if that is what it is retained as ), I have no problems - I can set up Windows command strings accordingly. It might be as well to document this behaviour as "pd [flags] file.pd", in the usage message.
Richard Dobson
I wrote:
anyway, there is an issue under Windows which I have been fiddling with
- file-association based launching, i.e. double-clicking a pd file to
launch it in PD. the default Windows mechanism is to send a program the command "open" as a command-line argument, together with the selected filename.
Well, "-open" used to mean "open the following file as a patch"... if it now means "load a dll" then it's broken. I'll check and fix.
thanks Miller
-
unknown＠example.com -
Guenter Geiger -
Karl MacMillan -
Micheal Allen Thompson -
Miller Puckette -
Richard Dobson