dondelion

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-to-trigger-phasor

Quote: dondelion wrote on Wed, 12 September 2007 06:59

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

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

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)


nope...i still don't get it! more clues needed...

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

> nope...i still don't get it! more clues needed...

similar to [line~], but can be triggered by a signal (mode 1), and 

afaik, depending on sigvs it's not 100% accurate, so i wouln't use it 

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


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

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.

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 

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.

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.

I'll try zigzag~ when I get home and post a patch demonstrating what I mean...

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. 

You might want to check out Nathan Wollek's granular toolkit; perhaps 

the train.shift~ or phasor.shift~ objects might do what you need?

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

> 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 

"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 

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

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

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

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

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!

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?

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?

Actually the method I'm proposing is better suited for wave~ not play~...

> 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 

And I also don't get why Roman would put a sawtooth into cycle~ instead 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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

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.

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. 

>> And I also don't get why Roman would put a sawtooth into cycle~

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

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

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

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

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

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~?

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

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

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


train~ to trigger phasor~