I've been exploring synthesis with more traditional code lately and I'm amazed at how much more time it takes me to do something like this piece of ChucK code, which sets the frequency and gain of 20 overtones, in PD:

DecaySine s[20];
    for (int i; i < 20; i++)
{
s[i] => dac;
247.0 * (i+1) => s[i]freq;
3.0-(i*0.1) => s[i].T60;
0.5/(1+i) => s[i].gain; //triangle
s[i].keyOn();s
}

To do that in PD, I'd have to make all these boxes, fill them in one at a time and connect them with wires. This remains true even if I come up with something to calculate out the values in the same way. I still have to manually enter the numbers into the [route] and manually make and fill out the object boxes (bottom right of the image. This takes like 20 times longer than the ChucK code (or C++ etc.)

I imagine PD will never be as efficient/quick for things like this as a typed coding language, but am I missing something? Is there a more efficient way to use PD?

@s.elliot.perez I'm not a coder, but I do get the sense that there will always be certain programming techniques that can be realized faster in code than in Pd.

That said, I feel like my biggest breakthrough in Pd was in learning how to quickly build abstractions. Anytime that you're repeating similar calculations & connecting dozens of cables, you can likely create a new abstraction & realize the idea in a fraction of the time it would have taken you otherwise. I don't think it'll ever be quite as efficient as a few lines of code, but at least will get you much closer.

You can also pull off some fairly advanced trickery with [expr], although I'm not the one to ask about that.

@s.elliot.perez I think dynamic creation is as close as you could get.
A counter to place the objects and connect them.
I use the method a lot.
E.g....... build_inputs.pd
Needs ..... count.pd
David.

@whale-av I've renamed them to get rid of the numbers (assigned @ download?) and when I open build_inputs.pd, the three upper objects are all invalid. Am I missing some extended library?

@s.elliot.perez Sorry...... It's likely...... I just grabbed it from a patch and it probably depends on other things.
Here is one that will run....... and is 100% vanilla....... matrix~.zip ....... It needs [count] again which is a vanilla abstraction.
I built it to replace [matrix~] from the cyclone library.
Open the test patch and then open [matrix~] and then open [pd mixer] to see how it builds.

If you open [matrix~] itself outside the test patch you will see that it is mostly empty. It only creates when it is given arguments.
David.

@whale-av Thanks! Very interesting. Might take me a while to figure out how it works.

@s.elliot.perez You might want to check out [clone] too. I don't read ChucK, but I think you might be able to make 1 overtone abstraction and then use clone to replicate it 20 times.

@jameslo Hey, thanks for sharing that. I just put this together- It took me a little while to set up, but it works pretty well! It's not compatible with hvcc, which I use for integrating PD structures into Unity and other platforms, but it could be useful for prototyping.

Here's the version I made of the above code with oscillators. Open "string.pd" to use it. Needs to have "overtone.pd" in the same folder.

string.pd
overtone.pd

@s.elliot.perez if you are not bound to vanilla you can combine text based and dataflow programming with ofelia (using lua). In some cases (overtones) sinesum might be useful too: http://write.flossmanuals.net/pure-data/generating-waveforms/

@s.elliot.perez It looks like you could simplify things a bit in string.pd by using the [all $1( message whenever you intend to message all the clones and not just a subset of them.

@jameslo Ohhh yeah. That's what I get for skimming the help file. Thanks!

Speaking of efficiency: There's ChucK code that does spectral analysis and outputs a list of peak frequencies and their amplitudes in this format:

[ 4072.47, 1 ], [ 5593.25, 0.304494 ], [ 4196.28, 0.66348 ], [ 5536.73, 0.726691 ], [ 4382.01, 0.527432 ], [ 5380.61, 0.722193 ], [ 4766.91, 0.287018 ], [ 7073.66, 0.620362 ], [ 5334.85, 0.513121 ], [ 5490.97, 0.267715 ], [ 5046.84, 0.342458 ], [ 7006.37, 0.657309 ], [ 6629.53, 0.451136 ], [ 6939.07, 0.525416 ], [ 9520.37, 0.254127 ], [ 9388.48, 0.253434 ], [ 7396.66, 0.225276 ], [ 9582.28, 0.259454 ], [ 8990.11, 0.168725 ], [ 9703.4, 0.247069 ]

which you can easily click and paste into another ChucK script that will resynthesis a sound with that spectrum.

If I wanted to use this data in another text-based language, I could make or adapt a parsing script that removes the brackets and sends the left value into a frequency array and the right value into an amplitude array. But in PD, even if I use abstractions or [clone], I would still have to either manually go in and cut the individual values and paste them into a message box or into an abstraction as a creation argument. I suppose if I could convert them into two lists, one for frequency and one for amplitude, eg. I could send them into a [clone] easily, eg.

[4072.47, 5593.25, 4196.28, etc.(
|
[next $1(
|
[clone]

I've made a parsing script before to read parameter list txt-files into C#, so I'd have to look into how to generate .txt files. So the process would be

1. Get ChucK analysis data.
2. Paste it into algorithm to generate two txt-files in the proper format.
3. Copy and paste content of those files into PD message boxes.

This would work for testing in PD, but since hvcc isn't compatible with [clone], I'd have to wire up a route system into regular abstractions.

Any better ideas for how to do this? Is there a way to do the parsing in PD itself?

(I know @Jona mentioned ofelia. So the question is what's more work and what has more payoff. Doing it the way I described or learning ofelia?)

Does ChucK support MIDI or OSC? I often send lists from Arduino devices over USB serial to PD, but that requires the external [comport]. If ChucK can send character data over TCP or UDP, you could also use [fudiparse] to convert it into PD messages.

@s.elliot.perez here is a parsing script made with pd
parsingScript.pd

@Jona Thank you! You're a legend. I'd forgotten all about the list items since they're not hvcc compatible.

Unfortunately that particular ChucK analysis script doesn't work very well on noisy sounds...