In Pd vanilla, how does one query whether DSP is on or off?

I know you can send messages to "pd" to turn signal processing on or off, but I can't find where to ask the current status. (By the way, the search facility on this forum is really excruciating -- I did search this topic but you get hundreds of "matches" with apparently no concern for relevance at all.)

Context: I quite like the output~ abstraction in Purr Data, so I was seeing if it was possible to use it in Pd vanilla, but it complains about no [pdinfo] object. I can't find which external supplies this object. I'd be satisfied with an answer "install this external" or "here's the other way to query DSP state."

Thanks.

hjh

@ddw_music Maybe this could help:

That's an interesting idea, but... 687 status checks per second (assuming 44.1 kHz and 64 samples per block) strikes me as excessive.

Finally tracked down that Purr Data's [output~] is a revised version of PDDP [ezoutput~]. It turns out that [ezoutput~] can follow DSP status changes after the object already exists ([receive pd] --> [route dsp]) but if DSP is turned on when an [ezoutput~] object is created or loaded in a patch, it doesn't detect this and the DSP toggle box shows "off" even if it's really on.

So I suppose the answer to my question is:

• At the moment of loading a patch, you can't know if DSP is on or off. (But, perhaps the [bang~] trick could be adapted to check once and then stop.)

• After the patch is loaded, [receive pd] will tell you about any subsequent DSP status changes.

hjh

This does the trick, I think.

@Balwyn said:

This does the trick, I think.

True, except initial status upon loading a patch.

hjh

@ddw_music Put [loadbang] into the trigger to check as the patch is opened.
[set 0( required for a new "check" because when dsp is stopped [snapshot~] holds its last value (always 1 in this case).
[delay] required as we need to wait for the next audio block when the [snapshot~] value is reset by audio (or not).
The [delay] needs to be more than 1.45ms at a block size of 64 @ 44.1KHz to be sure of the reset.
David.

check_dsp.pd

@whale-av said:

@ddw_music Put [loadbang] into the trigger to check as the patch is opened.

Hmm, very nice. Learned a few tricks here.

Thanks!
hjh

and here is yet another way, using [sgn~] and [avg~] in a subpatch to determine whether the dsp is on and [switch~] to disable the audio use after the notification
dsp-check.pd

[pdinfo] object

This is a built-in class in Purr Data. It took 5 minutes to write the method that fetches the dsp state and maybe 10 minutes for us to discuss any gotchas.

By using that simple method in Purr Data's "output~" abstraction all of the gotchas of the various workarounds in this thread simply go away.

@jancsika said:

This is a built-in class in Purr Data. It took 5 minutes to write the method that fetches the dsp state and maybe 10 minutes for us to discuss any gotchas.

Well... you're hinting at the broader point: namely, rather serious usability gaps in Pd vanilla.

These gaps force serious Pd users to be highly creative about finding workarounds (I wouldn't have thought of setting a snapshot, waiting a tick for DSP to overwrite it, and then banging the result) -- but there is a point where the unwillingness to add a simple way into the platform becomes a bit masochistic.

See also https://forum.pdpatchrepo.info/topic/12460/brown-noise-generator/5 -- "I have wondered why Pd doesn't seem to have more of these types of primitives in the standard library (i.e. [pink~] [grey~] [brown~] [jitter~] etc)." It's exactly the same question (by someone else, not me), in a different context.

hjh

@ddw_music because of that there are a lot of libraries and abstractions. i think a concept of pure data vanilla is to have only a few basic objects, and everything (most of it) can be build with it, or with the help of libraries. if you have an abstraction for brown noise and dsp-status for example, than it is basically one object for each plus you can change something easily without touching the source code. of course there is always something that can be improved, but i think pure data improved a lot the last years. for example with the [text] object and the new [array] and [list] methods. you can even undo more than one step now i am not involved in the development, but you can surely join the mailing list or at github: https://github.com/pure-data/pure-data/issues

@Jona A brown noise abstraction is a great example of what you're describing-- using a small core set of objects to build more sophisticated functionality. One could use the same design for various noise-related abstractions and roll them into a nice external library that is modular and easy to reason about.

Outputting dsp status is not a great example, however. Introspection of something as central as dsp computation is a missing core feature. The abstractions provided here are buggy and difficult to reason about. The proliferation of various buggy workarounds wastes both the time of users and developers.

Even worse, such workarounds add noise to the discussions that end up making it more difficult to get missing features included in Pd Vanilla. Once a user requested it we added the "clear" method to delwrite~ in Purr Data quite quickly. In Pd Vanilla it took a) a patch, an argument about the patch, c) an argument about Pd Vanilla's dev process, d) the patch sitting for years, e) another argument, f) a proposed workaround so difficult to reason about that one developer familiar with Pd's externals couldn't completely understand it, g) more pleading from other users, and finally h) a reluctant merging of a single trivial patch to the core. I don't think asceticism requires a development process like that.

@jancsika good points, I agree. By the way, in Ofelia is an object called [ofGetDspState]. Getting mouse coordinates without externals is another example, there are some vanilla solutions, for example https://forum.pdpatchrepo.info/topic/10854/xy-abstraction-to-get-mouse-click-and-drag-coordinates-vanilla and some externals like [mouse] from else. I asked myself why there is not a simple object for mouse coordinates in vanilla (I think it still would be nice), on the other hand i am fine with using a (workaround) abstraction or an external if it is not basic enough or not needed from enough people. I can imagine that it is difficult to decide what is really important for Pure Data vanilla.

i think a concept of pure data vanilla is to have only a few basic objects, and everything (most of it) can be build with it, or with the help of libraries

Sure, I understand this, and I understand that every audio environment will, sooner or later, present obstacles for incoming users. I'm suggesting that the obstacles come up more quickly in Pd. To be concrete, if the new SuperCollider user is looking for a resonant low pass filter (not an exotic requirement), she goes to the main help page and from there, there are multiple paths through the documentation to find the answer RLPF.ar -- a built-in UGen that works like you'd expect.

By contrast, Pd has [biquad~], which "formally" does it but then... where is the coefficient calculator? Oh... I already forgot. And it takes the coefficients as a list, so you can't modulate at audio rate (so forget about filter envelopes or LFOs). So you give up and ask the forum, and wait a few hours for a reply. (Eventually I ended up with [omniFilter_abs~] based on MMB abstractions.)

I can accept that there's always going to be a difference of opinion about what is a "basic" feature. I guess I shouldn't push too hard because Pd isn't my main axe -- I'm using it for teaching because I need graphics for fall semester a year from now, but I don't use it for my own projects because I would rather build on top of a richly-featured framework than rebuild on top of a (deliberately) minimal feature set. So I should probably back off. At the same time, I get the feeling the experienced Pd user community might sometimes underestimate the degree of frustration felt by knowledgeable audio programmers coming to this platform and finding many, many basic things to be difficult.

hjh

Should also say: I'm writing deliberately provocatively. I've actually enjoyed digging into a different way of thinking in Pd, and the students take to it better than to code. GEM is fun, and Ofelia is even fun-ner. Just, no harm in noting where it could improve. (And, I did notice the comment about [text] -- tried it here a couple of weeks ago, much nicer than previous sequencing options.)

Thanks for listening.
hjh

@ddw_music thanks for your explanations. "....better than to code" actually that was a reason why i started with pure data. slowly i get a understanding of text based programming too. and there are definitely things that are much more efficient with text based programming. still pure data is my main programming language, and i think even if i would be really good at text based programming i would still use pure data regularly, because it is easy to use for certain things. i do not know how experienced programmers think about that... and i can not compare it to super collider, because i have no experience with it.
i am also more into sequencing than audio synthesis, but there are some more basic filters (in the audio filters section) if you open "list of all objects", and in the pure data doc are some more complex ones like H13.butterworth.pd. some of the doc filter examples are explained in more detail in this book, starting at page 256: http://msp.ucsd.edu/techniques/latest/book.pdf
and i have the feeling that open frameworks for example is at least not better documented, while lua is documented quite well (perhaps because there is a bigger userbase?). of course it would be nice to have a pure data library database where you can search for vocoder for example, and it shows all available vocoder objects and the corresponding libraries.
there is only a very old list as far as i know: http://blazicek.net/list_of_pure_data_objects.html
and of course suggestions to improve pure data, or anything else, are always very welcome.
so your main audio programming language is super collider?
can i ask what you use for graphics programming besides GEM and Ofelia?

jona

@ddw_music This is going to be a long thread.
[biquad~] was easy in extended.
Trying to convert a massive patch to vanilla I collated this.... stuff-coefficients.zip
Some calcs done at signal rate, others not.
Obviously strayed or I might have something more useful.
David.

@Jona "....better than to code" actually that was a reason why i started with pure data.

Sure -- different people have different cognitive styles, which is why it's good to have multiple tools with different approaches. I had a couple of students who really took to Pd, which never happened in the classroom with SuperCollider for me -- and that's more important to me than my own personal biases.

I can also see that some of what I'm experiencing with Pd is simply lack of fluency -- such as, there are efficient and inefficient ways to express complex math expressions in data flows. I simply haven't practiced those skills, so of course my perception is going to be that "it's really hard." (In SC, wiring up GUIs is admittedly harder than in Pd.)

so your main audio programming language is super collider?

Yes. Features that I feel are better developed in SC than in other audio programming environments are: polyphony (and parallel signal graphs -- not the same as parallel processing btw), glitch-free instantiation of audio UGens, and feature-complete implementations of standard data structures (multidimensional arrays whose elements are "variant" types, hash tables, queues and linked lists). These data structures have been invaluable in my big project over the last few years (a live-coding dialect for SC).

On the downside, both synthesis and GUIs are "heavy" in that there's more background involved -- hslider --> [osc~] is easy, SC sliders are not exactly hard to use, but more to learn at the beginning. So a lot of potential users probably give up.

of course it would be nice to have a pure data library database where you can search for vocoder for example, and it shows all available vocoder objects and the corresponding libraries.

Indeed... but maintaining such a list is a huge effort. SC has the same problem with third-party UGen plug-ins and class library extensions -- some great stuff out there, but how do you find it?

can i ask what you use for graphics programming besides GEM and Ofelia?

I've done almost nothing with graphics (no time), so only those two.

hjh

@ddw_music Please hammer away at the <ctrl-b> help browser in Purr Data by adding issues to the tracker:

https://git.purrdata.net/jwilkes/purr-data/issues

If it's not returning useful results for a term like biquad there are probably lots of ways to tweak it.

That help browser searches all the external libs that are already installed on your machine, so being able to successfully leverage that should address a lot of the problems.

Also-- please report if any of the externals are broken. I've never seen a single Pd external lib that shipped with tests, and we're talking about trivial bugs like broken arg parsers in a constructor, pointers to nowhere, etc. An unfortunate part of the Pd culture is that instead of reporting a bug a new user quickly learns, "if doing X crashes Pd then don't do X."

I mean, there's an XML parsing class that had a bug which ended up indexing past the end of an array for a core part of the algorithm. All that effort to do something as mind-numbing as string parsing in C, and the developer apparently never even called a method on it. It's like the code equivalent of 5'33".

Lack of feedback is something that discourage devs. And that's probably a reason why so many projects are never finished. And thus users are discouraged to contribute. Damn.

@Nicolas-Danet I think of it from the standpoint of the user-- there's almost certainly a low threshold of crashers and other bugs that the user quickly interprets as the natural state of the system,

That's esp. important for devs to keep in mind. I'm typically running Purr Data from the terminal where it will spit out a "fault" or some kind of error message to the virtual terminal. But for people running from a graphical menu Pd simply disappears on crash. Over time they may become anxious about doing any kind of business that could lead to Pd going away-- e.g., data structures, some external library, or even some method of an external library.

Add to that the open source "it's free" ethos and a user may be convinced that it would be rude to complain on the list that something isn't ripe soon enough for their tastes.