You want to use line~ for your amplitude fading. Otherwise, you'll be making more clicks, since line doesn't interpolate at audio rate. (Even if you set the grain size very small, if your CPU usage climbs, control-rate messages don't receive the same priority, so you'll probably get clicks; line~ won't have this problem.)

the problem with [line~] is that its too slow on reacting short distances. i must choose smaller fade in/out to not cut away the audio, and finally have more clicks. the clicks come not by the fading itself, they come from a more initial sample access max does. just like there´s none of that invisible glue on it cause you wouldn´t need for most purposes.

but maybe load a file for yourself and compare line/line~ here.

looks to me your messages to line~ are formatted the wrong way. you send it "20, 0" and and "30, 0" what you are telling line~ to do in this case is: go to 20 immediately then jump to 0 (ie no ramp) and the same with the other message. Also you don't need to hook anything up to the right inlet of line~...

your message should probably look something like this: 0 20 and 1 30 and should go into the left inlet ONLY. this way line~ will go to 0 over 20 msec for the first message and go to 1 in 30 msec for the second one.

HTH

alternatively, you could also use the function object to run your line~. something like the patch below maybe? I haven't played with your patch, but it looks to me like that pack next to the current line~ is going to drive a play~. So every time you start playing a sound you need to know the length of that sound which then updates the length of the function. bang the function into a line~ and you should be good. The cool thing about function is that you can quickly and easily change the shape of your attack/decay visually...

Good suggestion re: function, MIB. One more thing regarding 20,0: you're not actually jumping from 20 to 0 instantly. Here's what's happening:

1. Set to 20 (scheduler tick -- this duration is set in the preferences under "Scheduler"; mine defaults to 1 ms, but it could be more depending on how much control data is getting passed around) 2. Set to 0

If you want to go from 20 to 0 over some very short interval, your message should look more like this: 20 0. 0. n where n is your interval (can be float, must be >=0.)

One recommendation as to function: be sure that it's set to list output mode, otherwise you're going to have the same timing issue as before. (because it will output as "first pair, everything else" by default instead of "all values at once") Never understood why that wasn't the default behavior of function, but I'm sure there's some old reason for it. This is a good place to use the prototype feature.

As a quick aside, line won't be faster than line~ because of the scheduler. Even if you could change the value of line five times a sample the only value you would hear would be the last one, so it would be no different.

Here's another way of doing without amplitude cross fading. I've added some code to simulate spinning down the platter.

@Peter McCulloch: purely worded on my part. of course things happen according to the scheduler... didn't wan't to complicate the matter to much when the messaging structure seemed to be the problem ;)

Figured as much, just wanted to clarify for the OP.

"looks to me your messages to line~ are formatted the wrong way. you send it "20, 0" and and "30, 0" what you are telling line~ to do in this case is: go to 20 immediately then jump to 0 (ie no ramp) "

no, there is a cycle in between which splits the input to the right and the left inlet of the [line~].

what it does in fact: set the ramptime to 20, then send the 0. on bang set ramptime 30, then send a 1. it takes 50 seconds going down to 0 and back to 1. otherwise i wouldn´t have mentioned the time problem of cutting away audio on higher fading times than 20/30.

@peter

thanks for the example, i´ll have to take a closer watch.

@xh9o: you are right. just have never seen it done that way. seems a bit complicated for what you intend. you introduce an extra object that's unnecessary... also, I think you meant to say 50 msec, right?

eh yeah sure, 50msec ;)

i had problems when sending a list like "0 20" and then "1 30". but looking at yours or peters patches and trying again i remembered line~ runs only with dsp set on. probably it was off when i did try it with the lists.

btw. the [function] idea is cool (for many purposes), i´m gonna play around with it.

Be sure to check out the setdomain and setrange messages for function: they allow you to stretch the envelope to fit new times and levels, and makes the object way more flexible.

Also, cool totally unrelated use for function: you can use it as a lookup table. (send in time values in the inlet, get out y values out the left outlet.) Very handy for remapping values.

+1 for this VERY cool use of [function]; for those of us scared of or n00bish with [expr] and [zl] (guilty).

Brendan

Be sure to check out vexpr, also. It's expr but for lists (and @scalarmode 1 is a big help!) and makes lots of things way easier. You can see plenty of uses in my tool awkwardly named: PM.MatrixVolumePan. It converts a matrix~ into a mixer including muting, solo, pan, volume, and trim.

don´t know vexpr yet, but expr is heaven sent. sometimes especially by the ability to integrate direct table access or put it into the sxformat argument list. makes it all so wonderful and easy.

@ peter: PM.MatrixVolumePan is nifty to have, thanks very much.

(just checked my 4 year old thread asking about the meaning of the soundfx-message to matrixctl, but in max5 this message is gone.) hans