train~ to trigger phasor~

Sep 12, 2007 at 12:59pm

train~ to trigger phasor~

hey list,

i would like to generate a ramp from 0-1 that can be triggered periodically to use for triggering grains via play~ in a granular synthesiser. currently i’m using metro and line~ but am wondering if an entirely msp/signal solution would be more efficient. if so, it appears some combination of train~ and phasor~ would suffice but i can’t figure it out. any ideas?

sorry no patch to demonstrate but i’m currently at work…

thanks in advance,

don

#33643
Sep 12, 2007 at 7:27pm

Quote: dondelion wrote on Wed, 12 September 2007 06:59
—————————————————-
> hey list,
>
> i would like to generate a ramp from 0-1 that can be triggered periodically to use for triggering grains via play~ in a granular synthesiser. currently i’m using metro and line~ but am wondering if an entirely msp/signal solution would be more efficient. if so, it appears some combination of train~ and phasor~ would suffice but i can’t figure it out. any ideas?
>
> sorry no patch to demonstrate but i’m currently at work…

train~ and cycle~, with cycle~ playing a ramp (and not a sine)

#112333
Sep 12, 2007 at 9:43pm

nope…i still don’t get it! more clues needed…

#112334
Sep 13, 2007 at 7:41am

On 12 Sep 2007, at 23:43, donovan sellings wrote:

>
> nope…i still don’t get it! more clues needed…

you might have a look at [zigzag~].
similar to [line~], but can be triggered by a signal (mode 1), and
has some other useful features.
afaik, depending on sigvs it’s not 100% accurate, so i wouln’t use it
as an oscillator.
but as control signal it’s fine.
vb

#112335
Sep 13, 2007 at 10:15am

I’ve done this with train~ and rampsmooth~ but it goes from 0-1 only once each pulse. As parts of this patch are message/event based rather than signal based does that make it less efficient and accurate?

What I would really like to do is use some form of phasor~/cycle~ to go from 0-1 at a specified frequency within each pulse rather than just once…

max v2;
#N vpatcher 15 55 643 420;
#P origin 0 15;
#P user ezdac~ 487 188 531 221 0;
#P user scope~ 318 282 448 412 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 307 41 53 9109513 pulse width;
#P flonum 315 59 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 252 59 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 212 111 27 9109513 !/ 1.;
#P newex 274 215 27 9109513 *~;
#P newex 329 92 107 9109513 expr ($f1/1000.)*44100.;
#P newex 255 113 40 9109513 train~;
#P newex 283 179 93 9109513 rampsmooth~ 44100;
#P message 329 120 52 9109513 rampup $1;
#P comment 245 42 53 9109513 pulse time;
#P connect 8 0 6 0;
#P connect 7 0 3 0;
#P connect 8 0 3 1;
#P connect 2 0 5 0;
#P connect 3 0 2 0;
#P connect 1 0 2 0;
#P connect 6 0 5 1;
#P connect 5 0 10 0;
#P connect 7 0 4 0;
#P connect 4 0 1 0;
#P pop;

#112336
Sep 13, 2007 at 11:08am

Quote: dondelion wrote on Thu, 13 September 2007 11:15
—————————————————-
> I’ve done this with train~ and rampsmooth~ but it goes from 0-1 only once each pulse. As parts of this patch are message/event based rather than signal based does that make it less efficient and accurate?

it certainly makes it less accurate, but it really depends on what you want to control. i recommend you take a look at

> What I would really like to do is use some form of phasor~/cycle~ to go from 0-1 at a specified frequency within each pulse rather than just once…

here’s a quick demo made with zigzag, to try and illustrate what it can do.

j

#P window setfont “Sans Serif” 9.;
#P window linecount 2;
#P comment 338 307 100 196617 speed multiplier (pitch);
#P window linecount 1;
#P newex 380 119 27 196617 100;
#P newex 252 421 27 196617 *~;
#P button 530 173 15 0;
#P flonum 597 227 86 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 295 307 41 196617 *~ 0.2;
#P newex 252 457 52 196617 play~ buf;
#P newex 519 193 105 196617 info~ buf;
#P message 468 154 76 196617 read jongly.aif;
#P newex 468 173 61 196617 buffer~ buf;
#P flonum 295 152 47 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 314 71 27 196617 1;
#P newex 295 192 40 196617 train~;
#P newex 252 42 48 196617 loadbang;
#P window linecount 2;
#P newex 314 109 52 196617 prepend loopmode;
#P user umenu 314 90 63 196647 1 64 106 1;
#X add off;
#X add on;
#X add pendulum;
#P user scope~ 29 367 159 497 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P user ezdac~ 218 517 262 550 0;
#P window linecount 1;
#P message 252 90 61 196617 0 0 1 1000;
#P newex 252 329 53 196617 zigzag~;
#P window linecount 2;
#P comment 343 152 100 196617 ms interval (grain interval);
#P connect 7 0 2 0;
#P fasten 7 0 9 0 257 65 319 65;
#P fasten 7 0 19 0 257 63 385 63;
#P fasten 7 0 12 0 257 62 473 62;
#P fasten 19 0 10 0 385 148 300 148;
#P connect 8 0 15 0;
#P connect 15 0 1 1;
#P connect 14 0 3 0;
#P connect 14 0 3 1;
#P fasten 1 0 4 0 257 356 34 356;
#P connect 1 0 18 0;
#P connect 10 0 8 0;
#P connect 18 0 14 0;
#P fasten 16 0 18 1 602 420 274 420;
#P connect 17 0 13 0;
#P connect 13 6 16 0;
#P connect 11 1 13 0;
#P connect 12 0 11 0;
#P connect 9 0 5 0;
#P fasten 6 0 1 0 319 143 257 143;
#P connect 5 0 6 0;
#P connect 2 0 1 0;
#P window clipboard copycount 21;

#112337
Sep 13, 2007 at 11:12am

oops, to eager to press submit.

i recommend you take a look at some of the old granular patches kicking round the forum. there was a good one i learnt a lot from by nobuyasu sakodna…

or send in a patch with the granular part so we can get a better understanding of what you are trying to achieve.

j

#112338
Sep 13, 2007 at 12:43pm

Deconstructing nobuyasu’s patch has been very helpful in understanding the basics of granular synthesis but as far as I see his patch generates grains with a duty cycle of 1 – there is no ‘space’ between grains. I am using the basics of his patch but I would like to specify grain length, grain interval and pitch whereas his patch uses grain length, pitch and start time offset.

Or am I missing something?

I’ll try zigzag~ when I get home and post a patch demonstrating what I mean…

Thanks for the replies!

#112339
Sep 13, 2007 at 9:02pm

Don:

You might want to check out Nathan Wollek’s granular toolkit; perhaps
the train.shift~ or phasor.shift~ objects might do what you need?

jason

On Sep 12, 2007, at 7:59 AM, donovan sellings wrote:

>
> hey list,
>
> i would like to generate a ramp from 0-1 that can be triggered
> periodically to use for triggering grains via play~ in a granular
> synthesiser. currently i’m using metro and line~ but am wondering
> if an entirely msp/signal solution would be more efficient. if so,
> it appears some combination of train~ and phasor~ would suffice but
> i can’t figure it out. any ideas?
>
> sorry no patch to demonstrate but i’m currently at work…
>
> thanks in advance,
>
> don

Jason Geistweidt, Phd, MA, BMus

“Sound still remains to be deciphered, hence the idea of an
introduction to the sound object to train the ear to listen in a new
way: this requires that the conventional listening habits imparted by
education first be unlearned.”

::Pierre Schaeffer, Solfege de l’objet Sonore (1966)

#112340
Sep 13, 2007 at 9:47pm

I am using the toolkit already but wanted to ‘get under the hood’ as it were and create some granular synthesis patches from scratch. I just bought ‘Microsound’ and would like to experiment!

#112341
Sep 14, 2007 at 12:21am

Here’s a patch (hopefully) demonstrating what I am trying to achieve.

I fill a buffer using gen10 (from percolate) and play this using play~. I am trying to use train~ to generate pulses at a specified interval to scan the buffer at a specified pulse-width (grain length) and frequency. This method would be similarly used to scan the windowing buffer but without having to take frequency into account. I am hoping to keep everything as signals to keep it tight timing-wise. I think Roman’s idea using train~ and cycle~ is feasible but I just can’t quite get it!
I’ve also tried with zig-zag but can’t get it to lock with train~ – there’s a subpatch with my attempt. Would using sah~ as in Nobuyasu’s patch help?

So many questions…

Any help, as always, much appreciated…

max v2;
#N vpatcher 217 102 1146 714;
#P origin 0 46;
#P window setfont “Sans Serif” 9.;
#N vpatcher 15 55 498 523;
#P window setfont “Sans Serif” 9.;
#P flonum 90 90 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 135 6 45 9109513 loadbang;
#P message 209 40 16 9109513 1.;
#P message 160 42 26 9109513 500.;
#P message 96 42 31 9109513 1000.;
#P window linecount 1;
#P newex 128 221 27 9109513 *~;
#P message 261 87 39 9109513 mode 1;
#P newex 94 122 40 9109513 train~;
#P message 253 123 56 9109513 loopmode 1;
#P user scope~ 162 274 292 404 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P flonum 206 85 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 206 123 25 9109513 sig~;
#P newex 159 181 53 9109513 zigzag~;
#P number 158 86 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 159 123 58 9109513 0 0 1 $1 0 0;
#P comment 149 68 49 9109513 length;
#P comment 206 67 100 9109513 speed;
#P comment 84 63 100 9109513 interval;
#P connect 13 0 17 0;
#P connect 17 0 10 0;
#P connect 16 0 13 0;
#P connect 10 0 12 0;
#P connect 5 0 12 1;
#P connect 14 0 4 0;
#P connect 4 0 3 0;
#P connect 3 0 5 0;
#P connect 9 0 5 0;
#P connect 11 0 5 0;
#P connect 10 0 5 0;
#P connect 16 0 14 0;
#P connect 12 0 8 0;
#P connect 6 0 5 1;
#P connect 15 0 7 0;
#P connect 7 0 6 0;
#P connect 16 0 15 0;
#P connect 16 0 9 0;
#P connect 16 0 11 0;
#P pop;
#P newobj 111 89 65 9109513 p zig-zag_test;
#P newex 339 131 27 9109513 t f f;
#P newex 340 106 27 9109513 / 0.;
#P newex 278 65 53 9109513 t f f b f;
#P newex 340 222 27 9109513 !/ 1.;
#P newex 322 311 27 9109513 *~;
#P newex 299 162 107 9109513 expr ($f1/1000.)*44100.;
#P newex 250 199 40 9109513 train~;
#P newex 331 275 93 9109513 rampsmooth~ 44100;
#P message 299 195 52 9109513 rampup $1;
#P newex 543 -70 66 9109513 t b b b b b;
#P message 429 -26 26 9109513 200.;
#P message 472 -27 21 9109513 50.;
#P message 604 -27 74 9109513 1. 0.5 0.25 0.4;
#P message 574 -29 16 9109513 0.;
#P message 542 -29 26 9109513 100.;
#P newex 542 -99 45 9109513 loadbang;
#P flonum 324 33 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 277 32 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 673 238 38 9109513 replace;
#P newex 520 149 27 9109513 t f f;
#P message 576 206 37 9109513 size $1;
#P message 520 205 37 9109513 size $1;
#P newex 520 174 107 9109513 expr ($f1/1000.)*44100.;
#P flonum 520 131 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 743 330 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 665 292 105 9109513 info~ Waveform;
#P user scope~ 409 437 539 567 256 3 128 0. 1. 0 0. 0 1.2 102 255 51 135 135 135 0;
#P user ezdac~ 223 518 267 551 0;
#P newex 650 76 21 9109513 win;
#P user multiSlider 657 163 143 69 0. 1. 4 2937 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P objectname multiSlider;
#P user umenu 657 127 143 9109543 1 64 143 1;
#X add gauss;
#X add quasi-gauss;
#X add triangle;
#X add 3stage-linear;
#X add hanning;
#X add hamming;
#X add blackman;
#X add blackman-harris;
#X add expodec;
#X add rexpodec;
#P objectname umenu;
#P newex 679 75 91 9109513 buffer~ win 11.6099;
#P newex 669 260 87 9109513 buffer~ Waveform;
#P newex 518 265 81 9109513 peek~ Waveform;
#P newex 518 238 64 9109513 gen10 8192 0;
#P newex 311 360 51 9109513 wave~ win;
#P newex 221 414 99 9109513 *~;
#P newex 225 360 79 9109513 play~ Waveform;
#P comment 506 113 100 9109513 buffer length;
#P comment 256 15 53 9109513 pulse time;
#P comment 94 278 143 9109513 how to specify pitch here? —->;
#P comment 323 12 52 9109513 grain len;
#P comment 657 109 100 9109513 window;
#P comment 657 146 100 9109513 harmonics;
#P connect 6 0 7 0;
#P connect 7 0 16 0;
#P connect 37 0 6 0;
#P connect 41 0 37 0;
#P connect 7 0 16 1;
#P connect 43 1 37 1;
#P connect 33 0 26 0;
#P connect 26 0 41 0;
#P connect 41 1 38 0;
#P connect 38 0 35 0;
#P connect 8 0 7 1;
#P connect 39 0 8 0;
#P connect 36 0 39 0;
#P connect 32 0 27 0;
#P connect 37 0 36 0;
#P connect 35 0 36 0;
#P connect 42 0 43 0;
#P connect 40 0 39 1;
#P connect 27 0 42 0;
#P connect 41 2 42 0;
#P connect 43 0 40 0;
#P connect 41 3 42 1;
#P connect 39 0 17 0;
#P connect 34 0 33 0;
#P connect 34 1 32 0;
#P connect 22 0 9 0;
#P connect 14 0 9 0;
#P connect 9 0 10 0;
#P connect 29 0 20 0;
#P connect 20 0 24 0;
#P connect 24 0 21 0;
#P connect 21 0 22 0;
#P connect 34 4 29 0;
#P connect 28 0 34 0;
#P connect 34 2 30 0;
#P connect 24 1 23 0;
#P connect 34 3 31 0;
#P connect 13 0 15 0;
#P connect 30 0 15 0;
#P connect 31 0 14 0;
#P connect 11 1 18 0;
#P connect 25 0 11 0;
#P connect 23 0 11 0;
#P connect 18 6 19 0;
#P pop;

#112342
Sep 14, 2007 at 12:49am

#112343
Sep 14, 2007 at 12:51am

Actually the method I’m proposing is better suited for wave~ not play~…

#112344
Sep 16, 2007 at 9:54am

donovan sellings schrieb:
> Actually the method I’m proposing is better suited for wave~ not play~…

Reading the thread I was wondering all the time: whats wrong with
phasor~ -> wave~… ;-)
And I also don’t get why Roman would put a sawtooth into cycle~ instead
of just using a phasor~…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#112345
Sep 16, 2007 at 11:47am

#112346
Sep 16, 2007 at 3:00pm

Hey..

The problem with using train~ into phasor~ is that when a frequency value of 0 is sent the oscillator does not send out a value of 0 but sends out its most recent value. To use as a control signal I need the oscillator output to be 0 when the ouput of train~ is 0.

Here’s a patch hopefully demonstrating the problem with phasor~…

max v2;
#N vpatcher 186 165 607 594;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 138 65 14 9109513 1;
#P newex 138 36 45 9109513 loadbang;
#P flonum 181 104 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 209 156 27 9109513 *~;
#P flonum 271 33 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user scope~ 217 238 347 368 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P flonum 225 35 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 223 61 40 9109513 train~;
#P newex 215 182 41 9109513 phasor~;
#P user ezdac~ 117 151 161 184 0;
#P connect 8 0 9 0;
#P connect 9 0 7 0;
#P connect 2 0 6 0;
#P connect 6 0 1 0;
#P connect 1 0 4 0;
#P connect 3 0 2 0;
#P connect 7 0 6 1;
#P connect 5 0 2 1;
#P pop;

Wrt to train~ to cycle~ with a ramp buffer using phase to control frequency – I still need to drive the phase with a phasor~ and I can’t seem to get train~ and phasor~ in sync. I think my problem will be the same as above – when phase is 0 cycle~ will output its most recent value rather than 0.

I have succeeded in doing what I wish by using zigzag~ but still think there’s a more elegant solution and would love to see it.

Here’s my version…

max v2;
#N vpatcher 256 143 1114 730;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 160 204 31 9109513 *~ -1.;
#P newex 157 79 27 9109513 t b f;
#P newex 158 113 27 9109513 / 0.;
#P user scope~ 177 391 307 521 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P outlet 122 378 15 0;
#P newex 260 162 45 9109513 loadbang;
#P newex 122 310 83 9109513 rampsmooth~ 100;
#P user number~ 351 53 390 68 9 139 3 1 0. 0. 0 1. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 326 193 56 9109513 loopmode 1;
#P flonum 125 53 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 288 51 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 122 279 27 9109513 *~;
#P newex 123 146 57 9109513 train~ 1000.;
#P message 260 195 39 9109513 mode 1;
#P message 169 176 58 9109513 0 0 1 $1 0 0;
#P newex 171 240 53 9109513 zigzag~;
#P comment 107 33 61 9109513 interval;
#P comment 177 34 100 9109513 grain length;
#P window linecount 2;
#P comment 289 19 45 9109513 buffer length;
#P window linecount 1;
#P comment 349 30 100 9109513 speed;
#P flonum 176 54 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P connect 8 0 9 0;
#P connect 9 0 14 0;
#P connect 14 0 16 0;
#P connect 11 0 8 0;
#P connect 5 0 9 1;
#P connect 18 0 8 1;
#P connect 11 0 19 0;
#P connect 19 0 18 0;
#P connect 0 0 18 0;
#P connect 8 0 20 0;
#P connect 10 0 6 0;
#P connect 20 0 5 0;
#P connect 6 0 5 0;
#P connect 7 0 5 0;
#P connect 12 0 5 0;
#P connect 19 1 18 1;
#P connect 14 0 17 0;
#P connect 13 0 5 1;
#P connect 15 0 7 0;
#P connect 15 0 12 0;
#P pop;

#112347
Sep 16, 2007 at 5:16pm

see what i mean, stefan?

-110

#112348
Sep 17, 2007 at 6:33am

Roman Thilenius schrieb:
>
>> And I also don’t get why Roman would put a sawtooth into cycle~
>> instead of just using a phasor~…
>>
>> Stefan
>
> yeah, maybe because granular synthesis is an audio application and
> cycle~ allows signal input for the phase?

But if I feed a signal into the phase input of a cycle with a saw, all I
get is exactly that phase signal, then I don’t need a cycle~ at all…

A signal phase input to a phasor~ just doesn’t make sense…

> i dont need to tell you that there is a message saying “help, how do
> i sync 2 phasor~ in MSP?” about every 3-4 days in this forum.

Yes, but not in this thread…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#112349
Sep 17, 2007 at 6:47am

donovan sellings schrieb:
> Hey..
>
> The problem with using train~ into phasor~ is that when a frequency
> value of 0 is sent the oscillator does not send out a value of 0 but
> sends out its most recent value. To use as a control signal I need
> the oscillator output to be 0 when the ouput of train~ is 0.

That’s expected behaviour, because you would need to define somehow how
to reach that zero value. This could be achieved with a dedicated
oscillator object, which would only switch frequencies on zero crossing.

But of course, if you don’t mind clicks, you can use a gate~ to achieve
this… (or use matrix~ if you mind clicks…)

Stefan

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 185 210 40 196617 gate~;
#P message 138 65 14 196617 1;
#P newex 138 36 45 196617 loadbang;
#P flonum 138 91 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 215 150 27 196617 *~;
#P flonum 263 34 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user scope~ 217 238 347 368 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P flonum 217 36 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 215 62 40 196617 train~;
#P newex 215 182 41 196617 phasor~;
#P user ezdac~ 117 151 161 184 0;
#P connect 2 0 10 0;
#P connect 2 0 6 0;
#P connect 1 0 10 1;
#P connect 10 0 4 0;
#P connect 5 0 2 1;
#P connect 7 0 6 1;
#P connect 3 0 2 0;
#P connect 6 0 1 0;
#P connect 9 0 7 0;
#P connect 8 0 9 0;
#P window clipboard copycount 11;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#112350
Sep 17, 2007 at 3:12pm

I’ve got that syncing feeling…

gate~ appears to make no difference and gives the same results as train~ -> *~ but thanks for looking stefan.

here’s a comparison with zigzag~ and cycle~ is in there as well -

is using train~ and zigzag~ as efficient cpu-wise and as accurate timing-wise as using train~ and phasor~/cycle~?

max v2;
#N vpatcher 256 143 1114 730;
#P origin 0 -62;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 597 295 41 9109513 phasor~;
#P newex 513 398 83 9109513 rampsmooth~ 100;
#P newex 517 361 27 9109513 *~;
#P user scope~ 522 462 652 592 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P newex 547 333 60 9109513 cycle~ ramp;
#P newex 620 352 89 9109513 buffer~ ramp 11.61;
#N vpatcher 399 352 582 580;
#P window setfont “Sans Serif” 9.;
#P newex 40 30 50 9109513 loadbang;
#N vpatcher 50 40 202 305;
#P window setfont “Sans Serif” 9.;
#P newex 22 59 38 9109513 / 512.;
#P outlet 22 208 15 0;
#P inlet 22 33 15 0;
#P connect 0 0 2 0;
#P connect 2 0 1 0;
#P pop;
#P newobj 80 120 55 9109513 p sawtooth;
#P newex 40 143 50 9109513 pack 0 0.;
#P newex 40 164 57 9109513 peek~ ramp;
#P newex 40 98 50 9109513 t i i;
#P newex 40 76 50 9109513 line 0 1;
#P message 40 56 63 9109513 0 , 512 512;
#P connect 6 0 0 0;
#P connect 0 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 4 0;
#P connect 4 0 3 0;
#P connect 2 1 5 0;
#P connect 5 0 4 1;
#P pop;
#P newobj 620 331 76 9109513 p generate-ramp;
#P newex 287 149 27 9109513 t b f;
#P newex 450 351 26 9109513 print;
#P newex 348 236 27 9109513 / 0.;
#P newex 323 391 83 9109513 rampsmooth~ 100;
#P message 243 59 26 9109513 100.;
#P message 210 55 26 9109513 200.;
#P message 169 53 31 9109513 1000.;
#P newex 327 354 27 9109513 *~;
#P newex 212 22 45 9109513 loadbang;
#P newex 353 275 27 9109513 *~;
#P user scope~ 332 455 462 585 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P newex 357 326 41 9109513 phasor~;
#P user ezdac~ 566 162 610 195 0;
#P newex 160 266 31 9109513 *~ -1.;
#P newex 157 141 27 9109513 t b f;
#P newex 158 175 27 9109513 / 0.;
#P user scope~ 177 453 307 583 256 3 128 -1. 1. 0 0. 0 0. 102 255 51 135 135 135 0;
#P outlet 122 440 15 0;
#P newex -2 235 45 9109513 loadbang;
#P newex 122 372 83 9109513 rampsmooth~ 100;
#P user number~ 351 115 390 130 9 139 3 1 0. 0. 0 1. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 64 266 56 9109513 loopmode 1;
#P flonum 125 115 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 288 113 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 122 341 27 9109513 *~;
#P newex 123 208 57 9109513 train~ 1000.;
#P message -2 268 39 9109513 mode 1;
#P message 169 238 58 9109513 0 0 1 $1 0 0;
#P newex 171 302 53 9109513 zigzag~;
#P comment 107 95 61 9109513 interval;
#P comment 177 96 100 9109513 grain length;
#P window linecount 2;
#P comment 289 81 45 9109513 buffer length;
#P window linecount 1;
#P comment 349 92 100 9109513 speed;
#P flonum 176 116 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P connect 15 0 7 0;
#P connect 15 0 12 0;
#P connect 8 0 9 0;
#P connect 9 0 14 0;
#P connect 14 0 16 0;
#P connect 11 0 8 0;
#P connect 27 0 11 0;
#P connect 5 0 9 1;
#P connect 18 0 8 1;
#P connect 11 0 19 0;
#P connect 0 0 18 0;
#P connect 19 0 18 0;
#P connect 8 0 20 0;
#P connect 25 0 27 0;
#P connect 10 0 6 0;
#P connect 12 0 5 0;
#P connect 7 0 5 0;
#P connect 6 0 5 0;
#P connect 20 0 5 0;
#P connect 19 1 18 1;
#P connect 28 0 0 0;
#P connect 14 0 17 0;
#P connect 25 0 28 0;
#P connect 13 0 5 1;
#P connect 25 0 29 0;
#P connect 10 0 33 0;
#P connect 29 0 10 0;
#P connect 26 0 30 0;
#P connect 8 0 26 0;
#P connect 30 0 23 0;
#P connect 22 0 26 1;
#P connect 33 0 31 0;
#P connect 11 0 31 0;
#P connect 8 0 24 0;
#P connect 24 0 22 0;
#P connect 33 1 31 1;
#P connect 31 0 24 1;
#P connect 31 0 32 0;
#P connect 38 0 39 0;
#P connect 8 0 38 0;
#P connect 39 0 37 0;
#P connect 36 0 38 1;
#P connect 24 0 40 0;
#P connect 40 0 36 1;
#P pop;

#112351
Sep 17, 2007 at 4:56pm

> But if I feed a signal into the phase input of a cycle with a saw, all I
> get is exactly that phase signal, then I don’t need a cycle~ at all…
>

it is not exaclty that phase signal, it is one which you can reset at any time wih a spike, sampleexact.

this is really the most straightforward way of playing from a wave~, i cant believe you dont use that yourself.

btw. you still owe me that alternative which you recently suggested – dont think i forgot that. :)

#112352
Sep 18, 2007 at 11:00am

#112353

You must be logged in to reply to this topic.