Advanced Max: FFTs, Part 4
Now that we've got the basics for understanding FFT processing in Max, let's pull it all together and make something wonderful. This week's 42-minute video pulls pieces together from previous installments of this series to create a Max for Live device that does independent processing of each band of audio to produce spectacular results!
- Download the patches used in this tutorial.
- mrhayApr 11 2017 | 12:31 amThanks once again for these and do please, if possible, keep this sort of content coming!Peace.
- stkrApr 14 2017 | 1:42 pmthanks tim as ever. the 'advanced' tutorial series in general is fantastic.however, i am slightly perplexed by this #4 tut, and have to be a whinger here...1) unless something wonderful has been developed since the last time i checked a few years ago, @parallel for poly~ does not work in M4L - nor do most of poly~s useful features, such as dynamic loading etc. poly~ is half crippled in the Live environment 'cos of each track being on a thread etc.2) i really do comprehend pedagogy and ordering tutorials to introduce concepts and learn better through doing, but is it really actually useful to make a poly~based multiband delay that takes up 30% CPU in live (20% in max 'cos @parallel works there)? especially when there are very well known and far better and just as easy to comprehend techniques already out there, such as the olivier pasquet / manual poletti "Max Spectral Delay" that has always come with M4L, is far higher quality and uses only 3 or 4 % cpu ? :-)
- jonathan segelApr 15 2017 | 10:18 amYeah, 30-40% cpu is a killer, though I like the vertical GUI—it reminds me of FreqTweak! All we need is an LFO now.
- brendan mccloskeyApr 15 2017 | 10:27 am@stkrgood points and observations; may I make one? Sometimes reinventing the wheel is useful as a didactic exercise/approach, so that others can build other wheel-types and non-wheels. Although, as I began watching this, my immediate thoughts centred on CPU demands and M4L restrictions.Great series, with much to learn. Kinda got lost around the framecount quantization, but that's my failing.
- Timothy PlaceApr 17 2017 | 3:41 pmAll fair points, and I appreciate the feedback!It can certainly be perplexing trying to balance legit concerns of advanced users (e.g. cpu load and resource management) and clarity for folks aspiring to become advanced users. I certainly don't always get it right.For what I was trying to accomplish, Manuel's awesome spectral delay device was a bit too magical. Because of the way the delays are managed with the shared tapin~/tapout~ objects it is almost impossible to explain without drawing lots of elaborate illustrations on a white board.I was also hoping to provide a framework where other types of spectral processing could be explored, not just a delay. The suggestion here for adding band-specific LFOs is a great example.I'm embarrassed to say that I forgot that MFL doesn't support poly @parallel 1. I developed the patcher initially in Max and that feature makes a huge difference in Max. Hopefully it is still useful for folks to know about the feature.
- hz37May 08 2017 | 8:48 amThanks bunches for this series! The spectral delay eats 4% CPU on my laptop, btw. I hope you can add more to this series, like gen~ stuff. It is much appreciated!
- SjoerdMay 13 2017 | 9:22 amGreat Tutorial! Definitely that @ parallel 1 was a good insight. That cmnd-j shortcut slipped my mind, thanks again.Wouldn't it be great to have another way to initialize a new saved poly~ instead of always change the name, or delete and undo?Looking forward to the next one, very good level!
- Lorenzo LamasseJan 19 2022 | 11:08 amThis patch is making Max crash systematically at editing when used in Live, though it opens well direclty in Max. I seem to have seen that putting poly~ inside a pfft~would be the culprit, can you confirm that ? And update the description accordingly as it's quite a caveat ? Tested under 8.2.0/OSX Mojave and Live 11.0.12 Thanks !