Forums > MaxMSP

Interpolation in groove~, play~, index~ and wave~.

February 17, 2009 | 5:16 am

Hi everyone,

I’ve only found interpolation described for the wave~ and index~ objects, and only in detail for the former. Do groove~ and play~ interpolate? Do they offer different modes for doing so?

I’m particularly confused about play~, which on the one hand can take a signal input for the lookup position, but on the other hand claims to expect an integer. It seems to me that either it discards the fractional part of the signal input, or it must be interpolating, but neither possibility is mentioned.

I’m pretty sure wave~ is the one I want; unlike play~, it seems to interpolate, and unlike groove~ it offers direct control of the position being read from the buffer~. Have I got that right? Are there any other arguments for or against using any of these that I ought to be aware of?

Thanks,
Jeff


February 17, 2009 | 8:44 am

I think you are right in your analysis.

Maybe it’s worth noting that groove~ has interpolation at looppoints.
And… that the interpolation of wave~ doesn’t work well with long files (the artifacts will become stronger when playing a part located in the end of a long file)

Im am also puzzled with the integer input of play~


February 17, 2009 | 9:08 am

As to wave~’s interpolation of long files, check the hi-res package that JKC made. It’s a lot of milquetoast MSP objects recoded to work with 64bit numbers (by passing two msp streams around). Works well, just don’t try to put them in a multithreaded poly~ instance.


February 17, 2009 | 10:49 am

groove~ and wave~ have interpolation(at loop points only), you need an additional amp-window to smooth out play-position interrupts beyond loop-points.

(index~ has no interpolation(you may have written/read that wrong))

difference between play~ and wave~ is that wave~ handles its playback positioning similar to wave-tables that are read through by changing phase from 0 to 1, while play~ handles its playback positioning in milliseconds(floating-point-signal).

i know play~ says it takes [int] messages, not sure what for, but you can send a signal value representing milliseconds and because it is floating-point precision, you can get sample-accurate(in terms of play-position).

JKC hires objects are definitely sweet as well. best of luck!


February 17, 2009 | 11:04 am

Quote: RabidRaja wrote on Tue, 17 February 2009 11:49
—————————————————-
> groove~ and wave~ have interpolation(at loop points only), you need an additional amp-window to smooth out play-position interrupts beyond loop-points.
>

- wave~’s interpolation is not at the looppoints but during playback (try the interpolation modes at low playback speed of a longer sample)
- groove~’s loopinterp interpolation is at looppoints, however, after comparing groove~’s output with wave~’s I suspect this object to interpolate during playback as well.


February 17, 2009 | 11:07 am

this thread confirms groove’s interpolation during playback:

http://www.cycling74.com/forums/index.php?t=msg&goto=155228&rid=3976


February 17, 2009 | 11:09 am

Quote: RabidRaja wrote on Tue, 17 February 2009 03:49
—————————————————-
> groove~ and wave~ have interpolation(at loop points only)

In fact all the above objects except index~ interpolate in order to produce their output. This is to do with how they generate samples when they need to read a value between two samples, rather than what happens when they loop – the two issues being different from one another.

groove~ *also* has a facility to interpolate at loop points.

wave~ offers either no interpolation, or linear interpolation. groove~ and play~ both use cubic interpolation – so they will sound noticeably better in some cases.

It really depends what you are trying to do. If you need to control the position in the buffer manually play~/wave~ (or index~ if you don’t want interpolation) will be needed. If you don’t groove~ is my preferred option for sample playback type tasks, because the internal drive mechanism is more accurate, and will stay accurate for longer samples. The hr objects from jkc seek to reduce this problem but offer similar functionality.

For cubic interpolation vs. linear. Cubic is a better model for sound, so normally sounds better, but it depends on the speed and order of access. For a straightforward playback or looping operation the difference will be most noticeably as the playback speed decreases. It is not that difficult at all to tell the difference between the two on sounds played at 1/4 speed or below

As for the integer input to play~ – The reference page for play~ seems to be incorrect – look at the helpfile – the comments about integers on the ref page seem to refer to messages to the line~ object in order to drive play, and could in fact also be float values.

Regards,

Alex


February 17, 2009 | 11:15 pm

good stuff to find out, i always avoided the loopinterp message to groove~ and i think i just assumed that was the same interpolation across the board. thanks for clearing it up every1.


February 23, 2009 | 5:50 pm
MuShoo wrote on Tue, 17 February 2009 10:08
As to wave~’s interpolation of long files, check the hi-res package that JKC made. It’s a lot of milquetoast MSP objects recoded to work with 64bit numbers (by passing two msp streams around). Works well, just don’t try to put them in a multithreaded poly~ instance.

I uploaded new versions of Joshua’s object which should fix the problem. At the usual location.


February 23, 2009 | 6:01 pm
Emmanuel Jourdan wrote on Mon, 23 February 2009 10:50
MuShoo wrote on Tue, 17 February 2009 10:08
As to wave~’s interpolation of long files, check the hi-res package that JKC made. It’s a lot of milquetoast MSP objects recoded to work with 64bit numbers (by passing two msp streams around). Works well, just don’t try to put them in a multithreaded poly~ instance.

I uploaded new versions of Joshua’s object which should fix the problem. At the usual location.

YEEESSSSSSSSSS. Very Happy I will try these out later today! Thanks so much! This solves many problems for me. :DDDD


Viewing 10 posts - 1 through 10 (of 10 total)