Weird death by poly~ bug.
Hi guys, I keep getting a weird bug when using poly~.
Basically it happens at complete random, I have tried to find out what is making it happen but there is nothing that seems to bring it about and nothing in my patching that could cause it.
What happens is I randomly get a really loud constant distorted drone that could be very dangerous on a large sound system. It goes away when I turn the DAC off then on again.
The poly~ is just a really simple sine/triangle wave generator.
Although it also happens in other poly~ patches. It's always the same really loud explosive sound that randomly occurs.
I'm using a few of these patches with a big sub woofer I'm borrowing soon and don't really want to lose my head.
I'm using the latest version of Max6 and the last version of Snow Leopard.
I can post a patch but it doesn't seem to be dependent on patch.
Are you using any send~/receive~ where one of the pair is inside the poly~ and one is not? (Or possibly even more troublesome, using send/receive for audio signals where one is inside and one is outside?) I'm not 100% sure that doing so would cause a problem, but I seem to remember warnings against doing so when the parallel processing features for poly~ came out in Max5; at the same time, I seem to remember discussing send~/receive~ accross patches with the new parallel processing features of Max6 with one of the develoeprs at the NY Expo and I kind of have the feeling that part of that conversation was that send~/receive~ into/out of poly~ should be fine now too.
Bottom line: I know there was some time, but don't know when or if it is still true that send~/receive~ into/out of poly~ was a bad idea, but I think using send/receive for audio into/out of poly~ is probably still a bad idea. Sorry for the long rant, but just wanted to be clear that I'm not sure this is bad practice these days—at the same time the problem you describe and the fact that switching audio on and off fixes things seems to made me think it might have something to do with syncrhonizing threads between poly~ and the rest of Max.
Well, all the rest could be non-sense, so here is for sure good part of the response:
I can post a patch but it doesn't seem to be dependent on patch.
Well, there are two possibilities: either you did some strange thing in your patch that is abusing poly~* or there is a bug with the Max6 poly~ and all the patches you have tried illustrate the bug. Either way, post it. Even if it is not patch specific does not mean every patch will demonstrate the problem, so if it is not your patch but a bug it could help the developers to see a patch that does illustrate it. I can tell you from an experience a few hours ago (and every day for the past week) that on a software development project I'm working on right now every time I think I have a new feature tested (not 100% unit test coverage I'll admit) and debugged, the presets the guy I'm working for seems to try will find a bug right away every time.
*Not trying to claim you were doing something stupid, I've been known to abuse poly~ myself in some ways I personally think are genius, but doesn't mean it works well with poly~ they also might have not been a good use of parallel processing and been a big waste on CPU (and who knows, maybe had to do with unresolved bugs on that project)—and ot any devs that might see this, this was about 2 years ago, so haven't tested the patch I'm talking about on recent Max5 or Max6 because like I said, this was an abuse that I'm looking into writing other externals to solve (short version is, 8+ ins/outs to a 2 to 4 voice poly~ to use parallel processing didn't seem worth it especially with a patch made up of lots of such poly~ so I'm working on another solution to build DSP parallel DSP chains.
Wow that was long, don't want to delete it because it was what I meant to say, but I feel bad ranting for such a lame answer. Here is the short version:
any send~/receive~ or send/receive used for audio where one of the pair is inside and the other is outside the poly~?
Post a patch, even if it isn't a problem with your specific patch, maybe you found a patch that illustrates a bug that the devs haven't seen.
Ok, so here is a patch that it happens in. It's a little messy but is just something I'm working on with a composition for sub frequencies.
Poly:
Master Patch:
Watch out for your sub.
In addition to needing ejies, your patches also seem to depend on some external or abstraction ION and yafm which I could not find anywhere. If they are abstractions can you post those also? If they are externals can you tell where to get them?
In general, if you can make an example patch to demonstrate a problem that doesn't rely on external objects that's probably easier for other people to help debug your patch (assuming it isn't a problem with the external) and for the devs to find bugs. Of course if you can't make this problem happen without this specific patch, no worries.
Sorry ION is simply IO but I added something to the patch for ease of use in recording. YAFRN is also simply YAFR but I added patcher args so I could give the object arguments.
Yeah I forgot to mention the need for ejies. It's just to modulate pitch/phase/amplitude.
Any ideas on what might be causing it then? The problem is still happening.
I have noticed that in this patch when it explodes after resetting the DAC I have to also delete and remake the omx.comp~.
Not sure if this is because the overloaded signal blows up omx.comp~ or whether omx.comp~ is part of the cause.
Ideas would be most helpful.