Hello,

I need to plot array contents for signal visualisation in a GEM window. GEM runs in a -noaudio Pd instance to save CPU time, therefore I can not use [scopeXYZ~], and the signal points will be received from the audio process as list or table.

This topic has been discussed earlier, and I have tried solutions from ding, saturno and pdmtl library. These solutions are all very CPU intensive. For each GEM frame, hundreds of points must be individually handled by message objects, causing a huge function call overhead.

So I wonder, is there no method using a GEM object or openGL function which can read the content of a one-dimensional array at once and process data? One way or another, it should be as efficient as [scopeXYZ~], not spend 3% cpu time on each small scope trace.

Katja

Just a thought; do you think that there is a significant CPU load caused by eliminating the -noaudio flag? If this instance is only responsible for one or two [scopeXYZ~] maybe that will be a good short term fix if it doesn't burden the GUI CPU load too much.

How does PD react to computing DSP with 0 output channels I wonder?

Hey Ponzo, thanks for your suggestion!

It may be different for each OS, but on my macbook an additional Pd instance does 10% CPU load in idle state and with dsp on. The first instance does 15 - 20% in idle state and with dsp on. When I use an external audio interface these figures become more friendly. Anyhow it is clearly advantageous to start a Pd with -noaudio if dsp is not needed.

And now for Ponzo's hint: indeed, if input- and output device are unchecked in the audio preferences, CPU load for the instance is reduced to the modest 1% that a -noaudio Pd normally does when idle. Meaning, the high CPU load is merely for interfacing with the soundcard, even if there is nothing in the dsp chain. So, if I can automatically uncheck the I/O devices somehow when loading the patch for the GEM window in a new Pd instance, that would be great. Thanks Ponzo, this saves me another day of puzzling.

Still, it would be nice to (someday) find an efficient way of inserting an array plot in GEM, don't you agree?

Katja

update: I can inactivate I/O devices with this message to pd:

[audio-dialog 0 0 0 0 -2 0 0 0 0 0 0 0 -2 0 0 0 44100 20 0(
|
[send pd]

Don't know if it works the same for all systems / audio drivers (I'm on OSX). Audio settings can be found with help of abstraction [hcs/get-audio-dialog].

This looks sneaky and effective. We can all agree that support for multi core processors would be terrific. I hope that these kinds of work-arounds may have a way of making it into the next pd-extended release so that it can be "marketed" as having "multi-core" support.

Even if it's just an object that starts another instance of PD while the help-file explains why this may be useful and raises the issue discussed above and the other problems that are sure to arise.

@PonZo: [pd~] is, in part, meant to allow multi-core support, but it's still in the early stages.

@katjav: Thanks for posting that! I remember reading a while ago that a surprisingly large part of Pd's cpu usage had to do with the way it deals with audio drivers (can't remember if it was a portaudio or a OSX problem), but it never occurred to me that "disconnecting" it from the I/O could solve that.

Hello:
Is there any way of getting the UML ("Unified Modelling Language) for Pd / Pd-extended? With that guide, we may be able to sneak into the code and see which messages are correct for connecting / disconnecting audio devices. Moreover, we can write a serious and complete documentation for getting the most of this great tool. Otherwise, it will be very difficult to understand the code if one is not a professional programmer.
Best regards,

Sumidero

I believe IOhannis is working on some objects to make communication with audio devices and settings easier. Hopefully it won't be too long. It would be nice to be able to select a device by name from within a patch.

By the way, you can also see some of the messages to Pd by putting something like this is the patch:

[r pd]
|
[print]

You won't see all the messages you can use ([donecanvasdialog( doesn't show up when you change the canvas properties) but a few of them show up. Changing the audio properties dialog, for example, sends the [audio-dialog( message katjav pointed out.

so, you want to plot the content of an array which is located in the -audio pd instance in the -noaudio instance? am i right?
how could you access that array other than with netsend / netreceive quasi in serial fashion?

@sonsofsol said:

how could you access that array other than with netsend / netreceive quasi in serial fashion?

It may not be possible to do it another way than serial. Here is what I did: capture the samples as a list with [pack~], prepend an OSC tag with [list-abs/OSCprepend] and send with [mrpeach/udpsend]. In the receiving patch, the list can be stored in an array with [zexy/tabset]. I noticed that sending all samples of an audiosignal as lists over udp is very CPU intensive. It would be useful to downsample first and make a scopetrace with not too fast refresh rate.

Anyway, for the moment I use [mrpeach/udpsend~] and [mrpeach/udpreceive~] to get the scopetrace from the audio patch into the GUI patch. [scopeXYZ~] is very efficient, it can work with the highest possible refresh rate, almost without noticeable CPU load. Think it's unbeatable for this purpose. But for other purposes an array plot in GEM could be useful. For example, to plot a static waveform.

Katja