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.

@ingox i guess that point is a little subtle but makes sense when you think about it =P

@weightless Yes I mentioned issues with the [text sequence] and its linear search and with a non-neglible length of text, you start getting dropouts and non-negligible search times

@ingox cool, thanks for the tests. I suppose that's one way of looking at it with one line per note event then unpacking and manually doing the sends, which isn't the worst thing in the world. And then maybe breaking it up into several [text]s for subsections or diff groups. I suppose I just a little too attached to the idea of having structured key/value data that doesn't rely on linear search ala JSON and liking working in Pd but missing the power of SuperCollider patterns where it's basically OSC bundle format with typetags and such like \duration, Pseq([0.25, 0.5], inf]), \pan, Pseq([-1, 0, 1, 0.5], inf) and such. I guess the closest thing in Pd right now is structs? but even then you still face the issues with linear search. I guess I'll have to try to think more Pd-like for now =)

@weightless Yeah, I've used [qlist] in the past for sonification stuff. the issues i have with [text sequence] and [qlist] is that there's basically one send symbol binding per line, and the primary way of jumping back and forth through the text (say to jump from note 5 to note 1 to note 16) is through line numbers and that requires some bookkeeping. A way around that is to put in flags before every parameter chunk (say like a line with just "note2" or something) but then to get to "note100" you have to [text search] through the entire thing to hit "note100" (at least per my guessings as to how [text search] works, haven't combed through the source too thoroughly)

posted this on the fb group as well but curious as to what answers I'd get here:

how do you deal with scheduling/sequencing multi-parameter note events? say something like pitch, amp, dur, panning for each note? do you use one list with n-elt chunks dealing with n parameters? n different arrays/lists? [text sequence]? structs? manage to compile xeq and make sense of it? How do you deal with unit changes (switching from 16ths to say 8th note qunituplets)? In Pd, I've never really felt comfy with working with these sorts of things

in the past, i've used an absttraction I made based off the list sequencing example except with multiple parameters (found here ) and it gets feeling a little unwieldly/unstructured with a larger number of parameters or longer sequences and it's at those times I start wishing for multidim arrays or nested structures like lists in lists or jsony sorts of things (which I suppose text/structs kinda do), something make dealing with the whole thing a little bit easier. Lately I've also been experimenting with embedding info in just one number,.. so like 3.54 where 3 is the pitch from an array, 0.5 means it's twice as fast, 0.04 means it's panned left (making 0.06 panning right, 0.05 center pan). also a bit unwiedly and kinda confusing

@ingox Ah, interesting. I suppose I haven't used gigantic lists that much so I haven't come across that issue but that's a good thing to keep an eye out for, thanks! At least with my tests (and it looks like I come up with similar results with your environment with small lists (10-20 elts) that mine does go faster than the [list store] way and is comparable to the IEM speeds, so perhaps [list store] might be slower with small lists, but scales much much better (which is to be expected with only using one list object and not relying on weird passing things around trickery)

I've done my own version of list-drip in the past that I think beats the list-drip speed but has a variable drip size (also I think I use less lists than list-drip does?, patch here)

@1mark I think you need to add your user to the audio group (adduser username audio) and your /etc/security/limits.d/audio.conf should look something like this:

@audio   -  rtprio     99
@audio   -  memlock    unlimited
#@audio   -  nice      -19

I've commented out the nice property, i think it defines priority, but you can go ahead and uncomment it if you want... You shouldn't have to run pd as sudo... also sometimes JACK crashes and has processes still running so it also helps to kill processes off if that happens

Haven't tried Pd with PulseAudio, maybe something with internal sampling rates or buffer sizes? So maybe somebody can jump in here and help, but I would really recommend trying out JACK, particularly if you want to use anything else audio-related on your computer aside from Audacity (which can use ALSA directly but then you have the same hogging issues as before) as things like SuperCollider and Ardour also primarily use JACK as their means of talking with ALSA, and JACK tends be better at the low-latency, synchronous operation thing than PulseAudio, where latencies and synchronous operation don't mattery quite as much...

Linux and audio can get relatively hairy,.. basically if you try to use ALSA directly with Pd, you can't use anything else that has sound. That's where intermediary layers like PulseAudio and JACK come into play that talk to ALSA, PulseAudio is good for general use, JACK is good for lower-latency stuff like you would want with Pd so use JACK with Pd and then you want to download "sinks" where everything else can use PulseAudio and then be connected to JACK, I have this info saved somewhere...

Edit: Well essentially you want to sudo apt install both qjackctl (which I think installs jack also?) and pulseaudio-module-jack. Then in qjackctl: under setup > options: "pulseaudio -k" on startup, "pacmd load-module module-jack-source channels=2; pacmd load-module module-jack-sink channels=2;" after startup, then "pulseaudio -k" after shutdown. Basically, kill the pulseaudio process when you startup and after you shutdown the JACK server. You might have to tinker with /etc/pulse/default.pa,.. can't remember if I did on my current installation but we'll get to that if need be...

should be in iemlib, which you can download from "Help > Find externals". You can replicate the functionality by using vanilla objects as seen on this page: http://www.pd-tutorial.com/english/ch03.html (basically [env~] into [- 100])