christripledot

i know it's been done to death, but... c'mon...

feature-request-play-with-windowed-sinc-interpolation

Sorry, I know it's poor form. It's too late to edit my original post and I'd like to apologise to the devs for the tone of my request.

My remark was meant to be a bit tongue-in-cheek, but I feel the point is still valid. There are a great many DAWs out there that have 'better than cubic' realtime resampling interpolation. I feel that we Maxers are missing out here.

Volker Boehm's [resample~] external sounds great, but it doesn't allow for sample-accurate triggering, and it crashes on me fairly regularly.

I'm very happy to accept that Max has certain limitations, and I'm very willing to put in the time and effort to work around some of them. I'm not averse to writing my own externals - here's an example:

I'd like to be able to trigger a sample at audio rate, and move the loop points around while it plays. I could do this with [count~] or [+=~] indexing [play~], using a [%~] to change the loop length. But this just results in the current playback position jumping around. In order to reset the counter I need a feedback loop, and therefore a vector's worth of delay, thus ruining the sample-accuracy.

So I'm ironing out the last few bugs in my own external, a bit like [+=~], that can count forwards or backwards, and offers forwards/backwards/pingpong looping. I'm using this to index [play~], and it's working quite well. But I'm still frustrated by [play~]'s sound quality, and I simply don't have enough knowledge/understanding/experience/braincells to write my own sinc interpolator.

I've seen quite a bit of discussion about the lack of a decent-sounding sample player. Given that the Max devs are DSP wizards, and that we are paying customers whose feedback is encouraged, I'd like to think that this sort of advanced programming is the job of the developers, not the users.

If there are other users out there who'd like to see better-quality interpolation in the sample-playing objects ([play~] in particular), please make yourselves heard. I hope it's not just me who finds this a problem.

Thanks for giving this post your time. I don't mean to sound rude or demanding, it's just that I've bought into what is, after all, a cutting-edge audio package, and I think it ought to be able to compete with the rest of the industry in terms of sound quality.

Although it may not necessarily need to be a new interpolation. See this thread: 

https://cycling74.com/forums/play-distorted-sounds

 where Alex Harker suggests that play~ uses a single precision internal drive, and if this was changed to double precision, the artifacts of play~ would decrease significantly.

Although it may not necessarily need to be a new interpolation.  See this thread: https://cycling74.com/forums/play-distorted-sounds where Alex Harker suggests that play~ uses a single precision internal drive, and if this was changed to double precision, the artifacts of play~ would decrease significantly.


But doesn't [groove~] use a 64-bit internal counter? It still sounds like crap if you pitch a sample around a lot. My external uses a double-precision counter, and I've tried it with [hr.play~], but that isn't much better. Having a 64-bit counter lets you keep sample-accuracy for longer than the fabled 3 minutes, but it doesn't really help with interpolation artifacts.

So, C74, could you find it in your hearts to help us here? Is it likely that we might see something like this in the future?

1 - accuracy of the drive signal - the 32 bit float used to drive play~ just isn't accurate enough. IMHO that is the top reason that play~ will sound bad. (It's not the internal drive that is the problem - it's that the drive is external and hence limited to 32 bit).

2 - sinc interpolation using a viable number of points for real-time (to my ears) does not always sound better low playback speeds - I've observed strange artefacts in this scenario,, both with volker's object and my own (which actually does the sinc interpolation "in-house" - I believe volker's uses someone else's library). I'll maybe look into this again though.

3 - Windowed sinc allows you to anti-alias which is a definite improvement for faster playback speeds, although it depends on your material and the speed how noticeable it will be - muted trumpet makes it pretty obvious - electric guitar not so much (because the HF content is much lower, so less to alias). The trade-off is the cost, which (in my code at least - and not because I can't code efficient DSP) is quite a lot worse than with cubic interpolation. The cost also increases (at least using the techniques I'm familiar with) as playback speed increases.

4 - if you are concerned merely with quality (rather than anti-aliasing) it might be cheaper CPU-wise to think about higher orders of polynomial interpolation.

5 - Basic varispeed limitations. Varispeed is never going to sound great for all playback speeds / material - generally transposing stuff around always has potential problems. Personally, I don't see an issue with groove~ or hr.play~ for most purposes. However, if you can demonstrate (with audio examples) the difference in quality between methods for a given scenario it might move this recurring debate along, and also better locate what you want (ie. simply higher quality, or an anti-aliasing playback object).

My own external was written for a specific purpose and as yet is not at release level (limited functionality compared what you would need for general release and some odd behaviour last time I looked at it that needs ironing out). I can't currently revisit it for several months, but it is in the pipeline for some point in the future.

If you are capable of writing your own externals, why not download the source for resample~ and either report the bugs (volker is very good at looking at things if you ask him), or fix them yourself, or adapt it to work the way you want?

I'm not saying I wouldn't appreciate a native standard object, just that there might be quicker ways to get what you want. Also, for context, I've spent quite a lot of time looking at buffer playback and written custom playback objects (for other reasons) that use cubic interpolation as well as the aforementioned windowed-sinc approach.

Some thoughts... (and I'm not trying to be difficult!) :D

1. I'm driving [hr.play~] with two 32-bit floats from 2 outlets of my extern (one for the MSB and one for the LSB), so this is a moot point.

2. I take your point on this. Not knowing enough about the gory details of this stuff, I'm bandying the term "sinc" around because it's become (perhaps wrongly) synonymous with "god quality".

3. I don't care if it eats my CPU. If C74 introduced another option in the interpolation enum called "superbadman quality interp" then it would be there for those who want it/whose CPU can take it.

4. Re: sound quality - my setup is in a state of disarray at the moment so I'd find it hard to produce test recordings for the forum right now. But all it takes is for you to open "resample~.maxhelp" and compare [resample~] and [groove~] at low speeds to hear a mahoosive difference.

5. While I'm capable of writing my own externals, my understanding of DSP is extremely limited. The example I gave is nothing more than a counter - nothing magic happening in the code except some 'if's, 'else's, and 'add's. The prospect of polynomial interpolation gives me the heeby-jeebies.

I have tried to read up on this stuff, believe me, but with a day job, a pretty poor understanding of linear algebra, and total panic at the thought of imaginary numbers, this sort of thing is beyond me right now.

All I'm saying is that I think there is a demand for nicer-sounding native objects. I don't think it's too presumptious to say that the developers are very capable of implementing this without too much trouble. Unfortunately they seem to have made making money from the Ableton market a higher priority than bringing the existing MSP objects up to scratch with other competing software. But I'm not saying that good business sense has no place in a capitalist economy! I'd just like it if Max sounded as good as its contemporaries, and I don't think it's too much to ask.

2. My point is also that as well as being more CPU efficient - high order polynomials are probably easier to implement.

4. - You are more concerned with better quality at low speeds then? I'll check it out again.

5. - Sure - it's a bit tough to get a playback external right.

I think a decent windowed sinc playback object is a large enough job to get to release level for any developer (at c74 or not). Also, most of the software you seem to be calling 'competing' does a totally different thing (MaxMSP is not a DAW) so it's not really competing at all. FWIW a DAW (at least the one I use) is able to make all kinds of efficiency savings because it pre-buffers and calculates audio - hence although it may feel 'real-time' - it is actually not, and only certain parts of the code run in real-time - often in much bigger blocks. Playback is also core functionality.

Out of interest are you more concerned with playback at a given speed, or altering the speed in real-time also, or both?

Well, you're right about the DAW thing. I'm not trying to define Max as a DAW per se, but I've chosen to make it the heart of my performance rig. When I play a set, I need to be able to trigger and edit drum patterns (which may contain samples). Audio-rate triggering is a must for me because I do a lot of overdub-looping and the like.

Tight, reliable sample triggering shouldn't demand a complete DAW. But many DAWs, including Cubase, Logic, Renoise (if you can call that a DAW), Reaper, FL Studio, etc. can playback patterns of samples and sound much cleaner at a variety of pitches. I choose Max because of its unique data-routing abilities that let me mangle my patterns in interesting ways.

Ideally I'd like to be able to play samples at slow speeds without that nasty high-frequency ringing, and at high(er) speeds without aliasing horribly.

If anti-aliasing a playback object is a big problem, then it would be nice to at least have a dedicated anti-aliasing filter in the distro. Many people have called for this so that they can oversample effectively using [poly~]. Without a reliable method of AA, there seems to me to be little point in oversampling.

Sorry, I should have mentioned that vari-speed is a must for me.

BTW, Volker's external may have some weird artefacts, but it's decent enough to my ears.

I've looked at the source and I reckon I could mod it to trigger at audio-rate, but I wouldn't know where to start if I was trying to make it sample-indexable like [play~].

If you have any pointers (pun not intended) then I'd be honoured to have a go, but you'd probably all just laugh at my code. I'd ask Volker, but I don't have enough confidence in my skills.

OK - right. I've done some listening. With resample I get a high tone at some points with very low speeds. Other than that it definitely sounds better at all speeds.

For a start resample should be freeing dsp before freeing resources in the free routine - that's why it seems to be currently crashing when the object is deleted with audio on.

Looking at the code the pos variable seems to hold the current sample position in samples (as a long), so you might want to start by looking there...

OK - right. I've done some listening. With resample I get a high tone at some points with very low speeds. Other than that it definitely sounds better at all speeds. 

We agree there are several areas where audio quality can be improved in MSP, and we are hard at work on this issue for our next major release. We'll provide more information on our plans in the near future.

Tim, thank you so much for posting! I've seen a lot of posts which follow this pattern:

1. user posts his/her concerns or feature requests

2. other users tell first user that he/she is wrong to want an improvement

I really appreciate knowing that it's something the C74 team are looking at! Again, I'll reiterate: I don't wish to sound ungrateful to you guys.

Massive thanks to you too Alex, I thought I'd killed the thread with pessimism! Great tip about the [resample~] crash, I've managed to sort that!

I've been meddling with the 'pos' variable a bit but I think the libresample library expects to receive a contiguous block of samples to work with. The best I've managed is to set 'pos' to 0.0 when it receives a sample click, which is a start. For now I guess I'll stick with [hr.play~] for advanced sample-mashing, and use a modded [resample~] for one-shots where pitch really matters (hi-hats etc.)

Maybe I should start a separate thread or contact Volker about this, but I'm loathe to pester him about an object he hasn't even put on his beta downloads page. But this is as good a place as any... Even with the stock [resample~] object, I get horrible audible clicks whenever I start/stop a sample. These don't seem to be the usual clicks caused by suddenly jumping from one sample value to another; I think there's something ugly going on with the libresample internal buffer. If you want to spend some time on it I can send you what I've got, else I'll keep plugging away and post if I get anywhere.

1. user posts his/her concerns or feature requests
2. other users tell first user that he/she is wrong to want an improvement
3. thread dies with no developer input

2 - For the record I wasn't saying you were wrong to ask or want improvement - of course you have the same right as anyone to ask for improvements and I'll be very happy to see them when they arrive! Just thinking about what might realistically happen in the shorter term. Also the topic happens to be of interest to me technically....

3 - As I understand it, resample is already varispeed per sample, so if you think in terms of speed rather than direct position then you should be able to get at least forward varispeed without much trouble - I don't know if the library can do reverse, and you could probably hack it (much as volker internally buffers multichannel files - but buffering backwards for reverse speeds as the sinc kernel is symmetric) but it might be a pain to do and get right.

4. I'm not seeing (hearing) the clicks you mention here - any chance of some test files (audio and patch) to confirm this?

Thanks Alex. For the record, I wasn't being defensive (sorry if it came out that way). :D

Regarding test files, I'll try for tomorrow, but I'm at work right now and haven't got internet access at home yet (just moved house)...

Try with an audio sample with a bit of perfect silence at the beginning. The clicks will get lost if you're using a short percussive sound with no delay at the beginning.

[feature request] play~ with windowed sinc interpolation