Forums > MaxMSP

rufus replacement request

November 5, 2006 | 9:10 pm


November 5, 2006 | 10:00 pm


November 5, 2006 | 11:53 pm


November 6, 2006 | 12:17 am

Hi Pete,

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.

Hope this helps,

Alex

#P window setfont "Sans Serif" 9.;
#P user number~ 247 259 286 274 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P message 263 137 80 196617 1 , 1 46.44 2 0;
#P newex 262 161 41 196617 line~ 2;
#P newex 126 177 31 196617 sah~;
#P window linecount 4;
#P comment 355 150 232 196617 wait long enough to be sure the whole spectrum is analysed (not only half of it) 46.44 is twice the duration of the buffer , that displays only the first half of the fft output.;
#P toggle 82 45 15 0;
#P window linecount 1;
#P newex 82 71 31 196617 adc~;
#P user number~ 173 280 212 295 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 190 229 43 196617 sig~ -1;
#P message 323 245 86 196617 set eq , voffset 1;
#P user waveform~ 321 266 278 65 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W voffset 1.;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P newex 355 210 87 196617 buffer~ eq 23.22;
#P button 302 96 15 0;
#P comment 322 96 152 196617 trigger to capture spectrum;
#P newex 74 160 33 196617 sqrt~;
#P newex 74 129 27 196617 *~;
#P newex 114 129 27 196617 *~;
#P newex 120 303 49 196617 poke~ eq;
#P newex 139 253 62 196617 selector~ 2;
#P newex 82 102 89 196617 fft~ 2048 2048 0;
#P window linecount 2;
#P comment 173 298 77 196617 -1: poke does not record;
#P connect 18 0 17 0;
#P connect 1 2 17 1;
#P connect 1 2 2 1;
#P connect 17 0 2 0;
#P connect 17 0 20 0;
#P connect 8 0 19 0;
#P connect 19 0 18 0;
#P connect 1 1 4 0;
#P connect 1 1 4 1;
#P connect 1 0 5 0;
#P connect 1 0 5 1;
#P connect 5 0 6 0;
#P connect 4 0 6 0;
#P connect 15 0 14 0;
#P connect 14 0 1 0;
#P connect 6 0 3 0;
#P connect 12 0 2 2;
#P connect 11 0 10 0;
#P connect 2 0 13 0;
#P connect 2 0 3 1;
#P window clipboard copycount 21;


November 6, 2006 | 12:34 am

> 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).

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……

Alex


November 6, 2006 | 2:16 am


November 6, 2006 | 3:12 am


November 6, 2006 | 10:17 am


November 6, 2006 | 5:47 pm


Viewing 9 posts - 1 through 9 (of 9 total)