Hello Rolando.
I'm hardly a "support team"... I'm just a guy who put together an installer. I'm forwarding your email to the general Pd discussion list (which I highly recommend joining at http://iem.kug.ac.at/cgi-bin/ mailman/listinfo/pd-list), where other people who have worked with modern G4 PowerMacs might have some hints
I would recommend sending the output of doing the command: /usr/local/pd/bin/pd -listdev
That might help debugging.
Cheers, adam
Rolando Cori said this at Fri, 21 Mar 2003 18:35:08 -0400:
Dear PD support team>
I finally got PD installed in Macos 10.2 but I still get no sound from it. At the terminal I get the following message> Rolando-Cori-s-Computer:~] rcori% /usr/local/pd/bin/pd reading startup file: /Users/rcori/.pdrc could not open midi input device number 1: Host error. could not open midi output device number 1: Host error. using default input device number: -1 using default output device number: 0 nchan 2, flags 3, bufs 8, framesperbuf 256 Error number -9999 occured opening portaudio stream Error message: Invalid number of channels. audio I/O error history: seconds ago error type watchdog: signaling pd...
Perhaps PD doent work with the G4 factory sound card (It has only sound output anyway). I'm planning to buy a MOTU 828. You think that would work with PD?
Thank you very much for your help and advise.
Rolando Cori
Universidad de Chile Departamento de Musica y SonologiaDear PD support team>
I finally got PD installed in Macos 10.2 but I still get no sound from it. At the terminal I get the following message> Rolando-Cori-s-Computer:~] rcori% /usr/local/pd/bin/pd reading startup file: /Users/rcori/.pdrc could not open midi input device number 1: Host error. could not open midi output device number 1: Host error. using default input device number: -1 using default output device number: 0 nchan 2, flags 3, bufs 8, framesperbuf 256 Error number -9999 occured opening portaudio stream Error message: Invalid number of channels. audio I/O error history: seconds ago error type watchdog: signaling pd...
Perhaps PD doent work with the G4 factory sound card (It has only sound output anyway). I'm planning to buy a MOTU 828. You think that would work with PD?
Thank you very much for your help and advise.
Rolando Cori
Universidad de Chile Departamento de Musica y Sonologia
Adam Lindsay schrieb:
Perhaps PD doent work with the G4 factory sound card (It has only sound output anyway).
Try the option -noadc to disable audio input.
I'm planning to buy a MOTU 828. You think that would
work with PD?
I tried the Motu828 on OS X 10.1.5 with the Motu beta driver and it did not work (loud clicks and signal interruptions). In the meantime some fixes for the Mout 828 have been added to portaudio v0.18 (which handles audio I/O in Pd) but as far as I know this changes have not been added to Pd...
Olaf
Olaf Matthes said this at Sat, 22 Mar 2003 15:04:17 +0100:
I tried the Motu828 on OS X 10.1.5 with the Motu beta driver and it did not work (loud clicks and signal interruptions). In the meantime some fixes for the Mout 828 have been added to portaudio v0.18 (which handles audio I/O in Pd) but as far as I know this changes have not been added to Pd...
Hmm... I haven't been watching PortAudio/MacOSX developments lately. I'll take a look to see if it compiles with current CVS, and post...
Cheers, adam
Adam Lindsay said this at Sat, 22 Mar 2003 15:38:19 +0000:
Olaf Matthes said this at Sat, 22 Mar 2003 15:04:17 +0100:
In the meantime some fixes for the Mout 828 have been added to portaudio v0.18 (which handles audio I/O in Pd) but as far as I know this changes have not been added to Pd...
Hmm... I haven't been watching PortAudio/MacOSX developments lately. I'll take a look to see if it compiles with current CVS, and post...
Right. Well, it compiles and runs just fine on my machine when I replace portaudio/pa_mac_core/pa_mac_core.c with the new one and recompile. I'm just using my normal internal sound driver, though. Best I can say is "it compiles, and it doesn't seem to break anything obvious."
These are the changes since the last pa_mac_core.c synched with Pd:
02.03.2003 - Phil Burk - always use AudioConverters so that we can adapt when format changes. Synchronize with device when format changes. 02.13.2003 - Phil Burk - scan for maxChannels because FormatMatch won't tell us. 03.05.2003 - Phil Burk and Dominic Mazzoni - interleave and deinterleave multiple CoreAudio buffers. Needed for MOTU828 and some other N>2 channel devices. See code related to "streamInterleavingBuffer". 03.06.2003 - Phil Burk and Ryan Francesconi - fixed numChannels query for MOTU828. Handle fact that MOTU828 gives you 8 channels even when you ask for 2!
Pablio and pa_common have also changed recently, but I haven't messed with them, being as conservative as possible with changes.
What should I do?
- Check in the new pa_mac_core.c and let curious people compile the
devel_0_36 branch? 2) Point people to the portaudio tarball and let them experiment with the sources themselves? http://portaudio.com/archives/pa_snapshot_v18.tar.gz 3) Seed a new pd/bin/pd binary to people who want to test the updated portaudio stuff with a range of hardware?
adam
I think if (3) is easy that's the best. In my experience portaudio almost always moves in the direction of greater robustness.
FYI I'm right now getting ready to try PA V19. My guess is that it will soon be robust enough to use in the main Pd dist.
cheers Miller
What should I do?
- Check in the new pa_mac_core.c and let curious people compile the
devel_0_36 branch? 2) Point people to the portaudio tarball and let them experiment with the sources themselves? http://portaudio.com/archives/pa_snapshot_v18.tar.gz 3) Seed a new pd/bin/pd binary to people who want to test the updated portaudio stuff with a range of hardware?
adam
--
Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Miller Puckette said this at Sat, 22 Mar 2003 10:52:14 -0800:
I think if (3) is easy that's the best. In my experience portaudio almost always moves in the direction of greater robustness.
Agreed about portaudio. No matter what else might be true of the architecture (see Chris's comments later), it does get better.
So, if people want to replace their /usr/local/pd/bin/pd file with the file from: http://homepage.mac.com/atl/.cv/atl/Public/pd-pa-new-binary.tar.gz-link.gz ...then please, have fun, have a little test. Back up before installing, but you knew that already. :)
Cheers, adam
FYI I'm right now getting ready to try PA V19. My guess is that it will soon be robust enough to use in the main Pd dist.
cheers Miller
What should I do?
- Check in the new pa_mac_core.c and let curious people compile the
devel_0_36 branch? 2) Point people to the portaudio tarball and let them experiment with the sources themselves? http://portaudio.com/archives/pa_snapshot_v18.tar.gz 3) Seed a new pd/bin/pd binary to people who want to test the updated portaudio stuff with a range of hardware?
adam
--
Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Adam,
I have been looking at the MIDI stuff a little bit, and as PD also uses PortMIDI (for Mac OS X MIDI stuff), I thought that we could look at this too.
I still can't get PD to work properly, as I still get input from all input ports, and it outputs to all ports (not the one requested).
On the other hand, there is a program called 'pmtest' that is with the PortMIDI library, and it works properly. It is just a commandline test tool, but it selects the correct inputs and outputs. So, this leads me to think that there is something that PD is (or is not) doing. I have not really torn apart the code yet, this afternoon looks like a good time.
So, does anyone have any suggestions where to start on the MIDI stuff? I have been compiling some "tracer" code into the MIDI objects, just to get a feel for what code gets called when.
Mike
Adam Lindsay wrote:
Adam Lindsay said this at Sat, 22 Mar 2003 15:38:19 +0000:
Olaf Matthes said this at Sat, 22 Mar 2003 15:04:17 +0100:
In the meantime some fixes for the Mout 828 have been added to portaudio v0.18 (which handles audio I/O in Pd) but as far as I know this changes have not been added to Pd...
Hmm... I haven't been watching PortAudio/MacOSX developments lately. I'll take a look to see if it compiles with current CVS, and post...
Right. Well, it compiles and runs just fine on my machine when I replace portaudio/pa_mac_core/pa_mac_core.c with the new one and recompile. I'm just using my normal internal sound driver, though. Best I can say is "it compiles, and it doesn't seem to break anything obvious."
These are the changes since the last pa_mac_core.c synched with Pd:
02.03.2003 - Phil Burk - always use AudioConverters so that we can adapt when format changes. Synchronize with device when format changes. 02.13.2003 - Phil Burk - scan for maxChannels because FormatMatch won't tell us. 03.05.2003 - Phil Burk and Dominic Mazzoni - interleave and deinterleave multiple CoreAudio buffers. Needed for MOTU828 and some other N>2 channel devices. See code related to "streamInterleavingBuffer". 03.06.2003 - Phil Burk and Ryan Francesconi - fixed numChannels query for MOTU828. Handle fact that MOTU828 gives you 8 channels even when you ask for 2!
Pablio and pa_common have also changed recently, but I haven't messed with them, being as conservative as possible with changes.
What should I do?
- Check in the new pa_mac_core.c and let curious people compile the
devel_0_36 branch? 2) Point people to the portaudio tarball and let them experiment with the sources themselves? http://portaudio.com/archives/pa_snapshot_v18.tar.gz 3) Seed a new pd/bin/pd binary to people who want to test the updated portaudio stuff with a range of hardware?
adam
Right. Well, it compiles and runs just fine on my machine when I replace portaudio/pa_mac_core/pa_mac_core.c with the new one and recompile. I'm just using my normal internal sound driver, though. Best I can say is "it compiles, and it doesn't seem to break anything obvious."
that's good news.
These are the changes since the last pa_mac_core.c synched with Pd:
<snip>
the thing that sort of concerns me is that portaudio seems to need patching to support every new device release for OSX. this is not good, and pretty much defeats a lot of what CoreAudio is meant to do. plus the AudioConverter routine adds another buffer to the I/O chain which might mean at least another 64 samples of latency on both ends. pd already has a relatively high latency on OSX right now, so this isn't going to help out.
What should I do?
- Check in the new pa_mac_core.c and let curious people compile the
devel_0_36 branch? 2) Point people to the portaudio tarball and let them experiment with the sources themselves? http://portaudio.com/archives/pa_snapshot_v18.tar.gz 3) Seed a new pd/bin/pd binary to people who want to test the updated portaudio stuff with a range of hardware?
CVS is a good place for testing and experimentation. go ahead and commit it and i will compile a version and give it to some people using devices like the 828 and report back.
also, i would be interested in working on a direct CoreAudio implementation for pd. i'm tied up on a project until the second week in April, so i won't even take a look until then. anyone else interested in doing this?
cgc
chris clepper said this at Sat, 22 Mar 2003 13:43:03 -0600:
Right. Well, it compiles and runs just fine on my machine when I replace portaudio/pa_mac_core/pa_mac_core.c with the new one and recompile. I'm just using my normal internal sound driver, though. Best I can say is "it compiles, and it doesn't seem to break anything obvious."
that's good news.
We take what we can get nowadays.
These are the changes since the last pa_mac_core.c synched with Pd:
<snip>
the thing that sort of concerns me is that portaudio seems to need patching to support every new device release for OSX. this is not good, and pretty much defeats a lot of what CoreAudio is meant to do.
It's not as bad as that, but it is worth some concern. I think part of it is the issue that apparently PA pitched itself a little too low in the CoreAudio chain.
plus the AudioConverter routine adds another buffer to the I/O chain which might mean at least another 64 samples of latency on both ends. pd already has a relatively high latency on OSX right now, so this isn't going to help out.
True. I haven't been that concerned with latency lately, but I'm sure it'll catch up with me later.
What should I do?
CVS is a good place for testing and experimentation. go ahead and commit it and i will compile a version and give it to some people using devices like the 828 and report back.
I just committed the file, as well as posted the binary (link in another message).
also, i would be interested in working on a direct CoreAudio implementation for pd. i'm tied up on a project until the second week in April, so i won't even take a look until then. anyone else interested in doing this?
I'm interested. Similarly tied up in the short term. I'm also suspecting that Miller's 0.37 audio implementation will be the best foundation for this.
Cheers, adam
-
Adam Lindsay -
chris clepper -
Michael McGonagle -
Miller Puckette -
Olaf Matthes