p.j.e.batchelor@gmail.com

rufus-replacement-request

A better workaround than the above (in that it guarantees that the data all comes form one frame) is below. You use sah~ off the fft index outlet to hold the selector value across each frame. The timing for the line~ object is crucial in making sure that two frames don't get written consecutively, but either way what gets left in the buffer after writing has stopped will be from one frame.

A better workaround than the above (in that it guarantees that the data all comes form one frame) is below. You use sah~ off the fft index outlet to hold the selector value  across each frame. The timing for the line~ object is crucial in making sure that two frames don't get written consecutively, but either way what gets left in the buffer after writing has stopped will be from one frame.

> what you want to do here is impossible in core Max/MSP.

> Even in the examples that is the case. For instance, even with Jitter, the

> "jitter_pvoc_2D.pat" example embodies this same problem. Because [rufus~] is

> not part of Max/MSP, Richard Dubois had to use [count~]. This is not bad,

> but the incertitude on the frame number still exists.

> If one could synchronize [count~]'s start with an external signal, in that

> case, the fft bin index, that would work (and that would be a nice

> equivalent to rufus~, that other people could use for other applications,

This question of using count has come up before. I don't know the rufus~ object or what exactly it allows, but I can say that using count~ with the third and fourth arguments set to one guarantees that the count~ will synchronise with the fft~. The loadbang in luke dubois's patch is toatlly needless, as the count is being started automaticaly anyway - so there is no "incertitude". This is definitely the case within pfft~ and should be the case otherwise, although beware that this assumes that both objects (fft~/count~) start their dsp at the same time (meaning that re-instansiating the objects, or creating them at different times this could potentially cause problems - although I think this is unlikely or maybe impossible). At any rate there should be a way of deriving further sync signals from the fft~ index outlet if necessary without going outside of MSP. I'm not claiming its as clean a solution, Only that it should be possible.

If someone can give me a very concise and technical explanation of rufus~ maybe I can knock something up quickly for those who want a nice external. No promises though......

> what you want to do here is impossible in core Max/MSP.
> Even in the examples that is the case. For instance, even with Jitter, the
> "jitter_pvoc_2D.pat" example embodies this same problem. Because [rufus~] is
> not part of Max/MSP, Richard Dubois had to use [count~]. This is not bad,
> but the incertitude on the frame number still exists.
>
> If one could synchronize [count~]'s start with an external signal, in that
> case, the fft bin index, that would work (and that would be a nice
> equivalent to rufus~, that other people could use for other applications,
> too).

rufus replacement request