Hi,
I always thought that in PD, "process" (i.e. dsp and control processing) had the priority over GUI rendering, in such a way that drawing the gui would NEVER cause audio clicks although this means there's no warranty about how much gui rendering may be delayed.
To my great disappointment, I see that when opening a subpatch with a lot of gui, audio clicks are produced. Just opening it, i.e., right-clicking on it and "open" (or just left-clicking when not in edit mode) Not to mention moving around a "big" GOP-enabled object (or, I guess, a handful of gui elements at the same time). But the first one seems to me a much more severe problem.
Suppose you have a large application (for a performace, for example) with a lot of controllers and display that you may only occasionally need. So you have your main interface (i.e. most important elements you need to see all the time) in your main window, and lots of less critical displays and controllers inside subpatches or instances of abstractions. When you need to check out or move a display or controller, you click on the subpatch (or even abstraction) to show up the controllers it contains. This is just not possible because when you do that, you suddenly get a second of silence (if the subpatch you open contains more than a couple of sliders), as audio processing holds on while drawing the gui.
Do you know of any workarounds? Do you know if this is Windows-specific?
This is indeed another example of what I was talking about in my previous message under the "puredata evolution" thread.
Thanks m.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Prestiti Online. Scopri subito se sei finanziabile. in 24 ore senza spese né anticipi, clicca qui
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2908&d=4-6
On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
Hi,
I always thought that in PD, "process" (i.e. dsp and control processing) had the priority over GUI rendering, in such a way that drawing the gui would NEVER cause audio clicks although this means there's no warranty about how much gui rendering may be delayed.
Do you know of any workarounds? Do you know if this is Windows-specific?
no, i don't know of any workarounds. no, this is not windows specific.
there are other issues as well, which cause drop outs, that might be avoidable:
- reading/saving files to/from disk
- dynamic object creation
- full buffer of [netsend]
(maybe there are some more)
all this issues cannot be 'worked around' within pd, which makes pd sometimes not very suitable for presenting/live situations. netpd suffers heavily from all the issues above (including the one you mentioned). i do believe, that some of them could be solved (e.g. for [netsend] it would be already enough to provide an additional outlet, that sends a bang, whenever its buffer is emptied). others might be not that easy to overcome. i think, it would be great and mean a big step for pd, if this issues could be addressed.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
Hi,
I always thought that in PD, "process" (i.e. dsp and control processing) had the priority over GUI rendering, in such a way that drawing the gui would NEVER cause audio clicks although this means there's no warranty about how much gui rendering may be delayed.
Do you know of any workarounds? Do you know if this is Windows-specific?
no, i don't know of any workarounds. no, this is not windows specific.
there are other issues as well, which cause drop outs, that might be avoidable:
- reading/saving files to/from disk
Yes, this one gets me very often. To be clear, I'm not referring to loading *sound* files. Just regular reads of non-sound files will cause dropouts. For live performance, it is necessary to pre-load everything to avoid this, which is very inconvenient and not conducive to spontaneity.
I'm wondering if the threaded [sndfiler] object could be adapted to help with this particular problem. Apparently, it doesn't work so well for soundfiles (please correct me if I'm wrong), because the dsp tree needs to be rebuilt anyway, causing dropouts. However, could it work as a way of loading normal files without glitching the audio output?
Phil Stone
On Tue, 2007-06-05 at 07:41 -0700, Phil Stone wrote:
I'm wondering if the threaded [sndfiler] object could be adapted to help with this particular problem. Apparently, it doesn't work so well for soundfiles (please correct me if I'm wrong), because the dsp tree needs to be rebuilt anyway, causing dropouts.
correct me as well, if i am wrong, but there shouldn't be a need for rebuilding the dsp tree when loading a soundfile using [sndfiler], since it just copies data from disk/soundfile to memory/table. the dsp tree should stay the same. perhaps the same approach would work for [textile] and other harddisk accessing objects as well?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Tue, 2007-06-05 at 17:00 +0200, Roman Haefeli wrote:
On Tue, 2007-06-05 at 07:41 -0700, Phil Stone wrote:
I'm wondering if the threaded [sndfiler] object could be adapted to
help
with this particular problem. Apparently, it doesn't work so well
for
soundfiles (please correct me if I'm wrong), because the dsp tree
needs
to be rebuilt anyway, causing dropouts.
correct me as well, if i am wrong, but there shouldn't be a need for rebuilding the dsp tree when loading a soundfile using [sndfiler], since it just copies data from disk/soundfile to memory/table. the dsp tree should stay the same.
don't tell this to me, tell this to miller ;)
without these architecture design problem a threaded sndfiler for pd is as trivial to implement for nova ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
On Tue, 2007-06-05 at 17:16 +0200, Tim Blechmann wrote:
On Tue, 2007-06-05 at 17:00 +0200, Roman Haefeli wrote:
On Tue, 2007-06-05 at 07:41 -0700, Phil Stone wrote:
I'm wondering if the threaded [sndfiler] object could be adapted to
help
with this particular problem. Apparently, it doesn't work so well
for
soundfiles (please correct me if I'm wrong), because the dsp tree
needs
to be rebuilt anyway, causing dropouts.
correct me as well, if i am wrong, but there shouldn't be a need for rebuilding the dsp tree when loading a soundfile using [sndfiler], since it just copies data from disk/soundfile to memory/table. the dsp tree should stay the same.
don't tell this to me, tell this to miller ;)
sorry, i didn't mean to tell how things should be, i just thought i'm telling how things actually are. you mean, the dsp tree is resorted after loading a soundfile into a table?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Tue, 2007-06-05 at 17:26 +0200, Roman Haefeli wrote:
correct me as well, if i am wrong, but there shouldn't be a need
for
rebuilding the dsp tree when loading a soundfile using [sndfiler], since it just copies data from disk/soundfile to memory/table. the dsp
tree
should stay the same.
don't tell this to me, tell this to miller ;)
sorry, i didn't mean to tell how things should be, i just thought i'm telling how things actually are. you mean, the dsp tree is resorted after loading a soundfile into a table?
unfortunately this is the case ... i proposed a workaround that would have been compatible with the public api of pd a few years ago ... i guess, you can find details in the pd-dev archives ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs
I'm wondering if the threaded [sndfiler] object could be adapted to help with this particular problem. Apparently, it doesn't work so well for soundfiles (please correct me if I'm wrong), because the dsp tree needs to be rebuilt anyway, causing dropouts. However, could it work as a way of loading normal files without glitching the audio output?
loading a soundfile in the background is trivial ... just the way the pd interpreter uses them (instantiate a patch / resort the dsp chain) isn't realtime safe ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww! Jack Kerouac
On 6/5/07, Tim Blechmann tim@klingt.org wrote:
loading a soundfile in the background is trivial ... just the way the pd interpreter uses them (instantiate a patch / resort the dsp chain) isn't realtime safe ...
Even applications like Logic do not create new audio threads while audio is running. Once audio is stopped the tree is resorted and the load balanced between threads.
On Tue, 2007-06-05 at 10:26 -0500, chris clepper wrote:
On 6/5/07, Tim Blechmann tim@klingt.org wrote:
loading a soundfile in the background is trivial ... just the way the pd interpreter uses them (instantiate a patch / resort the dsp chain) isn't realtime safe ...
Even applications like Logic do not create new audio threads while audio is running. Once audio is stopped the tree is resorted and the load balanced between threads.
there are applications which are able to load soundfiles in a realtime-safe way. there are even applications which can manipulate the dsp graph while running audio without dropouts ... as nova supports both, i can say, it's quite easy if the architecture is well designed ..
t
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Linux is like a wigwam: no windows, no gates, apache inside, stable.
Tim Blechmann wrote:
there are applications which are able to load soundfiles in a realtime-safe way.
see, for example, ableton live
Hi Matteo,
On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
I always thought that in PD, "process" (i.e. dsp and control processing) had the priority over GUI rendering, in such a way that drawing the gui would NEVER cause audio clicks although this means there's no warranty about how much gui rendering may be delayed.
To my great disappointment, I see that when opening a subpatch with a lot of gui, audio clicks are produced. Just opening it, i.e., right-clicking on it and "open" (or just left-clicking when not in edit mode) Not to mention moving around a "big" GOP-enabled object (or, I guess, a handful of gui elements at the same time). But the first one seems to me a much more severe problem.
Do you know of any workarounds? Do you know if this is Windows-specific?
I haven't experienced this problem myself because I hardly use any GUI stuff in performance. However, one way to avoid it might be to run two instances of PD, one for the GUI, and one in -nogui mode, and use some network protocol (OSC, FUDI), to send data between them. That way you have your GUI and audio processing running as seperate processes in the OS. At least on *n*x you can then optionally assign a priority to each process using something like 'nice'.
Jamie
-
chris clepper -
Damian Stewart -
Jamie Bullock -
Matteo Sisti Sette -
Phil Stone -
Roman Haefeli -
Tim Blechmann