this has been sitting around on my hard drive for a while and i don't find the time right now to keep developing it, so i thought i might just put it out there...
it is the first external i've put together and it's basically a hack of ffteases pvoc~. the analysis~ part gives a block with amplitude and frequency information. the adsyn~ part resynthesises it from an oscilator bank.
my intention was to find a way to do a sinebank resynthesis from fft data. looking at the code i've found out that phase information has to be converted to frequency information before it can be fed into a sinebank. to do so, the first step is to calculate the phase delta from frame to frame for every bin, this means discarding the absolute phase. in the next step the phase delta is converted to the actual frequency for every bin, which is not the bin frequency, but a deviation which is more or less close to it. fftease has some nice functions that handle this conversion.

for analyzer~ only the first inlet is of use. i didn't delete the other two yet, because i was afraid to mess something up. adsyn~ has four inlets. one for amp and one for freq blocks, a third one for pitch changes, and a forth one for gating out weak frequencies, in order to save cpu. this last inlet is still troublesome, because the gate isn't ramped in any way. the consequence is that you hear clicks anytime frequencies rise or fall below the threshold. the original pvoc~ has the same problem and it must be fixed by crossing it with something like vectral~ i guess, or something even simpler.changing the analysis window size works like with the other fft~ objects, by just changing block size.

next step would be to tidy up the code and strip it down to what's necessary.
also i've been thinking about if there's any way to improve sound quality by changing the resolution of the sine table.

included is the osx build and all sources.
i hope anyone will find this useful.

http://www.pdpatchrepo.info/hurleur/analyze:adsyn.zip

does anyone care to try this? i don't know a lot of pd-minded people around my place and i haven't shared this with anyone yet. the development has gotten quite far by now though. it's been some years of work and trying to make pd handle the digital part of my live setup. i am not sure yet about when and how to release this (it will be completely free though, that much i can tell). i'd really love to get some experiences and opinions before that though. Or get an idea if there's even any point to this in pd and if it is worth documenting it and maintaining it for the public.

the patch offers ten layers of granular/spectral soundfile or live input processing. there's 100 preset slots that can be accessed from within each layer and morphed between. full osc/midi control is possible. a pd port of the great polygome monome-patch is included. you can also load instrument banks, and play them as oneshots or using the sample slicing engine (just name each sample by it's corresponding midi pitch and choose the folder the samples are contained in). there's lfos and one assignable multi parameter for each layer. all settings and samples are stored in the presets to make it a fast and intuitive live instrument, that was my priority. it harmonizes perfectly with korg nano kontrol.

so far it was made and tested by me only in pd-ext 42.5 on osx. in addition only the soundhack externals are needed to get the decimator to work. loading might take up to 3 minutes or more! that is normal for now, but i hope i can do something about it in the future.

http://www.pdpatchrepo.info/hurleur/nigredo.zip

I'm curious if there's any external or abstraction or simple method to do the resynthesis from fft data with a bank of oscillators insted of inverse fft. i know it's probably more cpu intense, but the results seem to be superior in sound quality. any ideas?

i'm having trouble running PD under jack on OSX.
the patch i'm working with is very cpu intensive, but i optimized it as far as possible. when i run it with portaudio now, things are fine. i have to use high delay times of about 90ms to have things running smooth, but that's fine for me because it's more like soundscapeish stuff that don't need fast control response.
but when i use jack to route the outputs into ardour i get the typical audio cut-outs from too low latency (at 2048 buffersize maximum), and there seems to be no way to increase latency to the point where things work out under jack. at the same time though, cpu goes significantly down with jack, but still i get the clicks. very strange.
i've been told that the maximum latency is hardwired by the audio interface, but why can i increase the delay under portaudio to whatever amount i wish to have things working, but not under jack?
i hear that jack is supposed to be a "low latency audio driver" but for some reason it ruins the performance of my patch.
is there an alternative way to route 8 to 10 channels of audio into ardour?

thanks for any advice!

is there a way to dynamically change the length of the delayline for delwrite~, or is there an alternative object? delwrite~ seems to occupy memory even when dsp is switched off. i have a patch with lots of delwrites and it eats a lot of resources. is there a way to allocate the memory space only when i really need it?
i know i could use dymanic object creation, but i'd like to avoid that because it seems a bit shaky.
any ideas?

is there a way to receive a bang from an array everytime the content is changed? or does anyone know of an external that gives the values of an array as a list everytime the values change and only then? i want to have it act sort of like a row of sliders, if that makes sense. this would make things a lot easier in my projects, but i couldn't find anything so far.
thanks!

does anyone here have much experience with pd~? i'm trying to break a big patch down into two portions on a macbook duocore, to hopefully get a little better performance. the problems/questions are:
-it doesn't seem to find the file for the subpatch that the start message points to, when the current folder (in which the the subpatch is located) has spaces in its path (i can workaround this issue of course, but still it's kind of inconvinient)
-when i start with a -nogui flag, the console and the subpatch pop up anyway. does it always automatically do that when something like an errormessage wants to be printed in the console? (i know for sure i placed the flag right, because it works in the helppatch)
-what's the -fifo flag and value about? does it determine some sort of latency between the subpatch and mainpatch?

i didn't really get it to run and do some serious dsp yet, so if anyone knows how to work with pd~ in more complex situations than the simple helppatch some hints would be very appreciated!

hi everyone,

i tried to set up memento, but the [pool] object from the grill externals was missing. i downloaded it and linked it in preferences>path. i can load it now but i still get error messages, because another pool external seems to be included in the pool external, which obviously can't work. i get:
"... couldn't create
error: pool: can't load abstraction within itself"
from PD.
i have no experience with compiling externals.
is there any easy way to make [pool] work?

i'm using PD-extended 0.41.4 on mac osx.

thanks for any help!

here's another small update to fix some gui updating issues and get rid of some error messages. the link is up in the first post.

it seems to me like spectral stuff is a bit lighter on cpu in csound, but not significantly much. the sound is way better though. for granular processing i am using the partikkel opcode which is crazy cpu hungry, if you go for a dense grain cloud type of sound (or if you set it up wrong). the granular time stretch effect is barely usable on my core2duo macbook. you always have to make sure to keep the density parameters on a reasonable level, and always mute layers that are not in use.

generally it's hard to compare pd and csound in cpu because the functionality of both patches isn't exactly the same. both are hungry enough to make me consider getting a new computer some time soon though.

i don't really know what you mean by doing summing in csound. i use it mainly because i like the sound engine better, not really for saving on cpu load.

new version. i finished it up a while ago, but i barely got to test it.

a lot has changed:

ALL effects are csound based now, except for the granular delay. that one has changed significantly as well though. it sounds a lot smoother now with improved windowing.

there's three sample playback options now:
csound based pvoc, csound based granular, and the old synced looping

the interface is a lot tidier now and should give faster and more intuitive access to the functions.

there's a random LFO option now and there's lots of bug fixes

a great side effect of out-sourcing dsp to csound is that you can actually make use of multi core processors, because different csound instances spread up their cpu load.

i hope this update is final for some time. i feel much more like playing than like coding right now.
better docs and sound examples are still coming up though and there's an ipad lemur template for fast access to all the presets plus a nano kontrol template coming. but i still have to test those.