hi,
before I go about patching my copy of pd I was wondering if there were any major objections to free the /dev/dsp filehandle when stopping the dsp and reopening it when starting it again (under linux for now). Since I have pd running pretty much all of the time but sometimes like to use a waveeditor aswell (without patching it to write to a pipe ;) I think this would be a pretty usefull feature esp. in connection with a cmd line switch like -freedsp
what do you think ?
regards
x
I have the exact same problem... this sounds like a good idea. Note that with DSP stopped time measurement has to come from gettimeofday() instead of counting DSP blocks...! This means surgery to the main scheduler, which I've been loathe to attempt (but now seems like a good moment.)
cheers Miller
that you'd like to have the choice (use the DAC for time On Sun, Nov 18, 2001 at 05:02:33PM +0100, CK wrote:
hi,
before I go about patching my copy of pd I was wondering if there were any major objections to free the /dev/dsp filehandle when stopping the dsp and reopening it when starting it again (under linux for now). Since I have pd running pretty much all of the time but sometimes like to use a waveeditor aswell (without patching it to write to a pipe ;) I think this would be a pretty usefull feature esp. in connection with a cmd line switch like -freedsp
what do you think ?
regards
x
-- chris@lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
I read:
with DSP stopped time measurement has to come from gettimeofday() instead of counting DSP blocks...! This means surgery to the main scheduler, which
oops really (I guess you must know) ? But how come pd works fine without any audio device available ?
looking at the scheduler code right now ... regards
x
In m_scheduler() (which is very easy to mess up!) there's a test on "m_nodacs" which decides whether "timeforward" is true or not (and a bit more) which is handled differently in teh two cases. What I haven't got working is being able to switch seamlessly back and forth between the two.
cheers Miller
On Sun, Nov 18, 2001 at 06:51:18PM +0100, CK wrote:
I read:
with DSP stopped time measurement has to come from gettimeofday() instead of counting DSP blocks...! This means surgery to the main scheduler, which
oops really (I guess you must know) ? But how come pd works fine without any audio device available ?
looking at the scheduler code right now ... regards
x
-- chris@lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
hi Miller,
while looking at scheduler code, would you consider providing a third case of moving time forward as soon as all computations are done?
Krzysztof
Miller Puckette wrote:
In m_scheduler() (which is very easy to mess up!) there's a test on "m_nodacs" which decides whether "timeforward" is true or not (and a bit more) which is handled differently in teh two cases. What I haven't got working is being able to switch seamlessly back and forth between the two.
I am a little afraid, since start/stop dsp is used in some of my patches in sense of 'mute' and realy fast (eg 5 ticks) to let the cpu (message stack) catch up... so i think if the whole audiocard buffer has to be filled and emptied, there could be even some clicks on some soundcards which looses sync or so... so in concert situation its not a good idea...
My suggestion is to make an additional switch sound on/off:
a) where sound off forces dsp stop if not already stopped, and dsp start forces sound on if not already on. or b) sound on/off could is releasing/assigning the audiodevice and dsp continues running on timer mode (eg. for soundfile output...)
mfg winfried
I have the exact same problem... this sounds like a good idea. Note that with DSP stopped time measurement has to come from gettimeofday() instead of counting DSP blocks...! This means surgery to the main scheduler, which I've been loathe to attempt (but now seems like a good moment.)
cheers Miller
that you'd like to have the choice (use the DAC for time On Sun, Nov 18, 2001 at 05:02:33PM +0100, CK wrote:
hi,
before I go about patching my copy of pd I was wondering if there were any major objections to free the /dev/dsp filehandle when stopping the dsp and reopening it when starting it again (under linux for now). Since I have pd running pretty much all of the time but sometimes like to use a waveeditor aswell (without patching it to write to a pipe ;) I think this would be a pretty usefull feature esp. in connection with a cmd line switch like -freedsp
what do you think ?
regards
x
-- chris@lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
hi,
yes -- a separate toggle is much better. And even more handy would be an audio configuration panel for setting audio devices, experimenting with parameters like audiobuf or frags and blocksize, etc. Then the on/off switching could be done separately for dac and adc.
Krzysztof
Winfried Ritsch wrote: ...
My suggestion is to make an additional switch sound on/off:
a) where sound off forces dsp stop if not already stopped, and dsp start forces sound on if not already on. or b) sound on/off could is releasing/assigning the audiodevice and dsp continues running on timer mode (eg. for soundfile output...)
-
CK -
Krzysztof Czaja -
Miller Puckette -
Winfried Ritsch