steffensen

Have anyone made a synced delay by any chance?

Been trying all day to figure out how to sync my delay times, to mthe master phasor~, with no luck.

I figure as much, that it gotta have something to do with rate~, as it can do time scale's, but thats about it.

Been trying all day to figure out how to sync my delay times, to mthe master phasor~, with no luck.
I figure as much, that it gotta have something to do with rate~, as it can do time scale's, but thats about it. 

synced-delaytimes

I'd recommend doing a simple timer operation on the signal/data 

you're trying to sync to, then use that result to set the delay time. 

It will at least get you started in the right direction. Even more 

direct would be to simply take the reciprocal of the frequency of the 

master [phasor~] (to get the period) and use this to set the delay 

time. You could also, of course, multiply and/or divide this period 

to get multiples/divisions of the sync signal.

On Dec 30, 2007, at 6:47 PM, steffensen wrote:

> Have anyone made a synced delay by any chance?

> Been trying all day to figure out how to sync my delay times, to 

> I figure as much, that it gotta have something to do with rate~, as 

> it can do time scale's, but thats about it.

I'd recommend doing a simple timer operation on the signal/data  
you're trying to sync to, then use that result to set the delay time.  
It will at least get you started in the right direction. Even more  
direct would be to simply take the reciprocal of the frequency of the  
master [phasor~] (to get the period) and use this to set the delay  
time. You could also, of course, multiply and/or divide this period  
to get multiples/divisions of the sync signal.

>
> Have anyone made a synced delay by any chance?
>
> Been trying all day to figure out how to sync my delay times, to  
> mthe master phasor~, with no luck.
> I figure as much, that it gotta have something to do with rate~, as  
> it can do time scale's, but thats about it.
>
> Any hints, pointers?

----
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe

Home 
SFIFEM 
Atrium Sound Space 
OVOS 
CMP 

Yes, that makes total sense. I presumed this was the way myself, but im still not sure how to do this. Any special object i should have in mind?

Gonna wade thru the manual one more time..

Im sure it could be optimized and improved however, so feel free to jump in anytime. :)

You could also use sync~ instead of phasor~. it directly takes bpm in and

can be synchronised. Look at the example help file.

> #P flonum 58 322 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P newex 65 220 59 9109513 snapshot~ 1;

> #P flonum 152 132 54 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P number 67 62 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

A Pereshaped definition of a rotten Apple:

"You will never know what size worm is in your next apple byte"!

You could also use sync~ instead of phasor~. it directly takes bpm in and
can be synchronised. Look at the example help file.

On 31/12/2007, steffensen  wrote:
>
>
> Actually, this seems to work:
>
> max v2;
> #N vpatcher 316 40 659 494;
> #P button 11 300 15 0;
> #P user ezdac~ 200 342 244 375 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 239 115 14 9109513 1;
> #P newex 66 190 28 9109513 *~ 4.;
> #P flonum 58 322 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 59 301 29 9109513 timer;
> #P newex 65 269 19 9109513 t b;
> #P newex 65 244 48 9109513 change 0;
> #P newex 65 220 59 9109513 snapshot~ 1;
> #P message 208 115 29 9109513 0.75;
> #P message 296 115 14 9109513 4;
> #P message 280 115 14 9109513 2;
> #P message 255 115 23 9109513 1.5;
> #P message 183 115 23 9109513 0.5;
> #P message 152 115 29 9109513 0.25;
> #P flonum 152 132 54 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 66 163 96 9109513 rate~ 1.;
> #P newex 67 84 25 9109513 sig~;
> #P newex 66 107 37 9109513 /~ 240.;
> #P comment 104 63 30 9109513 bpm;
> #P number 67 62 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P objectname bpm;
> #P newex 66 135 58 9109513 phasor~ 1.;
> #P connect 15 0 21 0;
> #P connect 16 0 17 0;
> #P connect 15 0 16 0;
> #P connect 18 0 13 0;
> #P connect 13 0 14 0;
> #P connect 14 0 15 0;
> #P connect 4 0 3 0;
> #P connect 3 0 0 0;
> #P connect 0 0 5 0;
> #P connect 5 0 18 0;
> #P connect 1 0 4 0;
> #P connect 15 0 16 1;
> #P hidden connect 12 0 6 0;
> #P hidden connect 11 0 6 0;
> #P hidden connect 10 0 6 0;
> #P hidden connect 9 0 6 0;
> #P hidden connect 8 0 6 0;
> #P hidden connect 7 0 6 0;
> #P connect 19 0 6 0;
> #P connect 6 0 5 1;
> #P pop;
>
>
> Im sure it could be optimized and improved however, so feel free to jump
> in anytime. :)
>

-- 
A Pereshaped definition of a rotten Apple:
"You will never know what size worm is in your next apple byte"!

The following patch uses another method, but the result is the same.

Is it to use with tapin~/tapout~ or some delay in max domain... or something else ?

Your patch works fine I think. 
The following patch uses another method, but the result is the same.

Is it to use with tapin~/tapout~ or some delay in max domain... or something else ?


Interesting, im gonna try your way also. There is a few ms errors when using audiorate/timer for measuring the delaytimes, would probly be better to do some hard math and get the delaytimes out of pure data instead. But thats over my head as of now.

I can post the patch later, its a bit of a mess atm. But it does the trick for me i spose.

Quote: Bertrand Fraysse wrote on Tue, 01 January 2008 06:15

----------------------------------------------------

> The following patch uses another method, but the result is the same.

> #P flonum 181 120 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P comment 319 304 153 9109513 frequency (Hz) to time period (ms);

> #P comment 232 92 139 9109513 tempo (BPM) to frequency (Hz);

> #P comment 217 57 62 9109513 tempo (BPM);

> #P flonum 181 508 67 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 268 330 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 181 330 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 181 57 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P comment 249 508 44 9109513 error (%);

Im using this with tapin~/tapout~ btw. 
I can post the patch later, its a bit of a mess atm. But it does the trick for me i spose.

Quote: Bertrand Fraysse wrote on Tue, 01 January 2008 06:15
----------------------------------------------------
> Your patch works fine I think. 
> The following patch uses another method, but the result is the same.
>
> #P window setfont "Sans Serif" 9.;
> #P flonum 181 120 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window linecount 1;
> #P comment 319 304 153 9109513 frequency (Hz) to time period (ms);
> #P comment 232 92 139 9109513 tempo (BPM) to frequency (Hz);
> #P comment 217 57 62 9109513 tempo (BPM);
> #P newex 268 448 50 9109513 / 100.;
> #P flonum 181 508 67 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 181 475 97 9109513 / 10.;
> #P newex 181 413 50 9109513 abs 0.;
> #P newex 181 393 50 9109513 - 1000.;
> #P flonum 268 330 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 268 302 50 9109513 !/ 1000.;
> #P flonum 181 330 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 181 302 50 9109513 timer;
> #P user ezdac~ 357 379 401 412 0;
> #P button 181 246 15 0;
> #P flonum 181 57 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 181 91 50 9109513 / 60.;
> #P newex 181 159 65 9109513 phasor~;
> #P newex 181 179 65 9109513 delta~;
> #P newex 181 219 65 9109513 edge~;
> #P newex 181 199 65 9109513 >=~ 0.;
> #P comment 249 508 44 9109513 error (%);
> #P user panel 176 154 76 90;
> #X brgb 191 191 191;
> #X frgb 255 255 255;
> #X border 1;
> #X rounded 0;
> #X shadow 0;
> #X done;
> #P connect 22 0 5 0;
> #P fasten 22 0 12 0 186 146 273 146;
> #P connect 6 0 22 0;
> #P connect 13 0 14 1;
> #P connect 13 0 18 0;
> #P connect 8 0 10 0;
> #P connect 8 0 10 1;
> #P connect 15 0 16 0;
> #P connect 18 0 16 1;
> #P connect 16 0 17 0;
> #P connect 14 0 15 0;
> #P connect 11 0 14 0;
> #P connect 12 0 13 0;
> #P connect 7 0 6 0;
> #P connect 10 0 11 0;
> #P connect 3 0 8 0;
> #P connect 5 0 4 0;
> #P connect 4 0 2 0;
> #P connect 2 0 3 0;
> #P window clipboard copycount 23;
>
> Is it to use with tapin~/tapout~ or some delay in max domain... or something else ?
>
----------------------------------------------------


When putting your patch under close examination, i notice you have a solution without using Timer, and i thank you for that. :)

Good to have both solutions for further usage now!

When putting your patch under close examination, i notice you have a solution without using Timer, and i thank you for that. :)
Good to have both solutions for further usage now!


I would definitely steer clear of using timer to do this. It seems (to me) to be a very roundabout way of getting back a value that you yourself have set (in phasor~ or sync~).

Even more direct would be to simply take the reciprocal of the frequency of the

master [phasor~] (to get the period) and use this to set the delay

time. You could also, of course, multiply and/or divide this period

Like smill said:
Even more direct would be to simply take the reciprocal of the frequency of the
master [phasor~] (to get the period) and use this to set the delay
time. You could also, of course, multiply and/or divide this period
to get multiples/divisions of the sync signal.


i dont really get what smaill means by taking the reciprocal of the freq tho.

Im using the math delivered by Bertrand in his patch above now however, and it works like a charm!

Quote: Wetterberg wrote on Tue, 01 January 2008 12:24

> I would definitely steer clear of using timer to do this. It seems (to me) to be a very roundabout way of getting back a value that you yourself have set (in phasor~ or sync~).

> Even more direct would be to simply take the reciprocal of the frequency of the

> master [phasor~] (to get the period) and use this to set the delay

> time. You could also, of course, multiply and/or divide this period

> to get multiples/divisions of the sync signal.

Yes youre right,
i dont really get what smaill means by taking the reciprocal of the freq tho.
Im using the math delivered by Bertrand in his patch above now however, and it works like a charm!

Quote: Wetterberg wrote on Tue, 01 January 2008 12:24
----------------------------------------------------
> I would definitely steer clear of using timer to do this. It seems (to me) to be a very roundabout way of getting back a value that you yourself have set (in phasor~ or sync~).
>
> Like smill said:
> Even more direct would be to simply take the reciprocal of the frequency of the
> master [phasor~] (to get the period) and use this to set the delay
> time. You could also, of course, multiply and/or divide this period
> to get multiples/divisions of the sync signal.
----------------------------------------------------


I agree wth Andreas in that it seems a tad long winded. Stay clear of

1000 multiplied by 0.01 (same thing very much faster.

> I would definitely steer clear of using timer to do this. It seems (to me)

> to be a very roundabout way of getting back a value that you yourself have

> Even more direct would be to simply take the reciprocal of the frequency

I agree wth Andreas in that it seems a tad long winded. Stay clear of
division it is unfriendly.

On 01/01/2008, Andreas Wetterberg  wrote:
>
>
> I would definitely steer clear of using timer to do this. It seems (to me)
> to be a very roundabout way of getting back a value that you yourself have
> set (in phasor~ or sync~).
>
> Like smill said:
> Even more direct would be to simply take the reciprocal of the frequency
> of the
> master [phasor~] (to get the period) and use this to set the delay
> time. You could also, of course, multiply and/or divide this period
> to get multiples/divisions of the sync signal.
>

Synced Delaytimes?