Windows issues

[Richard Dobson]

I'm not sure how OS-independent an install package could be. The Windows
paradigm of course is to provide a 'setup.exe' installer (doubtless
based on InstallShield) which queries the user for a preferred drive and
directory (while offering a default), checks for disk space, machine
type and OS version, and installs all system info such as directory
paths, install directory and default execution options to the registry
(previously, an 'ini' file would have been used - still can be, in
fact). A 'settings' menu within the program would be available for the
user to change paths, and, er, settings (such as audio devices, etc).
The environment variable system is now somewhat deprecated under Windows
(requires a reboot, and affects all users, whereas Registry updates can
be dynamic and on a per-user basis), but is retained for DOS-mode
programs which don't access or know about the registry.

In the short term, a "PDLIBDIR" variable would work well; VST plugin
users are well used to putting plugins (which are dlls) into a specific
folder, then Cubase or whichever loads all plugins in that folder on
startup. DirectShow plugins load in much the same way, except that they
can be located anywhere, and the Registry knows where they are via the
GUID.

I think this should be separate from a "PDPATH" variable as that might
reasonably be used for other things - sample soundfiles or whatnot (like
"SFDIR" etc for Csound).

I have not even downloaded the Linux version of PD so I dont know what
is currently done; the Linux paradigm is more prescriptive generally, as
the directory structure is (eg default install to /usr/local/pd), so
that presumably most settings could be stored in a .pdrc file in the
users home directory, and an INSTALL.sh script or makefile used in the
usual way.

Within the program, so long as the calls to system info are abstracted
(don't call getenv() directly but use wrapper functions such as
Get_pdlibdir() or something), they can be customized for each platform.
Similarly, functions need to be available to set options, such as
SetAudioOutDevice(), whcih can either be called in response to a
command-line parse, or dynamically in response to a user menu action.


With regard to Windows shortcuts - this works very well, but there is no
icon for pd.exe yet! I have cobbled one together (yellow capitals "PD"
over the desktop background) and stored it in pd.dll, for now. Certainly
a snappy artistic one is required - perhaps a picture of a 'bang' wired
to an object?



Richard Dobson

Miller Puckette wrote:
> 
> (to answer Richar's earlier query, I'm running the spectral patches
> on my Dell PII 300.  But memory bandwidth (function of motherboard) is
> also important and laptops generally underperform "desktop" machines.
> 
> As to the path business, you can invoke "pd -path \my\favorites" or
> whatnot.  In practice for Windows I put this in a shortcut.  It would
> be appropriate to have a "PDPATH" environment variable feature too although
> I haven't treated this as a high priority.  The best thing would
> be to have a Pd installation somehow contain information about paths to
> installed "dlls" and abstractions, but I haven't thought of a good, OS-
> independent way to specify this...  ideas?
> 
> cheers
> Miller
> 
> On Fri, Nov 12, 1999 at 12:11:43AM +0000, Richard Dobson wrote:
> > Following my introductory post, I am making some progress, and have got
> > as far as building pd.dll under VC++ v.5, and the externs leftshift,
> > rightshift and pique. I hope to have access to an ftp server at Bath
> > university soon, so that I can make these available (with VC++ project
> > files) for anyone interested.
> >
> > I have already encountered the problem that external dlls such as those
> > mentioned are required to be in the 'current directory', which is hardly
> > ideal as there can be many of these, for different projects, as
> > demonstrated by the examples supplied. Such as dll is effectively a
> > 'plugin', and  should really be kept in a single folder for the purpose
> > (could even be /pd/bin). This can be accessed via the ineluctable
> > environment variable, or under Windows, idiomatically, via the registry.
> >
> > Would it be a 'big issue' to change this system to support such a single
> > directory?
> >
> > (after all, if an environment var is not detected, the program can still
> > default to searching the working directory).
> >
> >
> >
> > Richard Dobson
> >
> >
> >
> > --
> > Test your DAW with my Soundcard Attrition Page!
> > http://wkweb5.cableinet.co.uk/rwd (LU: 17th September 1999)
> > CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 4th November 1999)

-- 
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)