Forums > MaxMSP

event timing ( – or: voice allocatoin)


dhk
January 25, 2006 | 12:58 am

Hi all!

- 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,

Dag Henning


January 25, 2006 | 2:25 am

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

Perhaps this will help…..

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

Cheers

-A


January 25, 2006 | 5:31 pm

Or, conversely:

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



dhk
January 26, 2006 | 11:32 pm

Hi again, thanks for the answers.

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.

Dag Henning



dhk
January 26, 2006 | 11:38 pm

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



dhk
January 26, 2006 | 11:54 pm

…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:

max v2;
#N vpatcher 399 193 852 505;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 292 253 27 196617 stop;
#P message 292 233 65 196617 startwindow;
#P message 273 105 34 196617 3000;
#P message 209 72 14 196617 1;
#P flonum 309 152 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 309 170 75 196617 maxsustain $1;
#P newex 103 60 40 196617 notein;
#P comment 166 158 15 196617 R;
#P comment 148 158 15 196617 S;
#P comment 131 158 15 196617 D;
#P hidden message 350 102 45 196617 target 0;
#P hidden newex 145 215 39 196617 / 100.;
#P user dial 145 170 19 19 100 1 0 0 234 270 1 1. 227 234 168 248 248 248 147 147 147 187 153 91 175 26 26 1 184 43;
#P user dial 162 170 19 19 3000 10 0 0 234 270 1 1. 227 234 168 248 248 248 147 147 147 187 153 91 175 26 26 1 184 43;
#P user dial 128 170 19 19 100 10 0 0 234 270 1 1. 227 234 168 248 248 248 147 147 147 187 153 91 175 26 26 1 184 43;
#P user dial 111 170 19 19 100 10 0 0 234 270 1 1. 227 234 168 248 248 248 147 147 147 187 153 91 175 26 26 1 184 43;
#P newex 264 54 45 196617 loadbang;
#P flonum 241 152 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 241 170 65 196617 retrigger $1;
#P toggle 187 152 15 0;
#P message 187 170 51 196617 legato $1;
#P toggle 179 105 15 0;
#P message 179 126 45 196617 steal $1;
#P newex 77 215 40 196617 *~ 0.1;
#P newex 77 95 51 196617 pack 0 0;
#P newex 77 117 85 196617 prepend midinote;
#P newex 77 195 97 196617 poly~ adsr-synth 5;
#P newex 77 247 28 196617 dac~;
#P comment 113 158 15 196617 A;
#P comment 173 198 100 196617 < -- look inside;
#P user panel 277 226 95 49;
#X brgb 255 255 255;
#X frgb 100 202 30;
#X border 2;
#X rounded 0;
#X shadow 0;
#X done;
#P fasten 24 0 6 0 108 87 82 87;
#P connect 6 0 5 0;
#P connect 5 0 4 0;
#P fasten 8 0 4 0 184 146 82 146;
#P hidden connect 20 0 4 0;
#P connect 4 0 7 0;
#P connect 30 0 3 0;
#P connect 29 0 3 0;
#P connect 7 0 3 0;
#P fasten 25 0 4 1 314 192 99 192;
#P fasten 10 0 4 1 192 192 99 192;
#P fasten 12 0 4 1 246 192 99 192;
#P fasten 7 0 3 1 82 239 100 239;
#P hidden connect 15 0 4 2;
#P fasten 24 1 6 1 123 90 123 90;
#P hidden connect 16 0 4 3;
#P hidden connect 19 0 4 4;
#P hidden connect 18 0 19 0;
#P connect 28 0 17 0;
#P hidden connect 17 0 4 5;
#P connect 27 0 9 0;
#P connect 9 0 8 0;
#P connect 11 0 10 0;
#P connect 14 0 27 0;
#P connect 13 0 12 0;
#P connect 14 0 28 0;
#P connect 14 0 29 0;
#P connect 26 0 25 0;
#P hidden connect 14 0 20 0;
#P pop;

Dag Henning


January 27, 2006 | 3:46 pm


January 27, 2006 | 5:28 pm

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.

Cheers

Andrew



dhk
January 27, 2006 | 7:45 pm

Thanks – that’s good to know!

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!

Dag Henning


January 28, 2006 | 12:31 am

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.

Cheers

-A



dhk
January 30, 2006 | 3:36 pm

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.

Dag Henning


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