lol no, that was it.. doif!

@FFW why will this exact patch not work in my vanilla?

Hi~ I have a new hardware prototype built and looking to hire patch designers and c/c++ devs for making some changes to PD.

Ideally we could meet, video or otherwise, once a week (likely more) to decide on the landscape of this synth and how pure data is involved.

Hire means pay! IDEALLY the contributors would be part of a strong team and at first (up to you) perhaps do contract work but this is a minimum 5 year project with multiple iterations and to completely sign on would move things forward tremendously and get everyone paid to do what they already love doing.

Please contact me here or via; apoksypro aaatt proton dot me if you're interested and we can sort details!

We're all super excited, nothing like it exists atm and so birthing this into the world will be fun. There's alot more under the hood but first things first. Structure and money are involved so there's... well... structure and the idea is to do new and interesting things in new and interesting ways. Cleanse, fold4wrap5 and manipulate PD and hardware. Expert knob twiddlers who want to reniform puls a Sunshine Recorder through the Galaxy Garden, Let's go!

@whale-av a counter is a great idea. I'm looking in python scripting to help deal with this. always great advice here

@alexandros is there a visual or library/help that shows and explains the inlet/outlet table? I have been digging through various iem libraries to find a type of grid or structure to this table that could be visualized and modified. Do you know of anything?

@kaimo Are you using the pure data pduino external with comport?

I've been working with both and getting extremely shaky data. Smooth works alright but doesn't help much.
The input, at least for vanilla, requires a fudiparse object. I'm working on alternatives and thinking, (hoping not) that i'm going to need to write a library to handle this better.

Also, curious why you use pdextended? I love plugdata's gui and search, etc, But for whatever reason I've been sticking to vanilla. I use Patchbox OS also on a Pi4 without their PiSound, although it looks great Im unsure of being locked into their hardware.

Im creating a live setup with what I have here (Pis and arduinos) but looking at the Bela on BBB has me considering jumping ship. Also the UDOO looks like a tremendous piece of gear.

I love audio sculpture, and hype to see what you make!

Has anyone tried coding with Circuit Python's baremetal Rpi approach to run PD?

It's using a slower language than c/c++ to run Cpython however all OS needs have the potential to be run after audio. This makes the headphone jack the output (not ideal) so driver writing... eesh. But perhaps a solid solution?

Ready to begin hiring patch and script authors. FLOSS obv. If anyone is interested in this we can go deeper about the project, please message me if you have skills or the desire to contribute, can talk royalties, pay, etc.

@whale-av largely agree especially about the pi's, spent so much over the years on add-ons cameras, etc.. but the ideaa behind is awesome. Just really tired of laptops, not even in a dawless sense but the whole of it.

I appreciate all replies!
Reason for Pi is I have a bunch of them left from various projects over the years and they're super embeddable and modular without having to design custom circuits. Same with arduinos. Ideally a custom FPGA ASIC would be righteous. As per the paper though "FPGA-accelerated Real-Time Audio in Pure Data" they were successful doing physical modeling on a Terasic DE10-Nano but tooling for any realtime interactivity with the core was essentially non existent at the time of writing (2022). I don't understand FPGAs well enough to come up with a good solution yet, but parallel programming is somewhat comparable to writing an orchestral piece. The logic circuits can be rearranged so you could have different setups for different heavy synthesis types, just not on the fly iirc.

I could see having two FPGA cores to switch between heavy instrumentations w an MCU handling the rest of the audio functionality. Will need to hire ssomeone to write this. Accepting applications!
Thankfully modern FPGA's allow for c++ and python.

The Box im building is for patch recall and midi mapping with realtime programming built into the workflow. I want to get away from the laptop .with. PD.

@alexandrous exactly. Laptops are wonderful, absolutely, but looking at the screen for hours building sound machines and then using the same thing to improvise emotionally and then for email, web etc is wearisome and counterproductive. Keeping form factor and desk space small is crucial as well. Yes of course a screen is still necessary but w/a workflow more like an Elektron machine hence the desire to know the computational expense of atoms pushed to their limit (which is obviously a super lengthy and nearly impossible venture). Industrial 3" screens are are kind of better than capacitive or resistive touch screens

So maybe HiFiBerry is at the top of Pi DACs. Patchbox feels like a toy, definitely could be wrong. If latency between platforms can be solved a Pi/arduino cluster of sorts can make pD experimenting much more fun than sitting with the laptop ALL day. I don't think the human brain feels the same about things we can't immediately aurally detect. The vibe of a violin vs that of a synthesized violin is different. Embracing the difference is one thing but having standards in the architecture of the synth is like having standards in the making of a Stradivarius vs an amazon basics factory production. We're living in the decline of culture bc we accept the 'just enough' philosophy of building without functional aesthetics. Starting to ramble..

Bela looks really good and agree with @old about Elk and the site etc, lol, I perceive they have things going on behind the scenes, buyouts, integration, who knows... they may surprise us. Either way I've found a good route so I guess it's the HifiBerry or have a custom built to spec.

Flux-ai could probably design one flawlessly. BTW very interested to see @old 's large language patch mentioned in previous discussion.

I'm building a control box for a live setup using at least one Raspberry Pi 4 with Arduino for HID
(for now... plan to use an FPGA at some point to offload major tasks and have so far read only the one paper found on PD and FPGAs. (any ideas I'd love to bandy about!)

Elk Audio insinuates preference for HiFiBerry's ADC+DAC Pro and also as I've not seen any news of an Elk product designed for the OS additionally something universal would be preferable. (Elk community appears fairly small)
Patchbox OS is nice but Im not leaning toward a 'VST box' or being locked into Patchbox's hardware

Does Bela have the edge in overall useability plus community? BeagleBoneBlack (which i do not own) appears well used and supported with a good community.

Ideally a bare metal solution for Rpi4 CM, perhaps a cluster leans toward maybe a Raspa/Yocto build?

Looking for the lowest latency to get away with an Rpi build atm

I don't have time to design a specialized DAC, nor the incllination to try a ton.

What is the best, possibly future proof, DAC for RPi ? What is being commonly used?

Also: Elk / Bela / Patchbox who will survive?

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 (:

@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?

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!

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?