Hi there,
I recently built a midi CC sequencer abs. It helps me add some timeline-based control to my patches. But I came across a problem I never had to deal with before: CPU consumption. I realized I could'nt use more than four instances of my sequencer before the patch would become unmanageable (interface freezes, audio drops, and, finally... a crash) I think this is related to the use of large size arrays. I would be grateful if someone out there could point me to a better data storing/ CPU saving strategy for my sequencer, maybe data structures? Thanks in advance.
D.S
http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/
You can save some power by putting your arrays into tables so you can't see them. On my system, drawing graphical elements like that takes alot of power.
On Sun, Aug 1, 2010 at 5:35 AM, David Schaffer schafferdavid@hotmail.com wrote:
Hi there,
I recently built a midi CC sequencer abs. It helps me add some timeline-based control to my patches. But I came across a problem I never had to deal with before: CPU consumption. I realized I could'nt use more than four instances of my sequencer before the patch would become unmanageable (interface freezes, audio drops, and, finally... a crash) I think this is related to the use of large size arrays. I would be grateful if someone out there could point me to a better data storing/ CPU saving strategy for my sequencer, maybe data structures? Thanks in advance.
D.S
http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The problem is... the arrays HAVE to be visible AND accessible to the mouse, it's part of the abs. concept: you have to be able to draw your own graphics using the mouse. Otherwise, youre solution sure works!
D.S
From: "Cody Loyd" codyloyd@gmail.com Sent: Sunday, August 01, 2010 3:21 PM To: pd-list@iem.at Subject: Re: [PD] CPU saving strategies
You can save some power by putting your arrays into tables so you can't see them. On my system, drawing graphical elements like that takes alot of power.
On Sun, Aug 1, 2010 at 5:35 AM, David Schaffer schafferdavid@hotmail.com wrote:
Hi there,
I recently built a midi CC sequencer abs. It helps me add some timeline-based control to my patches. But I came across a problem I never had to deal with before: CPU consumption. I realized I could'nt use more than four instances of my sequencer before the patch would become unmanageable (interface freezes, audio drops, and, finally... a crash) I think this is related to the use of large size arrays. I would be grateful if someone out there could point me to a better data storing/ CPU saving strategy for my sequencer, maybe data structures? Thanks in advance.
D.S
http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/
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
hello
On 1 August 2010 18:06, David Schaffer schafferdavid@hotmail.com wrote:
The problem is... the arrays HAVE to be visible AND accessible to the mouse, it's part of the abs. concept: you have to be able to draw your own graphics using the mouse.
the arrays being visible alone should't cause excessive cpu consumption, but if you built a mechanism that refreshes the content of those (visible) arrays, then it could happen..
i haven't seen your patch, so i can not tell you more, but, generally, using many GUI objects at a high refreshing rate, may cause tremendous cpu consumption, since pd lacks the option for hardware acceleration for graphics, as i recently learned from this list.
alabala
On Sun, 1 Aug 2010, ypatios wrote:
the arrays being visible alone should't cause excessive cpu consumption, but if you built a mechanism that refreshes the content of those (visible) arrays, then it could happen..
Also, much of that refresh may not be visible in the "Load Meter" patch and [cputime] in general, because much of the job is NOT done in the main thread (nor any other threads that may be associated with [cputime]).
i haven't seen your patch, so i can not tell you more, but, generally, using many GUI objects at a high refreshing rate, may cause tremendous cpu consumption, since pd lacks the option for hardware acceleration for graphics, as i recently learned from this list.
Using Linux as an example, Pd uses Tk, Tk uses X11, and X11 uses hardware acceleration. It may just not be the same kind of hardware acceleration that you have in mind. OpenGL is not the only interface to what can be considered to be hardware acceleration. (one can make a similar argument about other OSes as well).
I know that Tk redraws way too many things that it shouldn't have to redraw, but then GL usually makes even more useless redraws than that. The problem is probably about HOW MANY things are being covered by the hardware acceleration that is in use, vs how many are still computed by the CPU.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hi,
On Sun, Aug 01, 2010 at 12:35:41PM +0200, David Schaffer wrote:
I recently built a midi CC sequencer abs. It helps me add some timeline-based control to my patches. But I came across a problem I never had to deal with before: CPU consumption. I realized I could'nt use more than four instances of my sequencer before the patch would become unmanageable (interface freezes, audio drops, and, finally... a crash) I think this is related to the use of large size arrays. I would be grateful if someone out there could point me to a better data storing/ CPU saving strategy for my sequencer, maybe data structures? Thanks in advance.
You're using way too many debugging GUIs, like [bng] or number boxes. Remove all of them that you don't see and optionally speedlimit the updates of those, that you want to see. [m_speedlimit] from rj (http://github.com/rjdj/rjlib) can be used for speedlimiting.
In general, never patch debuigging stuff like this:
[...] | [0\ <- a numberbox | [...]
or this:
[...] | [bng] <- a GUI bang | [...]
Instead always put the debugging GUIs into their own path like here:
[...]
|
| [0\ <- a numberbox
|
[...]
This way it's easier to remove them later, when you're finished debugging your patch. Make that a habit.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Thanks for your advices Franck, these are the kind of programming tips I was looking for.
David
http://www.flickr.com/photos/schafferdavid/
http://audioblog.arteradio.com/David_Schaffer/
Date: Mon, 2 Aug 2010 13:02:00 +0200 From: fbar@footils.org To: pd-list@iem.at Subject: Re: [PD] CPU saving strategies
Hi,
On Sun, Aug 01, 2010 at 12:35:41PM +0200, David Schaffer wrote:
I recently built a midi CC sequencer abs. It helps me add some timeline-based control to my patches. But I came across a problem I never had to deal with before: CPU consumption. I realized I could'nt use more than four instances of my sequencer before the patch would become unmanageable (interface freezes, audio drops, and, finally... a crash) I think this is related to the use of large size arrays. I would be grateful if someone out there could point me to a better data storing/ CPU saving strategy for my sequencer, maybe data structures? Thanks in advance.
You're using way too many debugging GUIs, like [bng] or number boxes. Remove all of them that you don't see and optionally speedlimit the updates of those, that you want to see. [m_speedlimit] from rj (http://github.com/rjdj/rjlib) can be used for speedlimiting.
In general, never patch debuigging stuff like this:
[...] | [0\ <- a numberbox | [...]
or this:
[...] | [bng] <- a GUI bang | [...]
Instead always put the debugging GUIs into their own path like here:
[...] |
| [0\ <- a numberbox | [...]This way it's easier to remove them later, when you're finished debugging your patch. Make that a habit.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
updating some numberboxes shouldnt cause audio interrupts, this is really the downside of PD. Is there any hope to rectify this situation to make it behave better in low latency conditions? I know it basically mean a rewrite of the whole thing but are there any initiatives?
Cheers,
Malte
On Mon, 2 Aug 2010, Malte Steiner wrote:
updating some numberboxes shouldnt cause audio interrupts, this is really the downside of PD. Is there any hope to rectify this situation to make it behave better in low latency conditions? I know it basically mean a rewrite of the whole thing but are there any initiatives?
sounds like you are not using the -rt option in your startup flags ?
can you get it to work ?...
(you have to restart pd after you saved the settings)
be careful with this feature.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
I am using the -rt option but encounter DIO errors on editing larger tables like the original poster, on Archlinux with realtime kernel and Jack in mild low latency conditions, 16ms. No Xruns, just the DIO. But when I use Alsa as backend it gets better!
A modern system should be able to handle multimedia like video and 3D plus GUI without interrupts in the audio stream. The separation from Backend and GUI Frontend in PD is leaving a bit to desire and my question if its possible to solve this, in maybe 10 years or so? Or will the new thread object help?
Anyway, PD was the star in my lecture about Linux Audio yesterday, resulting in the most interest and questions.
Cheers,
Malte
media art + development http://www.block4.com
new on iTunes: Notstandskomitee Automatenmusik http://itunes.apple.com/us/album/automatenmusik/id383400418
On Tue, 3 Aug 2010, Malte Steiner wrote:
A modern system should be able to handle multimedia like video and 3D plus GUI without interrupts in the audio stream.
That may be 1, 2 or 3 separate problems (it depends on how you try to solve it).
The main thread currently runs everything except Tk, which means that any visuals running in the main thread (GF,GEM,PDP) running at 30 fps can cause up to 33.3333 ms of latency when CPU usage < 100%. Generally, producing N fps can introduce up to 1000/N ms of latency.
Splitting signals vs the rest, can cause problems with anything that uses more than just signals to do its audio. It's a non-solution : it introduces so many new problems at once. You have to do an audio vs video split, ideally (because it's a split according to variation of needs of latency). And in such a case, part of the message-system has to run in lockstep with the signal-system, while another part of the message-system has to run in lockstep with the video output.
The separation from Backend and GUI Frontend in PD is leaving a bit to desire and my question if its possible to solve this, in maybe 10 years or so?
I haven't met anyone willing to address that problem, ever.
(Note that the video and 3D subsystems are not usually considered to be part of the frontend)
Or will the new thread object help?
which one ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, Aug 6, 2010 at 1:12 PM, Mathieu Bouchard matju@artengine.ca wrote:
The separation from Backend and GUI Frontend in PD is leaving a bit to desire and my question if its possible to solve this, in maybe 10 years or so?
I haven't met anyone willing to address that problem, ever.
Besides you? To be fair, I think that Tim Blechman was, wasn't he? Or maybe I have wrong recollection. Isn't that the reason he branched off with his Nada or Nova, or whatever it was called, project?
./MiS
Tim's SuperNova? It's a multi-core aware SuperCollider branch that is going to be merged to the main SuperCollider very soon
2010/8/7 Michal Seta mis@artengine.ca:
On Fri, Aug 6, 2010 at 1:12 PM, Mathieu Bouchard matju@artengine.ca wrote:
The separation from Backend and GUI Frontend in PD is leaving a bit to desire and my question if its possible to solve this, in maybe 10 years or so?
I haven't met anyone willing to address that problem, ever.
Besides you? To be fair, I think that Tim Blechman was, wasn't he? Or maybe I have wrong recollection. Isn't that the reason he branched off with his Nada or Nova, or whatever it was called, project?
./MiS
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, Aug 7, 2010 at 6:55 PM, Bernardo Barros bernardobarros2@gmail.com wrote:
Tim's SuperNova? It's a multi-core aware SuperCollider branch that is going to be merged to the main SuperCollider very soon
Ah, cool. IIRC, the first experiments were based on a branch of pd. Also, I believe that the patching syntax was based somewhat on the FUDI and used Pd-named UGens, although it was text based. But the only time I looked at it was in the first months of development which was probably a good 5-6 years ago and I have not followed the development of (Super)Nova.
Thanks for the heads up however, I didn't know that the project was still alive.
./MiS
On Sun, 8 Aug 2010, Michal Seta wrote:
Ah, cool. IIRC, the first experiments were based on a branch of pd.
It wasn't a branch, it was a pd-like software that offered zero compatibility with pd, and contained about zero % of code in common.
But the only time I looked at it was in the first months of development which was probably a good 5-6 years ago
PNPD version 0.00 was announced in december 2006, then had been renamed to Nova by march 2007.
and I have not followed the development of (Super)Nova. Thanks for the heads up however, I didn't know that the project was still alive.
I don't think that it's the same project at all. I mean, it surely has some ideas in common, but I suppose that it's a nearly-restart-from-scratch of those ideas, because Nova had completely its own architecture, with no interfaces in common with SC3 nor Pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sat, 7 Aug 2010, Michal Seta wrote:
On Fri, Aug 6, 2010 at 1:12 PM, Mathieu Bouchard matju@artengine.ca wrote:
The separation from Backend and GUI Frontend in PD is leaving a bit to desire and my question if its possible to solve this, in maybe 10 years or so?
I haven't met anyone willing to address that problem, ever.
Besides you?
I did make an elaborate attempt to move the GUI's server code to the client side, but it was not directly for reasons of avoiding dropouts. My code probably could have been a basis for an easier control of dropouts related to GUIs, but I just didn't explicitly work on reducing dropouts.
To be fair, I think that Tim Blechman was, wasn't he?
AFAIR, Grill & Blechmann worked on reducing the CPU usage of Pd through SIMD and FFTW3. Both modifications were rejected by Miller. Both of those help reducing dropouts and latency indirectly, simply to the extent that using the CPU more efficiently can achieve that. Blechmann also made a threading external for the message-system.
Or maybe I have wrong recollection. Isn't that the reason he branched off with his Nada or Nova, or whatever it was called, project?
Grill, Blechmann and Zmölnig had branched devel_0_37 and later devel_0_39, and when too few elements of devel_0_39 were merged back into vanilla, Blechmann decided to leave and started PNPD ("PNPD is Not Pure Data", recursive acronym), and this is by no means a "branch" or "fork" of anything at all.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Bernardo Barros -
Cody Loyd -
David Schaffer -
Frank Barknecht -
Malte Steiner -
Mathieu Bouchard -
Michal Seta -
ypatios