geddonn

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.

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. 

I can post a patch but it doesn't seem to be dependent on patch.


weird-death-by-poly-bug

 and one is not? (Or possibly even more troublesome, using 

 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 

 came out in Max5; at the same time, I seem to remember discussing 

 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 

Bottom line: I know there was some time, but don't know when or if it is still true that 

 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 

Well, all the rest could be non-sense, so here is for sure good part of the response:

Well, there are two possibilities: either you did some strange thing in your patch that is abusing 

 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 

 myself in some ways I personally think are genius, but doesn't mean it works well with 

 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 

 to use parallel processing didn't seem worth it especially with a patch made up of lots of such 

 so I'm working on another solution to build DSP parallel DSP chains.

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

 used for audio where one of the pair is inside and the other is outside the 

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.

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.

In addition to needing ejies, your patches also seem to depend on some external or abstraction 

 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.

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.

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.

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.

Weird death by poly~ bug.