So, I am switching all of my visuals to GEM from Ofelia. It seems to mostly be working.

I do have a question. When I am using audio I cannot create or destroy a GEM window without getting digital distortion/dropout. Is that just the way it is? Am I doing something wrong?

I just got a fast new computer and I get a very short dropout on [create( but not [destroy(, so I guess that means "yes, that's just the way it is"?

I wonder if you put the GEM stuff in another process (using [pd~]) and you didn't return any audio from that process whether that would address this issue? EDIT: nope, it doesn't. And launching the subprocess is even more disruptive.

Thank you for the confirmation. I appreciate it.

I have changed all of my patches from ofelia to GEM. It seems to be working fairly well. I am pleased. Gem seems to be somewhat fragile.

It can crash the system.

It does not seem to take up too much CPU and can run in the background. I am currently pleased.

Except that dropout when you create and destroy. Wish that could be changed.

@raynovich Did you try increasing the delay in your audio interface settings? On one of my patches that fixes the drop out after I create and destroy the gem window once.

Ha!!!! Yeah. . . I perform live while performing. I am already at a 50ms delay, which makes performance a bit challenging to say the least. I am also trying to get the delay shorter more like 25ms.

Well, if you load a large audio file while sound is playing, you can get dropouts then too.

That's a 97.3 MB file -- "audio I/O error." Only vanilla objects in the patch. Sending that read message does glitch the audio.

So this isn't "a Gem issue."

Since Pd is single-threaded and the control message layer runs within the audio loop, heavy activities in the control message layer can cause audio processing to be late. Reading a hundred MB of audio? Opening a window and preparing it for graphics rendering?

AFAIK the available solutions are: A/ structure your environment so that all heavy initialization takes place before you start performing -- i.e., start Gem before your show, not during. Or B/ Put Gem in a different Pd process (which doesn't have to be [pd~] -- you could also run a second, completely independent Pd instance and use OSC to communicate between them). (Smart-alecky suggestion: Or C/ Move your audio production over to SuperCollider, whose audio engine shunts heavy loading off to lower-priority threads and whose control layer runs in a separate process, so it doesn't suffer this kind of dropout quite so easily.)

"Except that dropout when you create and destroy. Wish that could be changed" -- sure, but the issue is baked into Pd's fundamental design, and would require a radical redesign (of Pd) to fix properly.

hjh

I think Pof, which embeds openFrameworks (much like Ofelia did), runs on a different thread (I think). But I have tried closing its window and that crashes Pd. But I could be wrong, as I could be doing this the wrong way.
Switching back to another external that embeds OF, since you have switched from Ofelia to Gem, can be discouraging. I just thought of mentioning that Pof runs on a different thread (I think).

Hey, I am doing as you exactly point out. I am opening Gem before the concert set begins. I have not yet tested the concert to see if that creates additional dropouts.

Now your other idea to run Gem somewhere else, sound enticing. I am not sure I am "knowledge" to be able to do that right now, but I like it.

@ddw_music said:

Well, if you load a large audio file while sound is playing, you can get dropouts then too.

That's a 97.3 MB file -- "audio I/O error." Only vanilla objects in the patch. Sending that read message does glitch the audio.

So this isn't "a Gem issue."

Since Pd is single-threaded and the control message layer runs within the audio loop, heavy activities in the control message layer can cause audio processing to be late. Reading a hundred MB of audio? Opening a window and preparing it for graphics rendering?

AFAIK the available solutions are: A/ structure your environment so that all heavy initialization takes place before you start performing -- i.e., start Gem before your show, not during. Or B/ Put Gem in a different Pd process (which doesn't have to be [pd~] -- you could also run a second, completely independent Pd instance and use OSC to communicate between them). (Smart-alecky suggestion: Or C/ Move your audio production over to SuperCollider, whose audio engine shunts heavy loading off to lower-priority threads and whose control layer runs in a separate process, so it doesn't suffer this kind of dropout quite so easily.)

"Except that dropout when you create and destroy. Wish that could be changed" -- sure, but the issue is baked into Pd's fundamental design, and would require a radical redesign (of Pd) to fix properly.

hjh

@alexandros

Interesting solution. I went to Gem because ofelia seemed to be less in favor and not being updated?

@alexandros said:

I think Pof, which embeds openFrameworks (much like Ofelia did), runs on a different thread (I think). But I have tried closing its window and that crashes Pd. But I could be wrong, as I could be doing this the wrong way.
Switching back to another external that embeds OF, since you have switched from Ofelia to Gem, can be discouraging. I just thought of mentioning that Pof runs on a different thread (I think).