If anyone was curious, I haven't necessarily figured out the "why" involved in this problem, but I was given a workaround that seems to be going alright by Baptiste Chatel on the facebook forum for Pure Data / GEM. Evidently if you have two instances of pure data running independently, and have one patch mostly handling video, and the other handling audio, and communicating via netsend or something similar, the problem can be avoided. Not perfect, but it will do for now.

Hello mraeclo,

I may be thinking about this wrong, but I'm not sure that you necessarily even need to use osc in this case, given the kinds of numbers you're looking at. Would it maybe be just as effective to use midi in this case? if you're using a mac, it's easy to route midi numbers through the IAC Driver. I don't know what Resolume's implementation looks like, and maybe it's better to use OSC, but if it's a problem that could be solved more simply with midi, that's probably what I'd do.

@m_alex_morris also, I get the error "GEM:Someone sent a bogus pointer to copy2image"

Hey all,

I'm a little new to this forum, but I'm not too new to pure data. I'm working on a project using GEM to drive audio, and one of the key elements in the patch is an internal video feedback loop using [pix_snap]. The visual elements look great, but I realized that whenever [pix_snap] is banged, it interrupts the audio processing. No idea why this is happening! Any recommendations on how to address this?

the culprit in the patch is this grouping of objects:

[gemhead 100]
|
[t a b]
| /
[pix_snap 0 0 640 480]
|
|

This is mixed through a [pix_mix] with another gemlist with either an image or a movie in it to instantiate the feedback. when I have audio running (a bank of oscillators using [pix_blob] and other objects to analyze the image and control various parameters), there is a constant, rhythmic dropout in the audio. When I unplug the wire from [t a b] from the bang outlet going to [pix_snap] the audio becomes totally clear. Not sure what's happening!