Hi all,
I seem to be having problems getting pd to run on NT. The error message I get in a little dialog box is:
The instruction at "0x100162bf" referenced memory at "0x00000010". The memory could not be "read".
And the output in the command prompt window is:
Pd version 0.21 compiled Thu Jan 15 08:52:27 PST 1998 port 5400 c:/pd Waiting for connection request... ... connected pd: ADCs on; DACs on waveInOpen: A device ID has been used that is out of range for your system. waveOutOpen: A device ID has been used that is out of range for your system. midiOutOpen: There is no driver installed on your system. There are no MIDI input devices. pd: running.
I've tried this on a couple different puters running NT, but to avail. It does work if I run it with the '-nosound' or '-adc' options, but then I hear no sound. :)
To tell you the truth I'm a little baffled by this because I've written a program that calls both waveInOpen and waveOutOpen and it works perfectly. Also, from first glance my source is basically the same as that in pd, with the one exception that I use the more recent structure WAVEFORMATEX rather than PCMWAVEFORMAT. Alas, I've modified pd's code to use that new structure but the same errors occur. (In fact, I'm not sure this should have any effect because actually I think the data alignment is the same between the two structures (except for an extra word at the end of WAVEFORMATEX), just the field names are different). I'll take a closer look at what is different between the two programs later, but I'm wondering if anyone else has had problems?
Also, I've tried to run pd in linux. I cannot seem to compile it, however. The error message I get is:
make: *** No rule to make target /usr/include/gnu/stubs.h', needed byg_canvas.o'. Stop.
This file does not exist in my /usr/include/gnu directory. Does someone have this file? Could you send it to me? The only file that is in that directory currently is types.h on my system. It is Debian distribution and my kernel 2.0.33.
Thanks much for your help,
Charlie
Very much enjoying the program, Miller....working on simple MIDI controled ring modulation: think "Mantra"!
Well, I might as well report my errors: i have NT 4.0 - TurtleBeach Fiji sound card Linux (2.0.32- RedHat 5.0) - TurtleBeach Malibu sound card
ERRORS: under NT- all of pd that I have tested worked well, *except* , apx. 80% of the time, the DACs are lost after a few seconds with "dacs died, switching to alternative timing source" This is too bad, because full-duplex has only worked under NT for me.... once the dacs are happy, things work great. (:-(
under Linux - well, no full duplex: the app complains that it can't stat /dev/dsp1 (hey, it's there, looks correct!), the card (actually, /dev/sndstat) reports that it *should * use /dev/dsp1 for record in full-duplex, which it says it supports. and, more important , since ver. 0.21, i get an immediate core dump. sigh. compilation seemed simple enough. ( no errors.) I have no problem with 0.20, other than no fullduplex, and no fft object.. I did go load tcl7.6/tk4.2, since I've moved on to tcl/tk 8.0 ... 0.20 works well, as I said. i will try to gdb the core dump this weekend, but since I no longer enjoy the priorities of an academic position (*sigh*- come'on FloridaState and/or Stanford!!), I must deliver some other debugging to my employer before I can get to pd.... any ideas?
CharlieB baker@charlieb.com baker@ccrma.stanford.edu cbaker@verity.com
Charles Baker wrote: ...
under Linux - well, no full duplex: the app complains that it can't stat /dev/dsp1 (hey, it's there, looks correct!), the card (actually, /dev/sndstat) reports that it *should * use /dev/dsp1 for record in full-duplex, which it says it supports.
The Linux port (s_linux.c) doesn't correctly support full-duplex, I think. There's an ioctl you need to use first to enable it.
Since full-duplex isn't working, what happens is that the card gets opened for output using /dev/dsp, then PD looks for an input card at /dev/dsp1. Something like that. I can send you my version of s_linux.c if you want, but I never tried to get the full duplex working myself.
and, more important , since ver. 0.21, i get an immediate core dump. sigh. compilation seemed simple enough. ( no errors.) I have no problem with 0.20, other than no fullduplex, and no fft object..
0.21 is available for Linux?
-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --
Charles Baker writes: [snip]
under Linux - well, no full duplex: the app complains that it can't stat /dev/dsp1 (hey, it's there, looks correct!), the card (actually, /dev/sndstat) reports that it *should * use /dev/dsp1 for record in full-duplex, which it says it supports.
Most of the things are said by Larry. Full duplex is just not tested (not even truly implemented for Linux) .... a weekend job for a full-duplex card owner ?
and, more important , since ver. 0.21, i get an immediate core dump. sigh. compilation seemed simple enough. ( no errors.) I have no problem with 0.20, other than no fullduplex, and no fft object.. I did go load tcl7.6/tk4.2, since I've moved on to tcl/tk 8.0 ... 0.20 works well, as I said.
Hmm .. sounds strange. No messages at all ? I'm using Debian2.0 here, which is a libc6 based system too and had no problems of that kind.
[snip]
any ideas?
not at the moment
Guenter
Charlie Kilpatrick writes:
make: *** No rule to make target
/usr/include/gnu/stubs.h', needed byg_canvas.o'. Stop.This file does not exist in my /usr/include/gnu directory. Does someone have this file? Could you send it to me? The only file that is in that directory currently is types.h on my system. It is Debian distribution and my kernel 2.0.33.
doing a "make -f makefile.linux depend" before doing "make -f makefile.linux" should "make" this problem go away.
Good News for you ... pd will be included in one of the forthcoming Debian distributions (2.0 or 2.1)
Thanks much for your help,
Charlie
No problem
Guenter
-
Charles Baker -
Charlie Kilpatrick -
Guenter Geiger -
Larry Troxler