rapid pitching

Jul 26, 2011 at 3:14pm

rapid pitching

i made a quick sketch for sth thats gonna be emulating treating a sample mp3 like you´d do with hands on vinyl. scratcher more or less.

but there´s the obligatory clicking problem. as far as my knowledge goes most here use fade in/out, like i did. but its not perfect.

maybe give it a look, thank you.

– Pasted Max Patch, click to expand. –
#58196
Jul 26, 2011 at 3:19pm

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

#208992
Jul 26, 2011 at 3:45pm

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.

– Pasted Max Patch, click to expand. –
#208993
Jul 26, 2011 at 5:59pm

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

– Pasted Max Patch, click to expand. –
#208994
Jul 26, 2011 at 6:14pm

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…

– Pasted Max Patch, click to expand. –
#208995
Jul 26, 2011 at 8:13pm

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.

#208996
Jul 26, 2011 at 9:01pm

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

– Pasted Max Patch, click to expand. –
#208997
Jul 27, 2011 at 3:05am

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

#208998
Jul 27, 2011 at 3:24am

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

#208999
Jul 27, 2011 at 4:15am

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

#209000
Jul 27, 2011 at 4:23am

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

#209001
Jul 27, 2011 at 4:41am

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.

#209002
Jul 27, 2011 at 2:19pm

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.

#209003
Jul 27, 2011 at 2:46pm

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

Brendan

#209004
Jul 27, 2011 at 3:18pm

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.

#209005
Jul 27, 2011 at 3:45pm

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.

#209006
Jul 28, 2011 at 11:11am

@ 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

#209007

You must be logged in to reply to this topic.