Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
cheers Miller
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
On 12/22/2012 02:48, Miller Puckette wrote:
Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
cool, but...
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
...i'm unsure what to think about the current jack situation. as it is (at least is in my cop of pd-0.44), taken from todays git), if i turn on/off audio, the Pd-jack client appears/disappears. roman reported this as a bug and i thought this was going to be fixed for 0.44, but it seems that it is still there. what are the plans for this?
fgamsdr IOhannes
PS: merry christmas!
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
cheers M
And merry Christmas too...
On Mon, Dec 24, 2012 at 10:09:37PM +0100, IOhannes m zmölnig wrote:
On 12/22/2012 02:48, Miller Puckette wrote:
Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
cool, but...
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
...i'm unsure what to think about the current jack situation. as it is (at least is in my cop of pd-0.44), taken from todays git), if i turn on/off audio, the Pd-jack client appears/disappears. roman reported this as a bug and i thought this was going to be fixed for 0.44, but it seems that it is still there. what are the plans for this?
fgamsdr IOhannes
PS: merry christmas!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
Roman
And merry Christmas too...
On Mon, Dec 24, 2012 at 10:09:37PM +0100, IOhannes m zmölnig wrote:
On 12/22/2012 02:48, Miller Puckette wrote:
Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
cool, but...
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
...i'm unsure what to think about the current jack situation. as it is (at least is in my cop of pd-0.44), taken from todays git), if i turn on/off audio, the Pd-jack client appears/disappears. roman reported this as a bug and i thought this was going to be fixed for 0.44, but it seems that it is still there. what are the plans for this?
fgamsdr IOhannes
PS: merry christmas!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
An Audio API can be quite different than another, so I don't think it makes sense to treat them all the same in terms of things like whether DSP disconnects the audio API. For example Mac OS X CoreAudio, even through PortAudio, always has handled multiple apps playing back. And the "audio stuck" workaround actually only causes problems with CoreAudio.
.hc
Roman
And merry Christmas too...
On Mon, Dec 24, 2012 at 10:09:37PM +0100, IOhannes m zmölnig wrote:
On 12/22/2012 02:48, Miller Puckette wrote:
Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
cool, but...
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
...i'm unsure what to think about the current jack situation. as it is (at least is in my cop of pd-0.44), taken from todays git), if i turn on/off audio, the Pd-jack client appears/disappears. roman reported this as a bug and i thought this was going to be fixed for 0.44, but it seems that it is still there. what are the plans for this?
fgamsdr IOhannes
PS: merry christmas!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Dec 27, 2012, at 3:29 PM, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
An Audio API can be quite different than another, so I don't think it makes sense to treat them all the same in terms of things like whether DSP disconnects the audio API. For example Mac OS X CoreAudio, even through PortAudio, always has handled multiple apps playing back. And the "audio stuck" workaround actually only causes problems with CoreAudio.
Here's a pulseaudio implementation for libpd, I'm sure Patrick would be fine for that code to be included in Pd.
http://www.workinprogress.ca/libpd/
.hc
.hc
Roman
And merry Christmas too...
On Mon, Dec 24, 2012 at 10:09:37PM +0100, IOhannes m zmölnig wrote:
On 12/22/2012 02:48, Miller Puckette wrote:
Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
cool, but...
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
...i'm unsure what to think about the current jack situation. as it is (at least is in my cop of pd-0.44), taken from todays git), if i turn on/off audio, the Pd-jack client appears/disappears. roman reported this as a bug and i thought this was going to be fixed for 0.44, but it seems that it is still there. what are the plans for this?
fgamsdr IOhannes
PS: merry christmas!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Don, 2012-12-27 at 15:31 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 3:29 PM, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
An Audio API can be quite different than another, so I don't think it makes sense to treat them all the same in terms of things like whether DSP disconnects the audio API. For example Mac OS X CoreAudio, even through PortAudio, always has handled multiple apps playing back. And the "audio stuck" workaround actually only causes problems with CoreAudio.
Here's a pulseaudio implementation for libpd, I'm sure Patrick would be fine for that code to be included in Pd.
Pd 0.44 with -pa already supports pulseaudio. -pa is even the default, so it's only a matter of making <pulse> the default for -pa to get your desired behavior.
Roman
On Don, 2012-12-27 at 15:29 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
An Audio API can be quite different than another, so I don't think it makes sense to treat them all the same in terms of things like whether DSP disconnects the audio API. For example Mac OS X CoreAudio, even through PortAudio, always has handled multiple apps playing back. And the "audio stuck" workaround actually only causes problems with CoreAudio.
So you agree that 'dsp 0|1' should not automatically disconnect|connect the audio API, regardless of what API is in use?
Roman
On Dec 27, 2012, at 3:36 PM, Roman Haefeli wrote:
On Don, 2012-12-27 at 15:29 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
An Audio API can be quite different than another, so I don't think it makes sense to treat them all the same in terms of things like whether DSP disconnects the audio API. For example Mac OS X CoreAudio, even through PortAudio, always has handled multiple apps playing back. And the "audio stuck" workaround actually only causes problems with CoreAudio.
So you agree that 'dsp 0|1' should not automatically disconnect|connect the audio API, regardless of what API is in use?
I don't know enough about the various audio APIs to say whether that's a good idea or not. Perhaps it makes sense with some audio APIs.
.hc
On Don, 2012-12-27 at 16:06 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 3:36 PM, Roman Haefeli wrote:
On Don, 2012-12-27 at 15:29 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
An Audio API can be quite different than another, so I don't think it makes sense to treat them all the same in terms of things like whether DSP disconnects the audio API. For example Mac OS X CoreAudio, even through PortAudio, always has handled multiple apps playing back. And the "audio stuck" workaround actually only causes problems with CoreAudio.
So you agree that 'dsp 0|1' should not automatically disconnect|connect the audio API, regardless of what API is in use?
I don't know enough about the various audio APIs to say whether that's a good idea or not. Perhaps it makes sense with some audio APIs.
I'm not sure you understood my proposal. Exactly _because_ it might not make sense for all APIs, I suggested to use a separate message for API on|off, so that 'dsp 0|1' can behave exactly the same with all APIs (as it used to do anyway before 0.43). Does that make sense?
Example: I often use an idiom [dsp 0, dynamically create stuff, dsp 1] in my patches. I wouldn't want this to work nicely only with -jack while causing ugly clicks with -alsa or -oss. The patchs behaviour shouldn't be affected by the audio API currently in use.
Roman
On 12/27/2012 21:36, Roman Haefeli wrote:
On Don, 2012-12-27 at 15:29 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
pulse audio never worked for me on various debian gnu/linux setups. these days i only ever use alsa and jack, and i believe that one of these (preferably the latter) should be the default for a pro-grade audio software.
So you agree that 'dsp 0|1' should not automatically disconnect|connect the audio API, regardless of what API is in use?
and i strongly agree with roman, that we should differentiate between audio-processing on/off and switching audiobackends on/off.
i think the easiest way would be:
- assume that all backends are blocking
- provide a dummy backend that writes to /dev/null (or whatever the
equivalent on platform foo)
- make dsp 1/0 turn the audio processing on/off. if dsp is off, any
active audio backends should be fed with zeros (to prevent 1-block loops)
gmsdrt IOhannes
On Dec 27, 2012, at 5:23 PM, IOhannes m zmölnig wrote:
On 12/27/2012 21:36, Roman Haefeli wrote:
On Don, 2012-12-27 at 15:29 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will look at it at least. Alternatively I could add a message to pd to restort DSP without stopping/starting the audio I/O, which I'm hoping will at least reduce the need to start/stop SDP all the time.
The change that caused this problem is that I fixed Pd not to have the audio system open whern DSP isn't running so that, on APIs in which audio is exclusive (e.g., ALSA) you can turn DSP off in Pd and go off and use another device with Pd remining open.
The problem arises when there is one message trying to control many different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close audio devices on ALSA, OSS, and MMIO but always keep it open when using jack. But then what about portaudio? I somply don't know the correct way to deal with this.
I'd say it's preferable if Pd's behavior is independent from the back-end currently in use. Rather, I suggest to use different messages for different tasks. IMHO, 'dsp 0' really should only turn computation of tilde-objects off as this is what it means and what one expects. What about a new message to pd 'card 0|1' to free devices which would work completely independently from 'dsp 0|1'? This would allow to record a signal to a soundfile without occupying the soundcard, for instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
pulse audio never worked for me on various debian gnu/linux setups. these days i only ever use alsa and jack, and i believe that one of these (preferably the latter) should be the default for a pro-grade audio software.
Yes, jack is great, and we should make it easy to use. Debian, Ubuntu, Mint, Fedora and others all come with pulseaudio installed and setup by default. That covers probably 75% or more of GNU/Linux users. Pd should have working audio without the users having to do anything at all. So it looks like the only way to achieve that is pulseaudio support. And no, I don't consider Pd's ALSA/OSS connecting to pulseaudio and blocking all other sound a working situation.
.hc
So you agree that 'dsp 0|1' should not automatically disconnect|connect the audio API, regardless of what API is in use?
and i strongly agree with roman, that we should differentiate between audio-processing on/off and switching audiobackends on/off.
i think the easiest way would be:
- assume that all backends are blocking
- provide a dummy backend that writes to /dev/null (or whatever the equivalent on platform foo)
- make dsp 1/0 turn the audio processing on/off. if dsp is off, any active audio backends should be fed with zeros (to prevent 1-block loops)
gmsdrt IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: IOhannes m zmölnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Thursday, December 27, 2012 7:44 PM Subject: Re: [PD] [PD-announce] pd 0.44-0 test 1 released
On Dec 27, 2012, at 5:23 PM, IOhannes m zmölnig wrote:
On 12/27/2012 21:36, Roman Haefeli wrote:
On Don, 2012-12-27 at 15:29 -0500, Hans-Christoph Steiner wrote:
On Dec 27, 2012, at 2:14 PM, Roman Haefeli wrote:
On Die, 2012-12-25 at 13:00 -0800, Miller Puckette wrote:
Hi all - I'm afraid to 'fix' this riht now, but will
look at it at least. Alternatively
I could add a message to pd to restort DSP without
stopping/starting the
audio I/O, which I'm hoping will at least reduce the
need to start/stop
SDP all the time.
The change that caused this problem is that I fixed Pd not
to have the audio
system open whern DSP isn't running so that, on APIs in
which audio is exclusive
(e.g., ALSA) you can turn DSP off in Pd and go off and use
another device
with Pd remining open.
The problem arises when there is one message trying to control
many
different tasks:
- switch DSP computing on/off (save CPU time)
- free/occupy the audio back-end (save soundcard time)
- mute/unmute Pd (save ears)
- force recompilation of the DSP graph
An alternative would be to have Pd automatically close
audio devices on ALSA,
OSS, and MMIO but always keep it open when using jack. But
then what about
portaudio? I somply don't know the correct way to deal
with this.
I'd say it's preferable if Pd's behavior is
independent from the
back-end currently in use. Rather, I suggest to use different
messages
for different tasks. IMHO, 'dsp 0' really should only
turn computation
of tilde-objects off as this is what it means and what one
expects. What
about a new message to pd 'card 0|1' to free devices
which would work
completely independently from 'dsp 0|1'? This would
allow to record a
signal to a soundfile without occupying the soundcard, for
instance.
I think that having a pulseaudio backend for Pd as the default on GNU/Linux would be the best way to solve this problem. Pulse will then handle the multiple apps playing at the same time. Then for people who want to skip Pulse, then can use the ALSA blocking implementation.
pulse audio never worked for me on various debian gnu/linux setups. these days i only ever use alsa and jack, and i believe that one of these
(preferably the latter) should be the default for a pro-grade audio software.
Yes, jack is great, and we should make it easy to use. Debian, Ubuntu, Mint, Fedora and others all come with pulseaudio installed and setup by default. That covers probably 75% or more of GNU/Linux users. Pd should have working audio without the users having to do anything at all. So it looks like the only way to achieve that is pulseaudio support. And no, I don't consider Pd's ALSA/OSS connecting to pulseaudio and blocking all other sound a working situation.
I'd like to get a timestamp from IOhannes for his comment on PulseAudio not working on any GNU/Linux systems. When I look at the PulseAudio docs I like what I see, but unfortunately like Gnome 3 the lead developers of PA seemed to have pushed very hard to get a half-baked initial implementation in as many distros as possible so as to cause the maximum amount of flamewars for something that should have otherwise been a solution to many of the usability problems that have plagued GNU/Linux for so long.
In other words if there are _still_ substantial problems with getting PA to behave, maybe we could do an Ardour-style "it just works" default to the jack server that doesn't require the user to have to know they are even using jack. After all, isn't jack cross-platform (and PulseAudio not)?
-Jonathan
On 12/28/2012 05:44, Jonathan Wilkes wrote:
pulse audio never worked for me on various debian gnu/linux setups. these days i only ever use alsa and jack, and i believe that one of these
(preferably the latter) should be the default for a pro-grade audio software.
[...]
Yes, jack is great, and we should make it easy to use. Debian, Ubuntu, Mint, Fedora and others all come with pulseaudio installed and setup by default. That covers probably 75% or more of GNU/Linux users. Pd should have working audio without the users having to do anything at all. So it looks like the only way to achieve that is pulseaudio support. And no, I don't consider Pd's ALSA/OSS connecting to pulseaudio and blocking all other sound a working situation.
note that i do not argue against "pulseaudio" support in Pd. i believe that the more audio backends we support the merrier. hence my suggestion to factor out the audio-backend stuff (not in this thread): this way "we" can add arbitrary without having to touch the pd-core.
I'd like to get a timestamp from IOhannes for his comment on PulseAudio not working on any GNU/Linux systems. When I look at the PulseAudio docs I like what I see,
the timestamp is 2 weeks before christmas 2012. but let me first clarify two things:
#1 i never said "any GNU/linux system". i said "various Debian gnu/linux systems" with the additional restriction that it didn't work "for me". i'm mainly using debian testing/unstable (rolling) as my distribution. also i'm not using GNOME or KDE, but xfce4 (and sometimes
#2 (and this is more important): i really confused PulseAudio for PortAudio. i often do these, since both are often abbreviated "PA".
so my rant was not targeted at PulseAudio but at PortAudio, which (and i'll happily repeat this) has not happened to work correctly yet.
In other words if there are _still_ substantial problems with getting PA to behave, maybe we could do an Ardour-style "it just works" default to the jack server that doesn't require the user to have to know they are even using jack. After all, isn't jack cross-platform (and PulseAudio not)?
i did the last implementation of jack-support for Pd (0.43) with something like this in mind. i didn't succeed very well (as we can see in this thread)...
anyhow, i agree (if this is what you are saying) that jack would be the best choice for the main backend.
fgdmsr IOhannes
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Friday, December 28, 2012 12:22 PM Subject: Re: [PD] [PD-announce] pd 0.44-0 test 1 released
[...]
i did the last implementation of jack-support for Pd (0.43) with something like this in mind. i didn't succeed very well (as we can see in this thread)...
It might be worth looking at how it works with Ardour since Paul is the author of both.
-Jonathan
anyhow, i agree (if this is what you are saying) that jack would be the best choice for the main backend.
fgdmsr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Friday, December 28, 2012 12:22 PM Subject: Re: [PD] [PD-announce] pd 0.44-0 test 1 released
[...]
#2 (and this is more important): i really confused PulseAudio for PortAudio. i often do these, since both are often abbreviated "PA".
I'd really like to hear from anyone who uses an up-to-date version of PulseAudio on an up-to-date distro whether the myriad problems that came from pushing a beta version of an "It-Just-Works" audio server are now gone.
Even for Pd, it'd be nice to support an audio server that lets you set levels for a video online of a Pd patch while you patch your own, then answer your bluetooth phone without having to open a config file.
I still like the idea of JACK being the default, but there are certainly times when I just want the server to just mix what programs I have open with zero configuration.
-Jonathan
On 12/28/2012 05:36 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Friday, December 28, 2012 12:22 PM Subject: Re: [PD] [PD-announce] pd 0.44-0 test 1 released
[...]
#2 (and this is more important): i really confused PulseAudio for PortAudio. i often do these, since both are often abbreviated "PA".
I'd really like to hear from anyone who uses an up-to-date version of PulseAudio on an up-to-date distro whether the myriad problems that came from pushing a beta version of an "It-Just-Works" audio server are now gone.
Even for Pd, it'd be nice to support an audio server that lets you set levels for a video online of a Pd patch while you patch your own, then answer your bluetooth phone without having to open a config file.
I still like the idea of JACK being the default, but there are certainly times when I just want the server to just mix what programs I have open with zero configuration.
Pulseaudio has been working pretty well for me using pulse-aware apps. I have been using Ubuntu mostly and recently switch to Mint. Apps like Pd and Audacity seem to mess with pulse, my guess is because they try to grab exclusive access, but things like rhythmbox, skype, etc. work well.
.hc
everytime i run audacity i can not get the audio to work again with anything without a cold start.
On 12/30/2012 01:31 AM, Billy Stiltner wrote:
everytime i run audacity i can not get the audio to work again with anything without a cold start.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Did you try resuming pulse audio? It is possible that Audacity might be suspending it but is not necessarily resuming it once it is done. Please take this with a boulder of salt as I've not tested any of this...
OK... try from git again - maybe it'ws fixed
cheers M
On Mon, Dec 24, 2012 at 10:09:37PM +0100, IOhannes m zmölnig wrote:
On 12/22/2012 02:48, Miller Puckette wrote:
Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
cool, but...
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
...i'm unsure what to think about the current jack situation. as it is (at least is in my cop of pd-0.44), taken from todays git), if i turn on/off audio, the Pd-jack client appears/disappears. roman reported this as a bug and i thought this was going to be fixed for 0.44, but it seems that it is still there. what are the plans for this?
fgamsdr IOhannes
PS: merry christmas!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mit, 2012-12-26 at 13:36 -0800, Miller Puckette wrote:
OK... try from git again - maybe it'ws fixed
Looks good to me. With -jack it's possible now to switch DSP off and on in zero logical time without causing a drop-out. Also, turning DSP off does not disconnect the Pd client.
I'm really happy to get the old behavior back. Thanks a lot for dedicating time to address this issue.
Roman
On Mon, Dec 24, 2012 at 10:09:37PM +0100, IOhannes m zmölnig wrote:
On 12/22/2012 02:48, Miller Puckette wrote:
Hi all,
Pd version 0.44-0test1 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
cool, but...
mostly audio, MIDI, scheduling, and OS compatibility bug fixes.
...i'm unsure what to think about the current jack situation. as it is (at least is in my cop of pd-0.44), taken from todays git), if i turn on/off audio, the Pd-jack client appears/disappears. roman reported this as a bug and i thought this was going to be fixed for 0.44, but it seems that it is still there. what are the plans for this?
fgamsdr IOhannes
PS: merry christmas!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Billy Stiltner -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Ivica Ico Bukvic -
Jonathan Wilkes -
Miller Puckette -
Roman Haefeli