I have a simple patch whereby a [phasor~]/[cos~] is acting as an LFO to modulate the frequency of a [cycle~]. When the LFO is turned on and off via a [gate~] it produces clicks. Can anybody recommend a way of eliminating this unwanted noise? I have been told the [line~] can help in doing this, but I am having difficulty understanding how it works - or how to implement it. I have included a patch which outlines what I am trying to achieve. 

how-to-use-line-or-an-envelope-object-to-reduce-clicks-when-using-switches

a click is just an abrupt change in voltage, all the program is doing for your sounds is spitting out numbers inbetween -1 and 1. when theres a change from something like 1, to -1, (say a sine wave is being input and its doing its little thing, oscillating inbetween 1 and -1 over the time period of each cycle (frequency)).

when you turn off the gate, it immediately stops the voltage from being output, so it goes from whatever value was last put in, to 0 instantaneously. that produces clicks, so if you visualize that, its easy to understand.

basically to remove a click, you just have to ramp the value down over something like 10-20 milliseconds and the human ear doesnt detect it.

so in simple terms, you need to maybe make an object that instead of immediately turning it off, it does a little ramp function based on the on/off states of the toggle that you have hooked to the gate.

a click is just an abrupt change in voltage, all the program is doing for your sounds is spitting out numbers inbetween -1 and 1. when theres a change from something like 1, to -1, (say a sine wave is being input and its doing its little thing, oscillating inbetween 1 and -1 over the time period of each cycle (frequency)).
when you turn off the gate, it immediately stops the voltage from being output, so it goes from whatever value was last put in, to 0 instantaneously. that produces clicks, so if you visualize that, its easy to understand.
basically to remove a click, you just have to ramp the value down over something like 10-20 milliseconds and the human ear doesnt detect it. 

so in simple terms, you need to maybe make an object that instead of immediately turning it off, it does a little ramp function based on the on/off states of the toggle that you have hooked to the gate.


i believe there is an object that is like selector~ and gate~, which ramps each port when changed, so if you have multiple ports on the gate or selector, it wont click, this object only works for single input gates.

(it might only be available in puredata though)

i believe there is an object that is like selector~ and gate~, which ramps each port when changed, so if you have multiple ports on the gate or selector, it wont click, this object only works for single input gates. 

(it might only be available in puredata though)


[matrix~] -- controllable with a graphical [matrixctrl], if you want. try presets too.

multiple inlets and outlets, with an optional argument for ramp time. So you can send it "ramp 50." for example, which makes all opening/closing/switching functions ramp over 50 milliseconds. perfect :)

[matrix~]  -- controllable with a graphical [matrixctrl], if you want. try presets too.

multiple inlets and outlets, with an optional argument for ramp time. So you can send it "ramp 50." for example, which makes all opening/closing/switching functions ramp over 50 milliseconds. perfect :)


ah yes, thats the object that handled it that way. thanks.

i go to help and i end up learning something again.

ah yes, thats the object that handled it that way. thanks.
i go to help and i end up learning something again.


for that patch, you'll want something like line~ or curve~. control line~ with the same toggle controlling gate~, but use line~'s output to control the amplitude coming out of cycle~(you're using a toggle which is an 'event' to trigger a 'signal' process... furthermore, you're gating 'phase'-control at the same time you want 'amplitude'-control(duck the amplitude at the exact moment that cycle~'s phase changes abruptly such as when you open and close gate~)).

in the 'windowing/enveloping' section of this tutorialpatch, there's more info. might help you, too:

https://cycling74.com/forums/rajas-lil-sampling-tutorial-for-maxmsp

for that patch, you'll want something like line~ or curve~. control line~ with the same toggle controlling gate~, but use line~'s output to control the amplitude coming out of cycle~(you're using a toggle which is an 'event' to trigger a 'signal' process... furthermore, you're gating 'phase'-control at the same time you want 'amplitude'-control(duck the amplitude at the exact moment that cycle~'s phase changes abruptly such as when you open and close gate~)).
in the 'windowing/enveloping' section of this tutorialpatch, there's more info. might help you, too:
https://cycling74.com/forums/rajas-lil-sampling-tutorial-for-maxmsp
;)


Thanks for all the help. I have experimented with a few different variations, including using a ramped [matrix~] as a switch, but am going to try and use the [line~]. I have incorporated it into my LFO. I am just having a little bit of trouble understanding the argument messages the [line~] is receiving - which are [sel 0 1], [1, 0 15] and [0, 1 15]. Could somebody help me?

EDIT: this question was answered by Peter McCullough earlier here:

https://cycling74.com/forums/help-getting-rid-of-clicks-when-using-phasor-as-control-signal-for-lfo

the phase becomes discontinuous when you open or close the gate for 2 reasons--

1. sudden change from no modulation to full modulation; fix: you need to ramp it

2. no information on what part of the phase cycle the modulated signal from cycle~ is at, so even if ramped from zero, there will still be discontinuity; fix: use a phasor to drive the base signal and explicitly add the modulator to that phase information

btw you don't need to use gate at all if you use line~ and mult~ (see subpatch)

EDIT: this question was answered by Peter McCullough earlier here:
https://cycling74.com/forums/help-getting-rid-of-clicks-when-using-phasor-as-control-signal-for-lfo

the phase becomes discontinuous when you open or close the gate for 2 reasons--
1. sudden change from no modulation to full modulation; fix: you need to ramp it
2. no information on what part of the phase cycle the modulated signal from cycle~ is at, so even if ramped from zero, there will still be discontinuity; fix: use a phasor to drive the base signal and explicitly add the modulator to that phase information

btw you don't need to use gate at all if you use line~ and mult~ (see subpatch)


DJF: the message sent in to line is actually 2 messages sent sequentially in once instance.

what i mean is that line needs an initial set value, then a destination value over what period of time.

so with the (1, 0 15) message, it sets the value to 1, then says (go to 0 over the time period of 15 milliseconds) which is what i said is around the range that is difficult for the human ear to detect.

and the other message is (0, 1 15) which means start at 0, go to 1 over 15 milliseconds.

the [sel 0 1] is there because the toggle when clicked outputs 1 of 2 numbers, when its turned on, it outputs a 1, when its turned off it outputs a 0, so the select object is there and it detects that. on the furthest left outlet, if there is a 0 input to the [sel] objects input, it

outputs a bang out that outlet which then outputs the message (1, 0 15) which ramps the value down. and vice-versa for the [sel 1] input.

you are aware that you can right-click all the objects and open the help patch that shows how to use it so you can get the gist of how it works right?

also you can even further click the *this object* reference link at the top of each help patch for further explanation (very useful because sometimes important things are left out of the help patches)

DJF: the message sent in to line is actually 2 messages sent sequentially in once instance.
what i mean is that line needs an initial set value, then a destination value over what period of time.
so with the (1, 0 15) message, it sets the value to 1, then says (go to 0 over the time period of 15 milliseconds) which is what i said is around the range that is difficult for the human ear to detect.
and the other message is (0, 1 15) which means start at 0, go to 1 over 15 milliseconds.
the [sel 0 1] is there because the toggle when clicked outputs 1 of 2 numbers, when its turned on, it outputs a 1, when its turned off it outputs a 0, so the select object is there and it detects that. on the furthest left outlet, if there is a 0 input to the [sel] objects input, it
outputs a bang out that outlet which then outputs the message (1, 0 15) which ramps the value down. and vice-versa for the [sel 1] input. 

you are aware that you can right-click all the objects and open the help patch that shows how to use it so you can get the gist of how it works right?
also you can even further click the *this object* reference link at the top of each help patch for further explanation (very useful because sometimes important things are left out of the help patches)


That is great, thanks for all the help. I have implimented the line object in the LFO part of my patch, but I was wondering if anyone could provide an answer as to why I still here occasional clicks in my patch? and why the LFO sometimes goes out of time. The patch I am working on is provided. I am using a sequencer as a modulation source for an LFO switch. I am only using one oscillator to control everything i.e. its cycles contribute to the sequencer's timing, as well as the LFO rate etc. 

Thanks, I have made some amendments to the patch I am working on - and have implemented suggestions from the forum. I now just need to work on reducing the audible clicks when changing LFO note values as well as those heard when pressing space bar to stop and start.

The reason I am using a custom GUI is just because I find the block colours more visually accessible - have a sight problem. Would be great if the live.graph and matrixctrl didn't pixelate when you enlarged them though - that would solve my problem straight away!

Thanks, I have made some amendments to the patch I am working on  - and have implemented suggestions from the forum. I now just need to work on reducing the audible clicks when changing LFO note values as well as those heard when pressing space bar to stop and start. 

The reason I am using a custom GUI is just because I find the block colours more visually accessible - have a sight problem. Would be great if the live.graph and matrixctrl didn't pixelate when you enlarged them though - that would solve my problem straight away!


Live.grid is pretty adjustable; spend some time with the controls and see if you can't find something that works, because you can definitely do big square blocks.

You're getting clicks with your matrix~s because you're sending the ramp 50 message into matrixctl, not matrix~.

You don't need matrixctl to work with matrix~, and I personally recommend not using it. If you want to use matrix~ as a mixer, check out the PM.MatrixVolumePan abstraction in my toolbox. It does muting, panning, etc.

You're getting clicks with your matrix~s because you're sending the ramp 50 message into matrixctl, not matrix~.  

You don't need matrixctl to work with matrix~, and I personally recommend not using it.  If you want to use matrix~ as a mixer, check out the PM.MatrixVolumePan abstraction in my toolbox.  It does muting, panning, etc.


How to use [line~] or an envelope object to reduce clicks when using switches