While Jean François-Charles’ article is completely seminal in terms of its explanation of spectral processing once the user has acquired their DSTFT data, he does not explain how to collect that data in Max in the first place. This had always been the most mystifying part of the process to me, so over the last few weeks I have been studying studying Luke Dubois’ jitter_pvoc_2D and Cycling 74’s article on implementing phase vocoders in Max.
The directory path where you can find Luke Dubois’ ‘jitter_pvoc_2D’: /Cycling ’74/Max 8/Examples/jitter-examples/audio/jitter_pvoc
I’m glad that Max has the functionality to be able to offer the user a relatively large freedom in terms of how they want to conduct the DSTFT, this choice has left me slightly overwhelmed. There have been two major choices to make in relation to DSTFT data collection: whether to use the ‘fft~’ or ‘fftin~’ object (inside a ‘pfft~’) and whether to use a ‘jit.matrix’ or a ‘buffer~’ to actually store the data. While the exact differences between the options are outlined in my project writeup in ‘1.1 main’, it is worth mentioning that both Jean François-Charles, Luke Dubois and Cycling 74 advised against the ‘fft~’ object, as it does not offer as much in-built functionality as ‘fftin~’.
One distinction I also struggled with was that between frame size and spectral frame size. Speaking to my supervisor and investigated the effect of the Nyquist frequency on DSTFT data collection really cleared this confusion up for me. As I have the full spectrum flag disabled on the ‘pfft~’ object, the frame size (N irrespective of the Nyquist frequency) is the same as my spectral frame size (DSTFT data up to 0.5N).
Making the decision between using a ‘buffer~’ or ‘jit.matrix’ to store the DSTFT data was one that I considered intensively. Up until last week it has been slightly unclear as to how this choice will affect me further down the line in the project. While I’ve been trying to come to a decision, I’ve also been considering whether using the objects in tandem could be a possibility to ensure I get maximum functionality out of both. In terms of storage of data, the answer to that is essentially no, the choice is whether to store data in one form or the other: you can store it in both if you like but wouldn’t be for the betterment of the project. Having chosen to collect DSTFT data through the ‘fftin~’ object and store it in a ‘jit.matrix’, there is one way in which buffer~ can be used alongside my patch. With ‘buffer~’ you can store a custom windowing function that can be called by the ‘fftin~’ object, but this is not a useful function for me as I have chosen to use the hanning window (which is already incorporated into the ‘fftin~’ object as it provides no amplitude modulation and a clean envelope.
Cycling 74’s article has also cleared up how ‘jit.poke~’ is synchronised with the data output from the DSTFT and then used to place this data in a ‘jit.matrix’. Specifically it was learning about how the 2nd inlet in this object controls the horizontal data placement and how the 3rd controls the vertical placement that that helped me grasp how ‘jit.poke~’ works in the DSTFT data collection process.
