Thanks to all of you for your replies.
Obviously, Abyss, Magnum, MDN Sidecar etc. save their activation state at another location than inside any of the files which are stored on the system during the initial installation process. Or rather, the plug-ins save / recall their license status at launch. But in which file?

I found logfiles which contain programming code in ~/Library/Application\ Support/Pulsar\ Modular/ - those were not erased by Wide Blue Sound's Plugin Uninstaller. Also, I checked the default AUpreset files in ~/Library/Audio/Presets/Pulsar\ Modular/ and compared them with earlier versions from time machine. They did not change. I deleted all of them now.

So it turns out, the big question here is: how to do a REAL COMPLETE uninstall of Pulsar Modular Plugins. I hope some of you have some more experiences in this (or a similar matter) and can give some advise.

Unfortunately, MORiA doesn't reply via PM on the sister side. And I don't know another way to get in touch.
So, every hint and support is very appreciated.
Thank you.

 

First part, as I said Wide Blue doesn't find "Everything", but it gets you way closer than just deleting plugins manually. I use this program called Dr. Buho Cleaner, and it is like CleanMyMac. I've never done a shootout between them. Those aren't even the only ones, and so it might come down to what you can find or what you want to "pay for". They do not just find everything and get rid of it; they can often easily get rid of "too much." So you have to be careful automatically cleaning. FAF is killer for it, and I still see stuff you can miss that way.

WideBlue does not do a Monitored Install method like Revo Uninstaller does; but it does find a lot more than most other quick options. It works best when the plugins are still installed.

Don't forget stupid plugin formats you might have installed. Look for the folders /Avid and /Digidesign. Also, look in your Documents folder. Don't forget the ~/User locations. You can often find presets in more locations than one, and that is often how shared plugins "don't have any presets". They just get stuck in the wrong location.

I never seem to have these reinstallation problems, but that is because my firewall works right And I still use more than "just Little Snitch" for dumb things like the Tahoe LS problem you seem to have had happen.

One last trick, Google Mothers Ruin Suspicious Package. It lets you look inside .pkg installer files (like Pacifist does, but it isn't annoying like Pacifist). Then you can look at the pre- and post- installation scripts and a directory tree structure of where your plugins put every file when you install something, before you install it. You do need the original installer to look at, and if you do not keep copies of installers you do have to download another copy of the installer. Then you can manually look and see everything Revo would by doing a Monitored Install.
Almost all plugin installers will be either .pkg files or .dmg files. With .dmg files, you have to first click the dmg like you are installing it to mount it as a virtual disk drive. Then the installer .pkg file will be the second install file you would normally click; sometimes with a nice custom background like HCiso, Moria, Guseppe all do. You can right click that file and open in Suspicious Package.

Make sure you have firewalled your DAW in Little Snitch. LuLu and Little Snitch can be overkill, but I can tell you they work perfectly together anyway. They can cause an issue with your Transmission torrent client, if you use that. But that is a bridge worth burning when you get to it.
You can always use Mac OS system firewall to block outbound data for applications like your DAW, but maybe not for plugins.

Anyway, tldr. Hopefully any of this will help you get more control of your Mac.

 

Could it be that the plug-in writes some hidden files on users hard drive when it realises it is not running a legit copy? Might be then tricky to get rid of it ... I remember I extended some early ilok plug-ins demo mode by deleting some hidden files it was writing (even on external hard drives) to check for the demo period. I used some program to track which files it was writing when running the plug-ins, those were the times heh.

 

The activation status gets presumably recalled from files which are created while running a Plugin inside the DAW. But I checked - there are no PM preference files to be found in both Libraries.
Wide Blue Sound Uninstaller unfortunately does not recognize and delete files which were created by any Audio apps or Plugins while being launched.
EasyFind didn't give me any helpful search results so far (hidden files, contents etc. included)
Any other knowledge about licence storage locations?

 

I regularly use Suspicious package, thanks anyway for the tip (also for others who read this and might need help as well). I will look again into the install scripts.
Any clue how to monitor which files are created or which existing files are changed while a plugin is running? mac Console maybe? (because my suspicion is that, a license file might not be part of the installation package, but is rather created at first launch).

 

Which program was it that tracked the plugin's file creation activity?

 

It is sooo long time ago, maybe it was called fseventer or something like that. However not sure it works with current OS X. I'm sure there are alternatives nowadays though, I would imagine someone would create app like that.

EDIT: from quick googling it seems there's something called fsmonitor nowadays. I'm sure you already know but you need to start such app before starting the plug-in. In the ilok thing the file writing happened when the plug-in was initialised.

 

Last edited: Oct 16, 2025

Meanwhile, I found that it seems to help to change file permissions of the .component-files and VST3-containers, as well as the preset files (!). I added user (me) with r&w rights and set all others (including "system") to read-only.
During the launch of a logic project, AUhostingService is doing a lot of stuff in the background via XPCservice, and it looks like the activation status is recalled and written to one of these files while running the plugins.
Didn't find the source of the recall, tho. Some background actions point to the /Xart and Preboot Volumes, but I doubt it, because that area is heavily restricted.

 

Interestingly, Suspicious Package shows no pre-/post-install scripts; MORiAs Pulsar Modular releases include only one distribution-.xml file each (see example)

Spoiler: Distribution (from P821 MDN Tape v1.2.1)

<?xml version="1.0" encoding="UTF-8"?>
<installer-gui-script authoringTool="Packages" authoringToolVersion="1.2.10" authoringToolBuild="732" minSpecVersion="1.0">
<options customize="always" hostArchitectures="arm64,x86_64"/>
<!--+==========================+
| Presentation |
+==========================+-->
<title>P821 MDN Tape MORiA</title>
<welcome file="welcome.rtf"/>
<license file="license.rtf"/>
<!--+==========================+
| Installer |
+==========================+-->
<choices-outline>
<line choice="installer_choice_1"/>
<line choice="installer_choice_2"/>
<line choice="installer_choice_3"/>
<line choice="installer_choice_4"/>
<line choice="installer_choice_5"/>
</choices-outline>
<choice id="installer_choice_1" title="P821 MDN Tape VST3" description="">
<pkg-ref id="com.pulsarmodular.pkg.p821mdntapeVST3"/>
</choice>
<choice id="installer_choice_2" title="P821 MDN Tape AU" description="">
<pkg-ref id="com.pulsarmodular.pkg.p821mdntapeAU"/>
</choice>
<choice id="installer_choice_3" title="P821 MDN Tape AAX" description="">
<pkg-ref id="com.pulsarmodular.pkg.p821mdntapeAAX"/>
</choice>
<choice id="installer_choice_4" title="Presets" description="">
<pkg-ref id="com.pulsarmodular.pkg.p821mdntape.presets"/>
</choice>
<choice id="installer_choice_5" title="User Guides" description="">
<pkg-ref id="com.pulsarmodular.pkg.p821mdntape.userguides"/>
</choice>
<!--+==========================+
| Package References |
+==========================+-->
<pkg-ref id="com.pulsarmodular.pkg.p821mdntapeVST3" version="1.2.1" auth="Root" installKBytes="57787">#P821_MDN_Tape_VST3.pkg</pkg-ref>
<pkg-ref id="com.pulsarmodular.pkg.p821mdntapeAU" version="1.2.1" auth="Root" installKBytes="57695">#P821_MDN_Tape_AU.pkg</pkg-ref>
<pkg-ref id="com.pulsarmodular.pkg.p821mdntapeAAX" version="1.2.1" auth="Root" installKBytes="57792">#P821_MDN_Tape_AAX.pkg</pkg-ref>
<pkg-ref id="com.pulsarmodular.pkg.p821mdntape.userguides" version="1.2.1" auth="Root" installKBytes="6571">#User_Guides.pkg</pkg-ref>
<pkg-ref id="com.pulsarmodular.pkg.p821mdntape.presets" version="1.2.1" auth="Root" installKBytes="135">#Presets.pkg</pkg-ref>
</installer-gui-script>

As you might have noticed, I am not a pro when it comes to analyzing and manipulating the Mac file system (I am studying every day). Therefore, thank you very much for all the precious information

I noticed another interesting detail: in ~/Library/Application\ Support/Pulsar\ Modular/, the plugins at stake save & modify .log files containing cryptic characters, probably machine code (Unfortunately, I could not find any solution to translate these entries for human reading).

I restricted permissions for these .log files, but left one file accessible for testing purposes. Interestingly, the activation code was later requested for the very plugin whose .log file remained accessible. All others launched & worked fine; none of that "infectious" >please activate< - behavior anymore.
I would also like to find out, based on which .plist or setting (<--modified while calling home?) any Logic-related XPC Service modifies the .log files (if my assumption is correct that these log files deliver the activation status). I did not find any .plist files identifying as Pulsar Modular-related; but rather assume that any part of common mac-internal logging architecture would be used for this. (No further insight available in my personal stock of knowledge)

A terminal command for specifically tracking file operations in the background while I load certain plugins would, of course, be extremely helpful and great. Also, for future scenarios, if any issues occur.

Your entire help is very much appreciated. Thanks in advance for the command, I'd consider it very helpful.

 

Last edited: Oct 19, 2025 at 2:41 AM

hey, when you specify one plugin and the actual version to look at, I went and was about to install it to do some testing. Did you look and see the Developer of these seems to have not even confirmed these will work with Tahoe? Of course, that doesn't mean they will not work.

But I found a user post about this one and Tahoe. Try it with just this one to see if this works, I think it will. Keep the installer around if you have to reinstall it just in case. But I think you already have done it often enough:


"For any ARM AU users who find this plugin deactivates, after trying everything I could think of, e.g., delete all obvious traces, install ealier versions, codesigning etc., I found the solution that worked was to remove the ARM portion of the plugin, reboot, then it was activated when using Logic in ARM native mode. I'm using M1 Tahoe, Logic 11.2.2.
The three Terminal lines of code are:


cd /Library/Audio/Plug-Ins/Components
sudo find . -name "P821 MDN Tape.component" -execdir sh -c 'lipo -extract x86_64 "$0/Contents/MacOS/P821 MDN Tape" -o "$0/Contents/MacOS/P821 MDN Tape.1"' {} \;

sudo find . -name "P821 MDN Tape.component" -execdir sh -c 'mv "$0/Contents/MacOS/P821 MDN Tape.1" "$0/Contents/MacOS/P821 MDN Tape"' {} \;

Reboot then re-check for activation status."

Not my solution, so credit to someone else if it works. I think he may have just mis-stated removing the ARM slice of the u2b, instead of the Intel slice. I think you want just the ARM Mach-O binary slice remaining to use Logic in Native mode. His command syntax is fine, because it is probably from Chat GPT anyway

 

Last edited: Oct 19, 2025 at 5:46 AM

Wow. Thank you. I'll give it a try. May I ask, where did you find this? (Reply via DM, if useful).
Would it be the same if I remove the Intel architecture of the plugin with Oven Plugin Manager (see https://ko-fi.com/s/ea8ef59ef3)?
Again, much appreciated. Thanks.

 

Last edited: Oct 19, 2025 at 2:04 PM

Of course, this does not work. You'll have to use the silicon-related equivalent of x86_64 in this command, which is arm64. And, this is exactly what the Oven Plugin Manager does. Therefore, my last question is obsolete.
Thanks again.

 

Well not exactly. People on ARM Macs have mentioned using the Intel slice to authorize things before, but that was just by loading the plugin via Rosetta2, then authorize, patch, or keygen the plugin. Then they would close Logic and reopen in native mode and that plugin would work and be authorized still.

That's why I think that command was generated by an AI. It's too complex in syntax for the rest of the comment, and I don't think you'd want the Intel binary there; unless Moria's released Intel slice is [k]'d correctly and the ARM version is not (for Tahoe at least). The command to remove the Intel slice only would be more simple (less complex), and the reverse outcome:
lipo -extract arm64 "$0/Contents/MacOS/P821 MDN Tape" -o "$0/Contents/MacOS/P821 MDN Tape.1"

One guy on here posted a little application he made that scanned plugins to see which architecture they contained, and I suggested to him to make one that actually removed all the slices you didn't want to have causing issue, if they were. I didn't care because i'm on intel anyway, so the only saving to me would be ssd space. Some other guy ended up posting that as an application about 3 weeks ago maybe. It is probably still on sister site. I made a script to do the same thing (and other stuff) to not use a compiled application from someone I do not know or want to "beta-test" something that will break things. It's funny thing, but most "studio owners" never want to use anything that may end up being unpaid beta tests which stop them from making money by having working computers and rushing into MacOS updates on already working systems.


"Even though Logic Pro is supported, the ecosystem (plugins, drivers, audio interfaces) may not yet be fully validated for Tahoe. The guide specifically says “very few, if any, of the plugins will be supported” at this early stage of Tahoe". Production Expert

Remember that when you alter a plugin like that, you may need to even re-codesign and de-quarantine it. Sometimes you can just use the command Push to have MacOS touch the binary again and recognize it has been changed

That comment was left on Audionews. It can be a decent other source of info. The search filters on most torrent trackers are usually easier to get good specific results from. Not to mention, are way less likely to have anything dmca requested/removed that has not been nuked.

 

Now, after reinstalling the rest of MORiAs PM plugins & removing intel architecture from them via Oven, I find them all opening & working just fine. I'm not about shouting "Halleluyah" yet, since I'll wait for another 3-4 weeks period to see what happens then.
But NOW it's adequate to mark this thread as solved, for now.
If the activation request will pop up again, I'll post an update.
Thanks a lot for your help. The hint regarding internal intel/arm architecture seems to solve the whole damn thing (just swearing to express temporary relief).
Have a nice day, Mr. Clone.

 

Thanks again for your additions & clarifications. I'll keep it in mind. As I said, it seems to work for now. Would you mind sharing that script via DM? Thanks.