qjackctl and patchage can store and recall patch configurations for audio and midi. You can also use aconnect to complete patches through the shell. Something like this could keep it all in the patch:

[loadbang]
|
[aconnect 130:0 129:0(
|
[shell]

I am getting the impression that [pix_video] can handle vnc client video streams. I am having trouble finding documentation about this though.

Does anyone have any success stories or resources to help me get there?

I love you!

If you want to attenuate the signal at the control level, set the [*~] multiplier to a fraction of 1. Since you have 3 oscillators, setting the [line~] to [.333, 0 1000( should sum an un-clipped wave form.

I been working on synthetic jamming musician patches for a bit now. A buddy of mine (DJ K9NE) tossed me a beat and I hooked a little synthony up to it.

All instruments were played by virtual musicians listening to the beat a each other. They all played presets on the Yoshimi synth. I edited about 40% of their notes out in post.

I'm considering hammering it into either a sonata form by adding composing a lead voice, to use as the first movement of a sonata. I havent envisioned what the character of the soloist would be though. CC welcome!

https://soundcloud.com/deifius/wubdubdub-randoshi-session/s-ibCF3

I was imagining the output of the sensor could be routed to a random int on a [pipe].

[midi beat]
| ............{rand int * sensor]
| ......... /
[ pipe ]

While you can upsample to make frames faster, you'll only be getting the same speed increase equivalent with dropping the window size. And what you gain in speed you lose in accuracy, starting in the lower frequencies. Doubling the sr with a 512 point window is effectively the identical to a 256 point window, just with twice the computations.

One issue with spectral domain is that you need to poll a history of so many samples to infer frequency information. ie If you want 10ms response time (just the spectral analysis, not total overhead), the windowing will not even register 60hz tones.

You can get away with smaller windows for higher voices. If you are tracking a piccolo or a violin, a 128 point window might be sufficient. 128 samples at SR 48k is only 2.6 ms of added latency, which is not too bad!

@Fauveboy In linux OSes, there is a nice value assigned to every running process, between 19 and -20. When processes are competing for resources, the nicer processes are left hanging while the lower value nice processes take precedence. You can dictate the niceness like so:

$ nice -2 pd
From the bash prompt.

Depending on from where to where the data is being read/written, the system may experience bottlenecks. The rpi3 has LPDDR2 SDRAM which has a throughput which might be as low as 20Mbps. That basically translates to a 20MB file hoarding all RAM IO for 1/8th of a second.
.

if you are in a linuxy environment, you can use the [shell] you can use 'date -r filename.pd' which will tell you the last modified time of the file in question. Why write a patch to replicate an inherent quality of files in the OS?

If you can find points in the set where you can handle dips for loading, that might be an opportunity to compose for.

You can also mess around with the nice value of pd, which might reduce audio dips.

Most modern rpis have 1 gig of ram, which you could load over 80min of cd quality stereo audio, and still have a couple of megs left over for OS and pd etc. How much rendered audio are you playing?

@sunji

I misread the question. Forget the part about the histogram and just fit the spectrogram in a [rifft~] window.