- Finally a real web forum for Max/MSP! Very nice. Joining a mailing list never was an option for me, and trying to find answers for my problems in the mail archives was kind of... discouraging, to say the least.

So, anyway, here's a question I'd appreciate some help with. I'm doing something as awkward as making a sampler and a synth in Max/MSP (...those of you who also have experiences with Reaktor will know what I mean by "awkward"...). Among the most serious problems is the poly~ object not doing voice stealing very well - it does not steal from the oldest note. So I made my own voice allocation system, which works exactly the way I want it to.

That is, as long as the cpu load is less than 50%. If it's higher, I get serious timing problems. The note events get way too slow, and - even though I've forced note-on events to be sent after pitch events into the poly~ instances - the voice instance is very likely to start sounding long before it catches the right pitch, especially at very high cpu loads.

Is there a known solution to this? Either - make MSP's poly~ steal mode behave properly, or some clever external which does the job with reliable timing? Or a way to force event priority for a specific part of a patch to the highest level? I mean, as high as audio processing - in this situation there's no need for reliable audio if you can't have reliable voice allocation. I know about the defer and deferlow objects, but they don't seem to be appropriate - Max is supposed to prioritize MIDI events anyway. It seems the heavy audio processing is messing with the MIDI timing, and that's not the way it should be.

BTW, is there any way at all to get reliable event timing? (...Yes, overdrie is on.) Trying to generate events off an audio object didn't get me any closer to it. I'm not at all sure the timing would be better if I used poly~'s own voice allocation, because the metro object is supposed to belong to the same prioritized category as MIDI events, and I've heard what a little cpu sweat does to the metro timing...

Any input appreciated - thanks in advance,

Is there a known solution to this? Either - make MSP's poly~ steal mode behave properly, or some clever external which does the job with reliable timing? Or a way to force event priority for a specific part of a patch to the highest level? I mean, as high as audio processing - in this situation there's no need for reliable audio if you can't have reliable voice allocation. I know about the defer and deferlow objects, but they don't seem to be appropriate - Max is supposed to prioritize MIDI events anyway. It seems the heavy audio processing is messing with the MIDI timing, and that's not the way it should be. 

event-timing-or-voice-allocatoin

> Among the most serious problems is the poly~ object not doing voice stealing >very well - it does not steal from the oldest note. So I made my own voice >allocation system, which works exactly the way I want it to.

http://www.synthesisters.com/hypermail/max-msp/Oct04/16441.h

 http://www.synthesisters.com/hypermail/max-msp/Oct04/16441.h tml

https://cycling74.com/forums/index.php?t=msg&goto=384

 https://cycling74.com/forums/index.php?t=msg&goto=384 78#msg_38478


I'm sorry I wasn't specific enough - I got so exited by the new forum I went on to post my question before I really recapitulated the problem. It's been some months since I worked on it, and I just recently started again.

Poly~'s voice stealing is ok for held notes, but the sustain period does not have a proper priority layout. Check out the attached modified adsr~ help patch. Try playing five notes in a low octave, release them, then play single notes one after another in a high octave. The low octave notes will hang on, while the newer high octave ones will cut as new occurs. This is not acceptable behaviour from a voice allocator.

Further testing also revealed what I suspected about the midi timing - under a little cpu stress (around 50%) it wasn't much better with poly~'s own voice allocator than with my own. So I'd still very much appreciate suggestions as to how to prioritize parts of the event processing, if possible; or any other solution that might help the situation.

...Am I doing something wrong? I can't see the attachment (zip file) I tried to attach. Trying again (sorry).

...Starting to realize it's not just to be hip that people post their patches as text files here. So here we go, only the stripped down polysynth example here:

Cool - thanks for the patch! This voice stealing bug will be fixed in a future release of MaxMSP, coming soon to a web browser near you.

In the meantime, I'll have to use my own system. Still, the event timing issue concerns me. Of course I don't know much about the inner workings of the Max application anatomy, but I would much rather prefer solid event timing (for example with the supposedly prioritized metro object) at the cost of higher cpu usage, than the situation now, where Max does what I tell him to do, but slowly and with unpredictable timing already at sub-50% cpu levels. In other words, (the ability to) prioritize event timing as high as audio signals. Coming from Reaktor, this is the case - events will take the cpu resources they need to do their work in time. IMO, this is what should be expected as the default event behavior, and then users could be able to de-prioritize event streams if needed (...sounds suspiciously like the deferlow object, except the "non-deferlow'ed" streams aren't reliable enough to ensure for example good MIDI performance).

But I'm pretty sure this isn't a wish coming true with the next update... If any time at all...? Please discuss/comment!

You're pretty much on your own here - timing stability in MaxMSP has been discussed any number of times in this forum.

As always - the best way to get the kind of response you might like from us is to be specific. Saying that MaxMSP's MIDI timing is unreliable with CPU over 50% is completely vague, and there is nothing anybody can do to help. We do not know what kind of patch you have written, or what kind of demands you have placed on your system (or how much of the manual you have read)

Send us details - another patch which clearly illustrates the problem, system info etc. I'd be happy to look at it.

Thanks again. I know I've rushed the questions a bit, I'll do a search on "timing" on this shining new forum.

This is getting a bit embarrassing for me - I stated loudly that I had overdrive on, which I almost always have - but when I looked at the synth patch with the timing problems, I remembered that I had to turn off overdrive just to make it work somehow at all. With overdrive on, the events seem to at least be in sync, but even slower and with dropouts and cracks and cpu spikes; not usable at all. I suppose it's all a cpu issue, although I really didn't think the project was too ambitious when I started, based on my experiences with Reaktor. I've done my best (which may not be good enough) to make as efficient patches as possible while keeping my initial design ideas.

I've also tried to adjust the Performance Options settings, without any substantial gains. But again, I'll do a search. BTW, what are these settings like when you make standalones? Do they always get the default settings?

I'm glad you're willing to look at the patch. But it's fairly big and complex, not something you would like to have as text in a forum page. Also, it's got lots of separate subpatches and script files. Is it by any means possible to post zip files here?

Anyway, I'd rather email it directly to you, because it's a project with an official (free) release on a certain web page, and I'm not sure it's a good idea to have unfinished versions of it around the internet. I'll have to tidy it up a little before that though - it's in a condition now even I scratch my head about what I did some months ago. And it will still be complex even at it's tidiest. So I wouldn't expect anyone to have the time or interest to dig into it, but I'll be more than glad if someone did. Anyway, you are really nice people here on the Max/MSP forum.

I've also tried to adjust the Performance Options settings, without any substantial gains. But again, I'll do a search. BTW, what are these settings like when you make standalones? Do they always get the default settings? 

event timing ( - or: voice allocatoin)