I haven't embarrassed myself on this list in a while. So here I am with another dumb question. My usual disclaimer:

1. I know it is in the docs. Everything is always in the docs. but I usually ask a question is because i don't understand the docs or the ref page. I am a moron. I need everything to be super explicit and clear so explain it to me like i am a 9 year old.

I don't quite understand how you specify a trapezoid. You specify 2 things: a ramp up and ramp down time. I am guessing these are as percentages of the overall duration? But the confusion comes in because every trapezoid I have ever seen has three segments. (here i am using a trapezoid env just to de-click):

1. rise.... how fast to go from 0-> 1 (or whatever your max value is).

2. usually some long stretch *at* the max value (1->1)

In many music11 type languages you have some kind of lineseg you can use where you specify a trapezoid de-click envelope to have a fast rise time, stay at full amplitude for as much of the sample as possible (the whole duration minus whatever rise and fall time there is) and then quick zip down to zero like:

/......................................................

So it is unclear how the 2 arguments specify the three segments since there are several ways that this could be done.

It looks like trapezoid wants you to specify the arguments as

1. percentage of the total duration to use as rise time.

2. percentage the env stays at the max value.

and then it just uses whatever is remained for the decay time?

But the defaults (.1 & .9) confuse as .1 would be to use 10% of the overall duration as a rise time leaving 90% left over for the steady state but then what about the decay time. Well that is already 100%. What does it use for the decay time? and if the steady part and the decay are supposed to be included in that second arg (the 90%) how does it know how much to use for each portion?

I just want a trapezoid env that has a super fast rise, stays at full blast as long as possible and has a super quick decay time just to use as a general de-clicker. I don't get why .1 and .9 works.

Just with that how does it now how fast the decay slope should be? If it just assumes that the slope up is the same as the slope down then .1 and .8 is necessary so that .1 is left over for the decay.

Alternately, I would imagine .05 and .9 to be correct as .05+.9+.05 is =1. and some remaindered percentage is necessary for the decay, no?

1. rise.... how fast to go from 0-> 1 (or whatever your max value is).
2. usually some long stretch *at* the max value (1->1)
3. the decay time.... (1->0)

 ____________________________
/......................................................

trapezoid-confusion

The trapezoid~ object expects to receive a signal from 0 to 1. A common source of input might be a phasor~ object, or the sync output of a groove~ object. The value of the incoming signal from 0 to 1 determines what trapezoid~ will output. There are 4 important "attributes" of trapezoid~:

'up' -- specified as an argument or in the second inlet, 0.1 by default

'down' -- specified as an argument or in the third inlet, 0.9 by default

When the incoming signal is somewhere between 'up' and 'down', the output value of trapezoid~ = hi

When the incoming signal is from 0 to up, the output is mapped commensurately on a ramp up from lo to hi

When the incoming signal is from down to 1, the output is mapped commensurately on a ramp down from hi to lo

So if the input signal moves steadily from 0 to 1 in T amount of time, it will cause trapezoid~ to ramp up from lo to hi in up*T amount of time, then stay at hi for (down-up)*T amount of time, then ramp down from hi to lo in down*T amount of time.

The trapezoid~ object expects to receive a signal from 0 to 1. A common source of input might be a phasor~ object, or the sync output of a groove~ object. The value of the incoming signal from 0 to 1 determines what trapezoid~ will output. There are 4 important "attributes" of trapezoid~:
'lo' -- the minimum output of trapezoid~
'hi' -- the maximum output of trapezoid~
'up' -- specified as an argument or in the second inlet, 0.1 by default
'down' -- specified as an argument or in the third inlet, 0.9 by default
When the incoming signal is somewhere between 'up' and 'down', the output value of trapezoid~ = hi
When the incoming signal is from 0 to up, the output is mapped commensurately on a ramp up from lo to hi
When the incoming signal is from down to 1, the output is mapped commensurately on a ramp down from hi to lo

nice explanation. I finally get it as well. thanks a lot!

......if you want the truth, go to the source, ie C.Dobrian

Having spent many an hour with C. Dobrain's docs and observed him teach several times first hand I can tell you that he is about as gifted an educator as we have in this field.

So I am certain that this is not his fault, but I am still not clear on how it works.

I am going to have to meditate on the response above and mess with the scope and see if i can grok tapeziod's behavior. Just too many years making trapezoids in music11 (cmix/csound) with linseg to break this block in my head.

Meanwhile can I just ask, for the output of groove, for short rhythmic samples, how steep a trapezoid can you get away with?

Do must folks just use [trapezoid~ .1 .9] or can you go steeper? [trapezoid~ .05 .95] ? It is hard to tell with the scope at what point your 'ziod gets so fat that it no longer dips all the way down to 0. and you end up with a square block with a hatchet notch in it.

The help patcher has [trapezoid~ .1 .9] but if you turn it on it isn't doing [trapezoid~ .1 .9] in the scope. It is more or less doing a sawtooth till you manually enter .1 and .9 in the up and down boxes. I thought that having the default args in the [trapezoid~ ] object would insure that it started @ [trapezoid~ .1 .9] (leaving behind the fact that [trapezoid~ ] is already seemingly set to .1 .9 as a default) why is this so?

Do must folks just use [trapezoid~ .1  .9] or can you go steeper? [trapezoid~ .05  .95] ? It is hard to tell with the scope at what point your 'ziod gets so fat that it no longer dips all the way down to 0. and you end up with a square block with a hatchet notch in it.

The help patcher has [trapezoid~ .1  .9] but if you turn it on it isn't doing [trapezoid~ .1  .9] in the scope. It is more or less doing a sawtooth till you manually enter .1 and .9 in the up and down boxes. I thought that having the default args in the [trapezoid~ ] object would insure that it started @ [trapezoid~ .1  .9] (leaving behind the fact that [trapezoid~ ] is already seemingly set to .1  .9 as a default) why is this so?

You might be able to go steeper, depends on the source material. Just one of those things that you have to experiment with.

Regarding the help patcher, it is a little deceptive. What is happening is that there are number~ objects sending signals to the inlets of trapezoid~, thus negating the typed in arguments.

You might be able to go steeper, depends on the source material.  Just one of those things that you have to experiment with.

Regarding the help patcher, it is a little deceptive.  What is happening is that there are number~ objects sending signals to the inlets of trapezoid~, thus negating the typed in arguments.

I find that I understand such formulaic things better when I plug real numbers in as a thought experiment. For example, if the input signal goes in a straight ramp from 0 to 1 in 1 second, the trapezoid~ will ramp up in 0.1 sec (100 ms), stay at 1 (or whatever "hi" is) for 0.8 sec (800 ms), then ramp down to 0 (or whatever "lo" is) in 0.1 sec (100 ms). It would be equivalent to sending this message to line~: 1 100 1 800 0 100

Now let's take the whole thing down by a factor of 10, imagining that we're using trapezoid~ to create 100-ms notes, so now your ramp-up time would be only 10 ms. That's a quick ramp, which might even sound percussive on a fairly pure sound, but it's not so rapid as to cause a real click.

Now let's imagine we're trying to make a 10-ms grain. That's a ramp-up time of 1 ms, i.e. about 44 samples, which is still different from no ramp at all. Sure, it will sound like a click, because anything that goes from 0 to 1 in 1 ms (and/or that you only hear for 10 ms) will probably sound like some kind of click, but the rms power and the timbral effect are different for different kinds of windows. Try comparing it to a triangular window or a straight rectangular window.

trapezoid confusion~