Would the gentleman from the DCP please resend his email (at least to me
collaborating.
Ben,
el correktor
!><!
http://iem.mhsg.ac.at/mailinglists/pd-list/latest/0034.html
etz what archeives r 4
with search facility!
On Thu, 11 Nov 1999, Benjamin Israel 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
(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:
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: