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.

i use the fcb1010 for my pd live stuff aswell and i totally love it. i've got the modded eprom version and for editing i use the java editor, which you can sure find somewhere on the web. it makes programming the pedal way easier and gives you a better idea of the capabilities of it. for uploading my settings i use sysex librarian.

your patch looks pretty simple and straight forward. not much to optimize there as far as i can tell.

hi tilllt,
thanks for checking this out.
in the upper window you change to sample mode, then in the bottom window you hit the sample button in the pink field on the top right. dsp has to be turned on for the sample to load, and it has to be a wav file.

i'll post a new update tomorrow, with lots of improvemens and bugfixes.
cheers

i'm posting a small update now:

-improved compression settings
-reduced amount of error messages
-some faders run smoother

things aren't fully tested yet. i hope the changes didn't break too much functionality. more updates are on the way soon.

the decimate problem sounds strange. i'll have a look at that.
th csoundapi should be installed automatically when you install csound. i had troubles with one of the latest csounds versions where the csoundapi~ just wouldn't create. i went for an older csound version and it fixed it. I only tested it on the 32 bit 42.4 PD version on OSX so far. There might be issues with creating objects on other setups.

thanks for your interest. in the next weeks my website will be up, with videos/demo sounds, to give a better idea of what this thing is about.

bsaylors [pvoc~] can be usd for time stretching a soundfile. sound quality and cpu usage depend on the window size you're using.
also csounds partikkel does an amazing job, but it's cpu intense and complicated to handle in pd. have a look at my Nigredo patch in the patch section for an implementation of that.

i am very interested too. there's some osx builds around but they don't work. they just max out my cpu and produce no sound. i did something in pd that is pretty similar in functionality and sound though. check out my patch called nigredo in the patch section. it's the granular delay. also have a look at soundhacks bubbler external (it's not quite the same though).

i tested only on osx so far but i don't see a reason why it wouldn' work on windows as well. csound has to be installed though. you have to check if [csoundapi~] is creating to get some of the effects to work.

i just uploaded a major update. things aren't tested yet but i guess it should be working fine, since most changes have been simplifications rather than new additions.

all the arrays for the fft processing and the corresponding statesave and control engine is gone. all the spectral processing is now handled by csound, so you need to have [csoundapi~] installed, which should install automatically with csound.
my plan is to keep GUI, control structure, audio routing, and statesaving as it is and replace all the processing with csound as far as it's possible and reasonable. sadly sound quality isn't pds strong side, so i had to make that decision.

the central spectral effect is now a csound based remake of grm tools contrast, which thanks to the great pvs opcodes sounds no less amazing than the original. it also has a flashy interface build on maelstroms beautiful abstractions.
there's a granular time stretch based on the partikkel opcode (it's cpu intense, so watch your settings), which replaces the spiral stretch.
the spectral soundfile scanning will be replaced next. also i will have a look at how to reduce loadup time and how to shut these annoying error messages down.

the pvs opcodes will introduce some latency, but it shoudn't really matter for the kind of music this is intended for. i think it's totally worth it and i'm stoked by how this sounds now.

cheers

i had that problem many times as i was working on my patch. it happens when things grow big and complex and i don't think there's one specific reason for why the GUI sometimes just freezes up. you just have to systematically take the patch apart again and see what causes it.

i think all you can do is to try and keep track of what you edit on your patch so you have a better idea of where to look for the problem.

here's the limiter i'm using in my Nigredo patch that you can find in the patches section. it uses cyclones [average~] and [expr~] though, but maybe you can replace those. it has an lop for smoothing and to my ear it sounds perfectly clean. the downside is that it causes quite a bit of delay. the slider regulates the intensity and automatically adds makeup gain so it's easy to use. it can do extreme squeezing without adding artifacts.

http://www.pdpatchrepo.info/hurleur/limiter.pd