Howdy! [first post]

Im somewhat new to PD. Ive read and patched and developed something I'd like to share. I am looking for data on how computationally intensive/expensive PD is. For instance I understand that block size is 64 samples that can be modified but what are the limits and how are they calculated?

How would I measure the size parameters of each object both on disk storage size and speed of microprocessor to run n number of objects / patches / etc.

I may not be asking this question correctly but for instance an attiny can run PD but what are the limits? How small of a processor (speed, ram, etc) can it be run on and based on that what are the limits to object count and hot swapping while a patch is playing (eg: adding a feedback on changing bands after fft) ?

Im sure there's an easy way to do this within PD that i haven't found yet

Any guidance to a list or script would be super helpful and appreciated.

I will post any results and update to giithub and here.

I look forward to meeting the community. Thank you for reading!

buffer size of running each patch?

@4poksy 64 samples cannot be modified for links between patches and sub-patches.... [inlet~] etc. ...nor for final input and output.... [dac~] etc.
It can be modified within a patch or sub patch using [block~].

Patches are very small on disk and in memory..... your os will tell you the size.... they just contain text.
The biggest patch (hundreds of patches running together) that I have ever built uses less than 100K on disk. The objects you call are loaded to and run within the Pd binary as you open the patch.
Pd itself uses about 8.5K of ram with no patches open, and the gui program "wish" just over 15K (in windows 7).
When that massive 100K patch is running Pd expands to use 76K of ram and wish reduces its space to use 12K.
Arrays are the size you choose, and can be large if you are storing audio..

Pd can (sort of) report its cpu load....... dsp~.zip

For more on what actually happens "under the hood"..... http://puredata.info/docs/manuals/pd/x2.htm
.... but that document is also in your Pd installation in the "doc" folder........ /doc/1.manual/x2.htm

Pd builds a "super-patch" from all the patches you open, and the audio thread is rebuilt as you change or add objects and patches. That means that it is always running, but there is no buffer between patches unless you make a mistake..... see the doc above...
You can also use [block~] or [switch~] to turn off audio processing within individual patches and sub-patches...... useful for saving cpu load when switching between effects.

Welcome to the forum...!!
David.

P.S I am usually wrong about something and others will tell you where.

Wow! Thank you @Whale-av ! thorough and prompt reply!

Thats an excellent starting point. That dsp patch is great.

Yes a super-patch is what I thought. So i'm thinking if there were maybe two Rpi's with one running a redundant version there'd be a fail-safe + + +... I've a bunch of Pi's to be repurposed.

This is what im looking at to systematically make a report. I'd like to have a table of each object and how they've been organized in https://archive.flossmanuals.net/pure-data/list-of-objects/introduction.html with an estimate of cpu and ram usage in a largest patch scenario for live performance switching, etc.

Onward!

Thank you!

@4poksy My largest patch is 230k and is a single patch which uses no abstractions* or even audio rate objects and it can eat every bit of ram and cpu my computer can give it without much fuss. I can probably write a small patch with just a handful of objects which can eat my cpu and ram. Knowing the resource use of individual objects will not be very useful, how you use them is fairly important and will effect resource usage, GUI and symbols can drag pd down even if the rest of the patch is fairly small. Your time would probably be better spent improving your patching skills so you can make more efficient use of pd, a slight change in methodology can have large effects on resource use. The first version of my 230k patch was only 84k and considerably less capable but hit the wall much more easily than my current version, difference is I learned about how pd worked and how to work with it, as a result my patches have gotten more efficient.

*Technically it uses one abstraction but it is a small abstraction of just a dozen objects which is dynamically created as needed, the patch can eat my computers resources with just one instance of the abstraction or run perfectly fine with 100 instances depending on what I ask of the patch.

@old I agree and thanks for great info. That's sorta the best advice: The architecture of patching is utmost important. Im working out a scheme for live performance and want to have a schematic of patch basics: for instance a dac must be included in every patch .automatically. and if I wanted to instantiate something super minimal like an osc filter and ramp,,, how many ways could i do that and how many osc can I add on the fly and have them midi assigned at button push. Knowing the consumption parameters is helpful to what Im building and most definitely it'll rely on patch design.

But on the fly sequencing for instance... sequencing a gated reverb on harmonics... and which parameters would be midi assigned automatically.. i have a ways to go .for sure. to somewhat cement these as core patches that can be assigned without using a mouse or pad.

could latency be resolved running for instance any of the computational weight on arduino nanos or minis alongside the pi's?

@4poksy A standard sequencer is probably a few dozen instructions to the cpu and even the early rpi can do ~2000 MFLOPS, pd can get a great deal done between audio blocks despite its single thread nature. Has your experience demonstrated that you even need to worry about this? Even my 230k patch which is an entire programming language can accomplish a great deal between audio blocks and it can control all of the parameters for a good number of analog style subtractive voices in real time without issue. Sure my computer is a considerably more performant than a pi but still, it is getting a hell of a lot done between audio blocks.

An arduino will probably not help anything unless you have a good amount of interface stuff and/or are using one of the old single core pis, with a multicore pi you can just do the UI stuff external of pd and let the kernel deal with scheduling everything, it will almost certainly do a better job than a mortal unless your programming skills are getting up around kernel dev level. Even on a single core pi it may not be an issue. If it is a multicore pi than one of the things you can do is isolate a cpu core with the isolcpus kernel parameter, play with IRQ affinity and start pd on that isolated core with taskset or cpuset, this will make sure that the kernel does not stick some other process on the core with pd during a time when pd has an easy load which can cause dropouts when that load suddenly jumps. You can also structure your patches so all UI is separate from DSP which will allow you to isolate a second core and run UI on one, DSP on another and communicate between them with [netsend]/[netreceive].

But none of that may even be a problem, are you having issues with dropouts or are you attempting to preempt such issues? For the former knowing your exact issues would help a great deal in assisting you, for the latter learning more about how pd works and the system on which it will be run will guide you in what preemptive measures you actually need to take.

The stuff above regarding arduino and pi should be taken with a grain of salt, I have no direct experience with either and am basing that off of my electronics/pd/linux knowledge, but someone (hopefully) will come along to correct me in short order if my assumptions are faulty.

@4poksy said:

The architecture of patching is utmost important.

Also: You won't get the architecture right the first time. So, try something, in full knowledge that eventually you'll have to rip the guts out.

(However, some architectural elements could be done well right away: minimizing the paths through which data can flow from one part of the system to another, for instance. Modularizing, and keeping modules as local as possible, concretely reduces the chances of bugs, and also reduces the area over which guts will have to be ripped out later.)

hjh

righteous.

good pi advice @old and yes this is mostly preemptive. I really want approximation charts to create structural patches and know their potential computation expense ahead of time.
Need to handle all samples with a separate mcu / storage with card and better understanding of ram.. it's coming along. and yes all external hid handled by arduino

yep, v true @ddw_music many many times (: