Strange problem with poly~, adsr~ and note timing
After banging my head against this for a couple of weeks, I'm hoping someone can make me an xmas present of figuring out what's wrong here!
I'll add a simplified version of the patches below.
Basically, I'm trying to replace an existing (working) multisampler with one using the new groove~ object (so that when I have it in _single sample mode, I can get better sounding transposition). I'm also replacing the 3PO imultibuffer/ibuffer combination with the builtin polybuffer~ . (I may have to go back on that if the problem turns out to be that buffer~ is switching between buffers too slowly)
The problem is most easily noticeable with an external midi keyboard (down to playing style i guess - it's hard to play kslider like a real keyboard!) and it goes like this -
if I play a (say) 3 note riff very quickly, when a new note starts, I hear a bit of the previous note first. So instead of a clean new note "dummmm", I get a bit of the old note which then switches "da-dummm".
It doesn't do it all the time, and it seems to get worse if you keep repeating the rapid note pattern.
To _really hear this you need a folder of multisamples, but I've set the patch up to access the default samples folder inside Max7 as a starting point. The problem is somewhat less noticeable, but if you figure out the keys that have the cello,sho & vibes on them, and play them rapidly, you should hear what I'm hearing. If you don't, you're probably a better keyboard player than me and are playing too cleanly!
In my attempts to see what's going on, it looks as though after playing note 1, note 2 is sometimes arriving at the same instance in poly~ (as note 1) rather than being routed to the next instance, so maybe there's an underlying problem with poly!? Or it might be something to do with adsr~ not getting back to zero before the instance is muted. or something else entirely.
The two patches are:
test.voice (the subpatch inside poly~) and
test.multisamp (the main patch)
This is with the latest version of Max7 (in fact I just deleted prefs and reinstalled), and the latest OSX 10, on a Macbook Retina.
Thanks in advance for any help!
Subpatch:
Main Patch:
Have you tried removing the signal input to thispoly~?
Just tried that. It actually made the "error" more consistent! Every new note now starts with the previous sample and then jumps to the new one.
curious though - why did you suggest that?
Hi David,
I've added a 'key upper' subpatch to the poly. It sends a bang to a 'stop' message upon key release and is delayed according to the adsr release time.
It might not work 100%, particularly if you play a really wild flurry of notes in a short space of time (thus confusing the voice allocation). Yet you might detect an improvement for your required playing style.
I also added and an @loop for groove, purely for testing so I could hold down a number of keys for longer.
I've also increased the number of available voices to 16 in the main patch. Perhaps try it with different numbers of voices. I tested it with 8 and got good results where I could keep track of what was happening with each sample.
Best of luck with it.
Subpatch:
Main Patch:
Thanks for that SID,
Unfortunately, the problem persists. I'm (hopefully) attaching a Project folder containing the patch, subpatch, some simple sounds anda seq test file. (The main patch is annotated). Hopefully this will make clear what I'm hearing. You might have to run the seq repeatedly, as the results are inconsistent!
Hi David,
I was just having another tinker with this (having a working polybuffer~ implementation like yours is of interest to me), have you tried removing the @timestretch 1 @mode monophonic @quality good attributes from your groove object?
I wasn't getting any 'mis-fires' when I removed them. Sure, you'll want time-stretching for your pitches down the track, but that can be implemented 'outside' of the groove object.
Sid.
Hi SID,
I did try that, but it didn't fix it. You're right about there being a non-groove way to do it - my currently working version uses ibuffermulti~ and ibufferplayer~, and that works fine. I wanted to use the new groove~ to take advantage of the pitch shifting when the player is in single sample mode. I suppose I could have two separate poly~s for single and multi sample modes, and turn the polys on and of as required, but it would be neater to keep everything with standard objects for a change!
The whole thing has become even more bizarre. If I triger notes inside the patch using bang or metro, the glitch goes away. It's only when I use an external midi device that it goes wrong. I'm completely flummoxed. I'm going to post some example patches soon, but I'm running workshops this week, so it might have to wait till next week.
By the way,Thanks for the input.
Just an idea: Try setting adsr @retrigger 0.01.
If that doesn't help already, then delay the rest of the muting by another 5 ms.
It's a shot into the blue really, but i recently had a problem with drum things, that started to trigger way to late as soon as i replaced line/curve objects with adsrs. setting the retrigger attribute to a very small value solved this.
Good luck-.
Hey All,
I know this is an old threat, but have you found a solution? I am running into the same problem. Could it be that there is still some audio saved in the vector size of Max? I did some experiments with setting the groove~ in my poly with an empty buffer, but it didn't change the 'da-dum' effect, the first few ms are still from the previous sound.
I am not working with adsr, instead I use curve~ So here is not a solution to be found...
@SID, is there a way to do timestretching outside of a groove~ but still in realtime?
Many thanks