Holiday notice: Cycling '74 will be closed on Dec 25th, 26th, and Jan 1st. Manual authorization, support cases, and manual order processing will be delayed.
poly~ inside poly~ ?
Feb 22 2007 | 10:13 pm
Hello,
I have a poly~ which allocates 12 voice. each voice has 4 (monophinic) poly~-objects to switch between different voice generations pretty much on the fly.
So generally - a polyphonic synthesis engine that as again 4 poly~s for each voice ....
The mute/unmute-order is
first the voice of the outer poly~ gets unmuted
then the poly~ in the voice gets unmuted
for mute it is the opposite -> first the internal, then the outer ....
this seems to function fine up to the third voice of the outer poly - when the fourth is unmute everything's ok, when it gets muted I get buffer problems .....
and a crash:
Thread 25 Crashed:
0 out~ 0x15d779f4 sout_perform + 56
1 MaxAudioLib 0x007cf06c dspchain_tick + 80
2 poly~ 0x30124108 poly_run + 132
3 poly~ 0x30123d48 poly_processnormal + 92
4 poly~ 0x30123cb0 poly_perform + 140
5 MaxAudioLib 0x007cf06c dspchain_tick + 80
6 MaxAudioLib 0x007cd20c ad_process + 392
7 CoreAudio 0x1584fe98 coreaudio_twodevice_ioproc + 540
8 com.apple.audio.CoreAudio 0x91466cf4 IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 376
9 com.apple.audio.CoreAudio 0x91466a08 HP_IOThread::PerformIO(AudioTimeStamp const&) + 532
10 com.apple.audio.CoreAudio 0x91464a18 HP_IOThread::WorkLoop() + 1156
11 com.apple.audio.CoreAudio 0x91464580 HP_IOThread::ThreadEntry(HP_IOThread*) + 16
12 com.apple.audio.CoreAudio 0x914553dc CAPThread::Entry(CAPThread*) + 96
13 libSystem.B.dylib 0x9002b508 _pthread_body + 96
Anybody any insides? Is it not a good idea to use a poly~ inside if a poly~?
thanks
best
- Feb 22 2007 | 11:29 pmi have no idea what that crash log means, but i do know that using nested poly~ objects is a really good way to eat up CPU usage like crazy. think about it:if you have 12 instances of the outer poly~, and 4 instances of the inner poly~ in each outer poly~, then that means you have 12 outer poly~ instances and 48 inner poly~ instances. that's not a huge deal in and of itself, but if your inner poly~ instances are doing something that uses more than 2% of your CPU, then you probably just maxed out your CPU (assuming none of them are muted).maxing out your CPU is generally not a problem, you just get highly distorted audio usually... though i couldn't imagine that max likes to play patches that spike the CPU usage up to 100%.i would try playing around with your muting/unmuting process. maybe try reversing the inner/outer order and see if that does anything. if possible, maybe try adding some [defer] and [deferlow] objects in your muting scheme to give max a chance to breathe.the description of your patch is kinda vague, so it's hard to tell if you really need to use nested poly~s, or if there is possibly an alternate solution.-scott
- Feb 23 2007 | 4:48 am
- Feb 23 2007 | 10:43 amSteff wrote: > Anybody any insides? Is it not a good idea to use a poly~ inside if a > poly~?It's a good idea, I do it all the time. Without example patch, its difficult to help further though...Stefan-- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
- Feb 23 2007 | 11:50 amThanks everybodyso see below for other info:Can somebody shed some light on how max handles muted poly~s? by default all voices and all poly~s are muted. I think messages are processed in muted voices/poly~s but how about line~ objects and so on? The problem seem to happen then the 4th voice is reset again (like muted, but it also happens if the voice does not get unmuted on the main computer but is delegated to a client for processing - and it happens on the main computer) If I turn off the dsp and back on the problem goes away AND stays away - so I can now reset the voice and no problem .....Generally if the voice is not processed locally there is hardly any params set - most of them are gated .....Also CPU power should not be the main problem as this happens on our Dual G5 and at that point the CPU is showing around 37% 15% - so there should be enough resources left......Well - I want to try to explain a bit more detailed:I have a poly~ (lets say that is P1) in my maxpatch - that one allocates 12 voices - by default all voices are muted.So P1 loads a patch which has 4 poly~s - the idea here is to have three different set of sound generation (the first 3 of those 4 poly~s) and another sound generator that is used in specific cases. These 4 poly~s are also muted by default and I unmute a combinated of those poly~S dependent on which sound generator I need. There is no updown sampling or something like that - it is just about muting and unmuting circuits to save CPU cycles.The next thing - which makes the whole a bit more complex is - that I can distribute each voice over up to 4 computers - so if it is not to be processed in the main computer - neither the internal poly~s get unmuted nor the voice for P1 gets unmuted. However my problem happens also if that voice does not get unmuted at all .... That scares me..... :-)>> Without example patch, its difficult to help further though... Sure, but I am afraid that is not that easy as the voices - all the params of the voices are processed in a different place and the only way to really do that would be to send the whole thing - but that might also not help that much as I do not think that anyone can take the time to study that patch (lots of patches (120 abstractions or so, lots are generated dynamically, there are tons of java externals for custom data structures and so on) - and as I said, the problem does not show up with less than four voices and therefore it is hard to try to simplify the patch as it most likely will not allow to reproduce that problem ....Thanks againbest
- Feb 23 2007 | 12:02 pmno, it is not right what I wrote - after turn off and on the dsp everything is broken :-) nothing functions. MAx just seems to play another part of the buffer ....so ....thanks againbest
- Feb 23 2007 | 6:58 pmok, ok, ok, life is sometimes cruel - seems like it was a typo that caused the problem .....thanks again everybodybest
- Feb 24 2007 | 6:31 pmSteff wrote: > no, it is not right what I wrote - after turn off and on the dsp > everything is broken :-) nothing functions. MAx just seems to play > another part of the buffer ....Sounds like a bug, ------ in the patch...Stefan-- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
