Thank you Thomas, hc and others for helpful feedback. The function I'm deferring is doing asynchronous DSP, not messaging. Essentially a barrage of intensive DSP thrown at the contents of a buffer (array in Pd land) that will hopefully be done in time to be played back in the main perform loop. Actually a lot of it is working on Pd now, but there are a few functions that do reliably crash Pd, even though they're not CPU-expensive. Quite possibly some memory indiscretion. I'll report back on any further findings.
Best, Eric
On Dec 5, 2006, at 10:13 PM, Mathieu Bouchard wrote:
On Wed, 6 Dec 2006, Thomas Grill wrote:
currently there's no low-priority messaging in Miller's pd version, but there is in the devel branch. It's one of the features that have been there for some time and i'm trying to provide a patch for Miller, so that it can make it into vanilla PD some time in the future. Hopefully the auto-discard mechanism of the patch tracker will blow up before that time. Don't expect the feature to be available soon.
So, how does one use that feature?
Is it that all the audio is high-priority and all the non-audio is low-priority?
Isn't that basically the way it is now? Correct me if I am wrong, but isn't audio data processed first in each cycle, then message data?
FYI: Max since 4.3 (I believe) has two audio threads, a high priority and a low priority. "qelems" and the defer() functions give you access to the low priority thread in externals. Another detail of not is that the threads are cooperative, not pre-emptive. If a give process doesn't defer(), then it won't give up that thread until its done processing.
.hc
Hi Eric, i'm wondering how asynchronous DSP works in Max. As far as i know only messaging can be deferred. Is the DSP operation done outside the normal DSP chain or is it some DSP operations on buffer data that you are doing in message callbacks?
greetings, Thomas
Am 06.12.2006 um 11:37 schrieb Eric Lyon:
Thank you Thomas, hc and others for helpful feedback. The function I'm deferring is doing asynchronous DSP, not messaging. Essentially a barrage of intensive DSP thrown at the contents of a buffer (array in Pd land) that will hopefully be done in time to be played back in the main perform loop. Actually a lot of it is working on Pd now, but there are a few functions that do reliably crash Pd, even though they're not CPU-expensive. Quite possibly some memory indiscretion. I'll report back on any further findings.
Best, Eric
On Dec 5, 2006, at 10:13 PM, Mathieu Bouchard wrote:
On Wed, 6 Dec 2006, Thomas Grill wrote:
currently there's no low-priority messaging in Miller's pd version, but there is in the devel branch. It's one of the features that have been there for some time and i'm trying to provide a patch for Miller, so that it can make it into vanilla PD some time in the future. Hopefully the auto-discard mechanism of the patch tracker will blow up before that time. Don't expect the feature to be available soon.
So, how does one use that feature?
Is it that all the audio is high-priority and all the non-audio is low-priority?
Isn't that basically the way it is now? Correct me if I am wrong, but isn't audio data processed first in each cycle, then message data?
FYI: Max since 4.3 (I believe) has two audio threads, a high priority and a low priority. "qelems" and the defer() functions give you access to the low priority thread in externals. Another detail of not is that the threads are cooperative, not pre-emptive. If a give process doesn't defer(), then it won't give up that thread until its done processing.
.hc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 12/6/06, Thomas Grill gr@grrrr.org wrote:
Hi Eric, i'm wondering how asynchronous DSP works in Max. As far as i know only messaging can be deferred.
Yes, but you can put DSP inside of a message too.
Is the DSP operation done outside the
normal DSP chain
Presumably.
or is it some DSP operations on buffer data that you
are doing in message callbacks?
I'm not doing callbacks, and am not even sure that's possible with what I'm doing, or at least not without a lot of programming pain and agony. Basically, I have two buffers with some sound in buffer #1. I'm planning at some time in the future to start playing from buffer #2. I copy the contents of buffer #1 to buffer #2 and then do all kinds of evil DSP to the contents of buffer #2, all done asynchronously from the main DSP perform loop. Hopefully by that time I'm ready to play buffer #2 the DSP is done. If not, I have to drop the playback of that event.
Best, Eric
Hallo!
Basically, I have two buffers with some sound in buffer #1. I'm planning at some time in the future to start playing from buffer #2. I copy the contents of buffer #1 to buffer #2 and then do all kinds of evil DSP to the contents of buffer #2, all done asynchronously from the main DSP perform loop.
okay, but this code don't have to be in the dsp perform loop ...
I see 2 possibilities for that:
- you can do the copy + DSP-transformation of the buffer in a seperate thread, as it is done in the [sndfiler] external
- maybe you can also do it with vasp, which is a set of externals for buffer calculation and I think they can do it also in a seperate thread
LG Georg
Basically, I have two buffers with some sound in buffer #1. I'm planning at some time in the future to start playing from buffer #2. I copy the contents of buffer #1 to buffer #2 and then do all kinds of evil DSP to the contents of buffer #2, all done asynchronously from the main DSP perform loop.
okay, but this code don't have to be in the dsp perform loop ...
I see 2 possibilities for that:
- you can do the copy + DSP-transformation of the buffer in a seperate
thread, as it is done in the [sndfiler] external
please note, that sndfiler is basically not clickfree, because it requires resorting of the dsp chain, which is not trivial, if your patch contains quite a number of dsp objects
- maybe you can also do it with vasp, which is a set of externals for
buffer calculation and I think they can do it also in a seperate thread
i guess the 'vanilla' way would be to downsample the 'evil DSP' ;)
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs
- maybe you can also do it with vasp, which is a set of externals for
buffer calculation and I think they can do it also in a seperate thread
i guess the 'vanilla' way would be to downsample the 'evil DSP' ;)
Horrors! That would take the edge off the evil :-[=]
Eric
On Wed, 6 Dec 2006, Tim Blechmann wrote:
please note, that sndfiler is basically not clickfree, because it requires resorting of the dsp chain, which is not trivial, if your patch contains quite a number of dsp objects
Does it really need re-sorting the dsp chain, or could the compiled dsp be only slightly modified? Doesn't it only need to change the array pointers in it?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 2006-12-06 at 12:24 -0500, Mathieu Bouchard wrote:
On Wed, 6 Dec 2006, Tim Blechmann wrote:
please note, that sndfiler is basically not clickfree, because it requires resorting of the dsp chain, which is not trivial, if your patch contains quite a number of dsp objects
Does it really need re-sorting the dsp chain, or could the compiled dsp be only slightly modified? Doesn't it only need to change the array pointers in it?
yes, you just need to change the pointer to the array. however, they are stored directly in the dsp chain. i proposed some changes, even changes, that are not changing the binary compatibility of garray_getfloatarray. i guess, you can find some of them, in the archives... asynchronous buffer operations are not a problem in pnpd, though ;)
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
Yes, that sounds exactly like what VASP was designed to do. I guess the trick would be determining whether the operation is complete before playing the buffer? Or does VASP do that? (I don't use it.)
~Kyle
On 12/6/06, Georg Holzmann grhPD@gmx.at wrote:
Hallo!
Basically, I have two buffers with some sound in buffer #1. I'm planning at some time in the future to start playing from buffer #2. I copy the contents of buffer #1 to buffer #2 and then do all kinds of evil DSP to the contents of buffer #2, all done asynchronously from the main DSP perform loop.
okay, but this code don't have to be in the dsp perform loop ...
I see 2 possibilities for that:
- you can do the copy + DSP-transformation of the buffer in a seperate
thread, as it is done in the [sndfiler] external
- maybe you can also do it with vasp, which is a set of externals for
buffer calculation and I think they can do it also in a seperate thread
LG Georg
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Am 06.12.2006 um 18:07 schrieb Kyle Klipowicz:
Yes, that sounds exactly like what VASP was designed to do. I guess the trick would be determining whether the operation is complete before playing the buffer? Or does VASP do that? (I don't use it.)
VASP will output a message only after completing an operation.
best, T
-- Thomas Grill http://grrrr.org
Eric Lyon wrote:
Thank you Thomas, hc and others for helpful feedback. The function I'm deferring is doing asynchronous DSP, not messaging. Essentially a
hi. since pd-0.40 you can do DSP-on-demand, by banging the [switch~] object. i have not tested, but it might be, that this DSP-operation is in the message queue. while i doubt that it is a good idea to put dsp-on-demand operations into a separate thread with the currently available means ([detach]/[join]), it might get you into the right direction.
mfg.adsr IOhannes
Georg Holzmann wrote:
Hallo!
since pd-0.40 you can do DSP-on-demand, by banging the [switch~] object. i have not tested, but it might be, that this DSP-operation is in the message queue.
what do you mean by that ?
by what? there are 2 parts which might be problematic.
mfg.adr IOhannes