Oh, it works pretty fast.

Thanks will look at that file.

I was trying the |table normalize(

Greetings,
Is there a way to tell if the normalize action is working? Or do you just have to wait?

Thank you so much for the feedback. I understand most of what you have indicated here.

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).

@alexandros

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

Maybe it is quarantining then. I changed the pathway to where the file is but the folder was not recognized by Pd. Perhaps, and very likely, Mac is doing things to make the folder not findable.

Hey,
Maybe this is with all externals, but I have been looking into transferring patches to other computers. I do not understand why, and I assume there is a reasonable explanation.

The patches I have made, I merely just transfer to the new computer. Easy. The patches that are externals, at least in deken, but maybe others as well have to be downloaded again. I tried just moving all of the files to the new computer (I am using macs). I put the files in the location where all the files were documents/Pd/externals.

As I write this, I realize the name of the account might be different which might be the reason Pd cannot find the files. Or is it that the files have to be recompiled.

I am not sure if I had to recompile the files the last time I changed computers which was in 2018 or 2019. I transferred my entire account from one computer to another computer.

Is it common to have to recompile? I assume so. Is there a way around this? At the same time, it might be good to recompile so that I can get any updates from the last time I got the externals.

Any thoughts would be greatly appreciated so that I can understand better.

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.