multislider fft panner
I have a multislider with 1024 sliders. It takes values of 0-1. I am trying to stochastically fill that table with uzi rand/drunk, pack & co. to make a nice scatter pattern that would work with nicely with this FFT panner more or less cribbed from the Baz patch 16 I believe(?). For a static FFT panner you would probably ideally want something that had roughly equal energy on both sides (R & L) so that is one reason why I am using drunk though likely other types of noise would likely be better (this is just quick and dirty to get started). Though the whole idea of "equal" would have to take into account that there is significantly more energy likely in the lower bands etc.
I am not sure the thing I have is really working properly (it seems to be). I am not sure if:
1. I am filling the whole multislider (are all sliders set? do I have an off by 1 anyplace?)
2. or if I am giving it values that are out of the range. (the whole [drunk 1000 50] -> [/ 1000.] is a kludge i guess)
So any suggestions on improving the auto fill part of the multislider or better strategies for setting those sliders would be welcome.
or even just some ideas about improving the panner portion…. why do we get such whooshing when the phasor is set to anything higher than .001? at that slow a rate it couldn't be audio aliasing could it?
cheers,
kevin
hey, pretty cool. Fun to mess with.
Looks like the multislider part is fine, you're staying in the range and you're filling all the sliders. You can trim up (and maybe speed up) a few things, like how it's loaded and read out, with [zl group] and [listfunnel]. Also the buffer~ can be made to the right length (just as big as you need, no bigger) with the "sizeinsamps" message:
With an fft size of 1024, half of that amount of values is sufficient. The size of multislider doesn't need to be bigger than 512.
An improvement could be found in how the multislider is mapped. Because the sequence of bins represent a linear frequency scale, the vast majority of all those bins is in the higher frequencies. Setting a panning curve based on midi values creates a more balanced control. The number of sliders can then be limited to a much smaller number, each slider representing a portion of an octave. The conversion of bin to frequency and midi to frequency are therefor used in the attached patch.
I realize that the phasor does not work anymore, but the whole idea might be realized within the signal domain.
Hope all this makes a bit of sense.
_
johan
Thanks. I see how the sizeinsamps message makes the buffer the correct size. I hadn't even gotten around to thinking about that. I guess that buffer was just artificially humongous. I see now how zl group and listfunnel makes this more elegant. Excellent tips those.
Some of the things Johan pointed out about the mapping were things I meant to articulate more clearly., about how some small fraction of the bins have the vast majority of the energy and clearly an FFT size of 1024 obviously doesn't mean we need a 1024 multislider! 512 or 256 is probably plenty. But I am going to have to think a while on your patch to get my head around it and I am not sure how to fix the broken phasor. I need to meditate on that .. but watching that break point function move around like that is exciting stuff. Hm…
cheers,
Kevin
Couldn't leave it at this... In this example the indexes coming from the right outlet of fftin~ are converted to frequencies and scaled to a certain amount of equally wide pitch bands. The panning value of each of these bands can then be retrieved using index~. Moreover an offset that can be modulated is possible. I didn't actually test it, does it work?
_
johan
oh nice. Thanks. I 'll give it ago. But it'll have to wait till this cocktail of sudafed & advil kicks in. My whole face hurts. I don't even have enough energy to shake my fist at my neti pot. ugh. Sinuses, I curse you!
I am back at this after fighting off a cold and doing some other work...
It's time for me to man up (man down? woman up? 7 up?) & admit that i am not sure what is happening in this patch.
I wonder if I could get some clarifications. I think that we are mapping the original 50 data points that come out of the uzi/mulitislider construct at the top. This is where the spectral space is sliced up and assigned a spot in the stereo field.
This goes through some logic which makes a better, less linear division of our spectral segments. Since a linear mapping means that a lot of our movement is wasted on the very highest part of the spectra where there is not much action. This is what the main improvement is in this version.
These segments are mapped on the function (nice to see a visualization of how much more log-esque it is now!) This function data is then stuffed the pancurve buffer with the values which are read/indexed in the fft-filter patches.
So we use 50 data points to map (log) a 512 sample buffer but we have 1024 fft bins?
The phasor biz seems broken now and further more there is now a discrepancy between the number of fft bands(1024) and the size of our buffer (512). Do we fix this by just making the buffer 1024 or fix the fft subpatcher to read each index twice? I am confused.
Am I sort of right?
cheers,
-kp--
johan,
Your second post with the signal version one I did not grok. Is there some (sonic) benefit to doing it all as a signal as opposed to doing it in control rate / old school max? I guess the whole thing would be smoother (esp. moving pan)?
I am still hoping for an assist on this, or at least a teaching moment. Both for the educational value and since this fft panner is pretty dang cool.
Hate to bada~bump, but
Anyone....
Was too busy, took me a while to respond. This patch implements what I tried to explain earlier. The central aspect of this patch is the conversion from bin number to (a reduction of) midi note number (after ftom~). Based on this conversion the bin numbers are warped to index values in the pan curve. This patch shows clearly the issue with fft, which lacks definition in the lower frequencies.
_
johan
Johan,
Thanks for the reply. Sorry to bump the thread & prod. I just thought it was past everyone's radar. I am going to look at this patch tonight and comment it up and see if i can get my head around the new bits but once i reconnected the missing patch chords (the pfft~ obviously can't be found until after you save it, is why i am guessing?) from the pfft~ and dac~ I can clearly see that it works and that the mappings in the multislider correspond with what you would expect. It is a lot more musical, sensible and manageable to see those 50 sliders mapped that way instead of fussing with all those sliders up in high that probably have little or no effect. It is easier to make meaningful changes this way.
This solution is really elegant. Many thanks for taking the time. Perhaps others will enjoy messing with this patch too and thanks to Barry for the initial bits that prompted all this. A multi (4, 8) channel version would be super sexy~
Time for study~
-kp--
Those uzi/multislider setups are ingenious. uzi 50 --> % 2 seems so obvious but I never would have thought to do that. I also played with zmap to make some nice shapes for example if you want that > shape to not go all the way to the far right and left you could do some variation on:
perhaps that is not centered... but
I wonder what is a sleek way to make the a V shape. I would think, for example that that would be common to have the lower freqs. more center and the high sizzle spread more for, say, percussion.
Also i know the canonic way to get a rand float value is
and I see that you used something similar to get us the range for the random scatter. But what if you want to exclude the extremes and just have a scatter that went 95% L and 95% R..... say if you were making a headphone mix and didn't want to drop out one channel completely? just use [zmap 0 1 0.05 0.95]? that was the only way i could think to do it off the top of my head.
Pretty amazing. The only downside is that i hear the background noise of my samples (tiny as it is) swooshing from the phasor, even at .001.
Fun stuff though. Thanks again for all your help.
-kp--