You need to stick your fft stuff into a subpatch and then use [block~] or [switch~] to specify the blocksize/overlap

I would do all your audio feature detection in Pd and send all your desired parameters via OSC from Pd to Processing.

Deken issues sorted out, just uploaded everything so they should be up and good to go

I don't believe so, but you can definitely run Pd on a Raspberry Pi or you might even want to check out https://bela.io/ .

A good rule of thumb is smaller window size (npts) = better time-resolution but worse frequency-resolution and larger window size = worse time-resolution but better frequency resolution. You could try out Katja's [helmholtz~] also.

So the threshold part is working? On the array size side,.. basically have a [metro] poll [timer] at regular short intervals and if you're still recording and you're within say 10 ms of the end of the array (which you will know from [timer], use [array size] to add on say,... 5 more seconds of array (old size which you can get from banging [array size], + (5 seconds * 44100)). Then when you stop recording, you can turn off the [metro] and poll [timer] one last tie to get the length of what you actually recorded. then use tabplay or whatever to just play that amount of the array.

Hello,

I did a writeup on this sort of thing awihle go... http://puredata.info/Members/derekxkwan/pdext-to-pd/ Essentially, you need to specify the folder that the externals are in. At least Cyclone contains binaries separate from the binary that has all the signal binops, so if you want something like [round], you have to type basically the relative path from something in your path to the object, so at least how it's laid own in the package downloader, [cyclone/round]. Zexy should be one binary though and you can load that with [declare] or load at startup via preferences (and once the binary is loaded, all the objects are in your "namespace" so if you want [swap~], you just type [swap~}, also I think Pd automatically searches subfolders for self-titled binaries)

@60htz Actually it looks like 3 separate but valid JSON structures (because I'm pretty sure you can't repeat keys), so just try it out with one and remove the commas,... so essentially

{
    "AIS":{
        "key1": 1,
        "key2":2
    }
}

well, jsonlint doesn't like it either... looks like at least on line 23 you are closing the very first bracket and I don't think you want to do that yet,.. you have an issue with the other "AIS" bits as well...

You might want to clarify the particular sound source(s) that you are concerned about and their qualities, ie monophonic (easier)/polyphonic (harder), more pitched(easier)/less pitched (harder), speed of notes, etc. Right off the bat, one parameter you can futz around with is window size, bigger window size = better frequency resolution but also worse time resolution.