rapid pitching

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.