@EEight Yes, this is exactly the kind of project Thanks for bringing my attention to it.

@EEight yes, ELSE is very impressive. Thanks for the suggestion. From what I understand ELSE is more of an extension of the Pd paradigm. I'm more looking for examples of how Pd is used to develop a framework or architecture for an instrument or workstation that may imposes a certain type of workflow. An example might be Automatonism, which uses Pd to create a modular synth style workstation. I appreciate your help @EEight

thanks for sharing! I watched the Vimeo demonstration, very cool. I tried install it but unfortunately tof & maxlib do not have apple silicon builds... but i'm looking through the individual files and getting a rough idea of it... is there any documentation that could help me better understand the project?

Hi all —

I’m currently writing a paper on the Pure Data framework behind an instrument I’ve built (youtu.be/9fTjfAB4PN4), and I’m looking for documentation or examples of other instruments or workstation-style Pd (or even Max/MSP) environments.

In particular, I’m interested in how other systems handle the functional relationships between components like:
•mixing/panning
•CV or control signal matrices
•sound-generating modules (eg synths) and/or audio effects (eg reverbs)
•preset management systems

Can anyone recommend projects, documentation, or repositories that explore these kinds of architectural choices? I've found individual solutions (eg preset management systems) but looking for info on more holistic system design...

Thanks

Thank you @fishcrystals for the explanation and @jameslo for the test results. Very helpful!

Thank you both for the clarification

I'm writing a paper where I measure the latency of an instrument I built that synthesizes sound with PD, and was wondering what to call this 'delay' parameter. I'm used to seeing it described as something like an 'I/O Vector Size' as in Max...

Thanks again for the help

Very helpful. Thanks for the reply.

So the purpose of this buffer is to accommodate the IO hardware?

And does this type of buffer have a name?

It seems to have something to do with the in/out buffer? But is not the same as the block size? Looking for a technical, under-the-hood explanation. Or a referral to any existing documentation... Thx

nice implementation and very resourceful approach using the vanilla objects. thx for sharing! will save this for future reference

I've updated ambiNilla (v.3.5) to include a signal rate implementation (ambiNilla3~). Works well for fast moving sources

thx for the response @seb-harmonik.ar . I've just fixed it. In short I had a few layers of switches nested within various subpatches. I realized that turning on/off the lowest layered switch was redundant, and it seems to be fine now.

It sounds (sonically) like it may be related to the issue you posted. I'm PD 0.55-0. thanks again!

Theoretically, I'm still not sure why it was causing that issue, But regardless, I'm happy it's fixed

I'm having problems with a strange distortion sound a patch of mine is making, perhaps related to FFT processing.

The patch uses a preset system to change between settings. The system will mute the input to FFT objects during preset changes to avoid audio issues. However, when the preset changes I'm often getting a sort of distortion, which strangely clears up if I add & delete an object.

I've demonstrated it here:

My DAW is looping audio which is sent to PD for processing. The loop is on top of a preset change to demonstrate the issue.

Any clues as to what this could be?

actually macos. APFS filesystem, which i'm just reading is case-insensitive by default.

now i'm a bit worried that other patches I've shared might have similar issues ...

@alexandros thx for catching that! (for some reason my pd runs it ok even with the case mixup?) i've updated the source files for consistency. thx again

@bklindgren I've updated AmbiNilla and it now supports 3rd order (plus 0, 1, & 2) + also fixed a few bugs

thanks for the response!

edit: you're right about the need for multiple specified arrays for tabread~

i think i've got it fixed actually. was confused bc when i first ran the snake~ thru the abstraction i hadn't realized hip~ wasn't compatible. But when i cmd clicked on the error in the console, pd highlighted the *~ or the abstraction rather than hip~... even after i fixed hip~, I think the saved abstraction had populated the incompatibility to other instances in the patch, making the error log a bit confusing...

still not sure why *~ was giving errors....

i'm 'upgrading' some signal wires in an existing patch to multichannel (8 chan).

i keep getting these errors:
canvas: incompatible signal inputs (8x64 vs. 1x64)
*~: incompatible signal inputs (8x64 vs. 1x64)

they seem to happen in conjunction with abstractions within my patch.

all the objects i think are snake~ compatible, except hip~, which i un-snake for

this is the primary abstraction of concern:

any ideas?

I made a patch with corresponding Bela code to transmit data from Bela's analog inputs into a PD patch. https://github.com/brianlindgren/Bela-to-PD-over-OSC

I was having trouble making a vanilla zero-crossing pitch detector for my project, so I ported one I had done in c++ to a pd external. maybe useful to others? https://github.com/brianlindgren/zDet/

I implemented a 1st order ambisonic panner for PD vanilla. It was derived from another panner & I optimized the process of generating coefficients and importing them into PD. Works for elevation too. Located here: https://github.com/brianlindgren/ambiNilla