This is why I'm not personally using Auganizer: though it be ever more painful I prefer to run a more vanilla system. Actually I'm running an archaic as well as vanilla and painful system

I can't speak to what Auganizer's doing, or the ramifications of altering plist files (that's not precisely code, but it is part of the Audio Unit all the same: it's included in the component package) since I'm not really sure what exactly is being done myself. To some extent when you get into modding systems to work differently, it's a given that SOMETHING will be changed and as it happens you don't have to change the executable code to do this. It's a bit like pasting on a different icon, only a little deeper and less user-accessible. I could see scenarios (having to do with sandboxed code, probably) where making any changes to the signed package would be bad.

I don't think that holds today. Seems to work fine for now. We are all, as Sean says, rather at the mercy of Apple to not break stuff and avoiding Auganizer isn't a guarantee of total safety. Even I had to update all of my plugins and freebies and legacy plugs to run 64-bit (a couple years ago) and my stuff is about as immune to such growing pains as anything could be. There's literally nothing to it but the audio code, by design: but if Apple does something really epically broken, I'm on the hook along with everybody else to update the lot.

What I can say to Auganizer users who're also Airwindows users is the same thing some people have learned through personal hardship: I'm a tiny company, just one autistic nerd trying to scrape by through audio performance alone, and willingness to help customers.

So, if Auganizer ever breaks anything ever, email me and I will send you a fresh copy, just like I've done a bunch of times to victims of hard drive crashes

I suppose if you stole the Airwindows plug in the first place and then it broke, you wouldn't be in my records and thus out of luck, but expecting support in that situation is a little beyond fair. In that case the support is a one-time $50 of buying the thing properly…

First of all Sean (Valhalla) thanks for that, we're really glad to have you on board as we are all devs and want to work closely with everyone. Of course we'll respond with a copy of Auganizer and you can test everything your end to conclude you're happy with how it works with your plugins

Secondly id just like to temper down some myths and/or fears here. Nothing we do is going to change compatibility with Audio Units in any shape or form past what your plugin is already compatible with (e.g. if it does/doesn't pass Logic's AU test). Its 100% the same plugin, but now given the name the user wants rather than the original manufacturers name. Remember Apple edits a lot more of a bundle when it injects its receipts into it for the Apple store.

*IF* Apple make any sweeping changes to the Audio Unit spec in the future, then those changes would apply to a developers plugins anyway and naturally if any naming conventions are changed specifically they'd also apply to the original versions of those plugins are we're only working in the AU standard. Ultimately with Logic there is actually no need to even work with any reference files or plists or anything else as part of the plugin, we could simply read the data, edit it in our own database and work directly with Logic - but this method reduces the amount of global Audio Unit hosts it works with, including Ableton, DP and Presonus One.

@Sean - there is the option to revert everything to stock with one button in Auganizer you simply lock the plugin, the one in the user folder is deleted and the original system file which hasn't been touched will be seen by Logic as originally instead (Apple programs will always load anything from the user directory over the system folder as standard). On top of that there is always the restore selected or restore all plugins to factory defaults (as well as previous session values if you want to roll back changes to one version ago) which again get you back to stock in a few clicks - when we launch the next update which will update system files this will be the easiest way to revert back to stock too. We'd still always recommend people have a back up of their system though, for obvious reasons, whilst Auganizer is totally safe, you never quite know if you're going to have a power failure whilst copying data, or a computer failure or all the other reasons to make sure you backup regularly.

To be honest any issues we've had in this thread with the exception of literally one or two plugins which do not like being run from the user directory (so putting them there was the problem, rather than changing the name they display) were all to do with Auganizer reading unusual strings or illegal characters from the plugins which didn't follow the same standards as all of the others - and the original issue with 32 Lives was quite simply because Auganizer didn't originally move the 32bit component with the 64bit one (so again nothing related to renaming) - we've not seen a single error/problem occur anywhere to do with renaming, and we shouldn't see as it conforms with legacy, current and future 64bit Audio Unit standards as laid down by Apple. We just have to make sure that the plugins are either happy to be moved or are being read/written to properly.

We really think people are going to love the new update. It addresses everything mentioned in all the threads, all the incompatibilities people brought up, most of the missing features and a whole lot more. We're really happy with it, its going to be ready really soon.

To finish up we're 100% confident the renaming conventions we have in place are 100% compliant with Audio Unit hosts and the AU standard just as all the original plugins are and very happy with the way we interface directly with all Logic versions and Garageband to ensure the user can do this quickly and easily.

Ah, that's much clearer now. Thanks.

Dannys1 I have one question: is the renaming working for projects compatibility?

I try to explain: I renamed manually a few plugins in the past (Nebula mainly) and obviously used these duplicated plugins with names changed, but now with new version I'd rather rename the new version(s) and change their names using Auganizer.

So if I created a 'Nebula EQ' plugin duplicating the original 'Nebula 3' plugin, and I used this in a few projects, can I use Auganizer to take a newer/updated version of 'Nebula 3' and rename it to 'Nebula EQ', will it open correctly old projects using a plugin called 'Nebula EQ' ? Obviously I talk about compatible versions/plugins.

I ask this because I don't know precisely how Auganizer works (cache or any other) and how Logic (X and 9) load plugins (by name, id, other?) and if Auganizer works around that.

Thanks!

Dannys1 I have one question: is the renaming working for projects compatibility?

I try to explain: I renamed manually a few plugins in the past (Nebula mainly) and obviously used these duplicated plugins with names changed, but now with new version I'd rather rename the new version(s) and change their names using Auganizer.

So if I created a 'Nebula EQ' plugin duplicating the original 'Nebula 3' plugin, and I used this in a few projects, can I use Auganizer to take a newer/updated version of 'Nebula 3' and rename it to 'Nebula EQ', will it open correctly old projects using a plugin called 'Nebula EQ' ? Obviously I talk about compatible versions/plugins.

I ask this because I don't know precisely how Auganizer works (cache or any other) and how Logic (X and 9) load plugins (by name, id, other?) and if Auganizer works around that.

Thanks!

Hi Rofus,

By standard, Logic doesn't recognise plugins based on their set manufacturer/plugin name, so you can change them as much as you want, see the video I made to demonstrate this here, which may answer all your questions.



Now the only thing that concerns me with your question is that you talk of duplicating nebula again and then renaming it. I would SUSPECT that Logic wouldn't track this due to the way it recognises plugins as per the example above. I understand what you're trying to achieve, however if you duplicate the original Nebula component file both Logic and Auganizer will currently only see one version of it. It sounds like what you want to do, is an upcoming feature, where you take a single plugin (in this case Nebula 3) and have it appear in multiple menus within Logic and perhaps have it named different in each one too.

With this very specific scenario I would suggest it'd be best to wait until we implement that feature before attempt to rename Nebula again. Not the answer you're currently looking for I don't think, and a tricky situation, one that even at that stage i'd have to test myself to see what the results would be.

Thanks for your reply, all clear.

Yes my situation is a bit 'unique', I'm beta tester for Acustica Audio (and few other manufacturers) so I very often have custom configurations. With Nebula I also helped users creating the AU 64bit wrapped, and I'm currently using it, and I published here the guide to rename it (or any other plugin) with mixed technique of editing plist and rsrc, you know what I'm talking about. I also published here on GS the files and instructions for users to download a ready to use wrapper for their Nebula, so I'm curious to see how all this will work with Auganizer.

I also developed the app/utility (again here on GS) to have Logic authorising all plugins (to avoid the 'Unauthorised' menu), so as well I want to see how it will work with Auganizer

I asked because what I need indeed is for Logic to recognise a renamed plugin exactly as a renamed plugin, after duplicating and modifying it for renaming, but I understand what you mean.

Will try maybe the demo and see if/how it works with all this!

Have you got this working internally, or is it something that's simply on the wish list for now?

You are correct that (in general) you can't have multiple copies of a single plugin floating around, I'm assuming Logic uses some ID system to identify plugins.

So in order to have plugins show up in Logic in multiple folders, they would have to have unique ID's - now you have some compatibility issues seeing as MyAwesomePlugin loaded on one channel from the "Favourite" folder/menu is technically a different plugin to the instance of MyAwesomePlugin loaded on a different channel from the "EQsISeldomUse" folder/menu. And storing and keeping track of presets becomes a(nother) nightmare!

I guess you could potentially create fake plugin wrappers with different ID's that internally host the (original) plugin inside, maybe, but again, I'd be worried about a tool doing that much rearranging of other developers plugins - it's quite messy... but I suppose 32Lives uses a similar approach to achieve it's ends and seems to work quite well, so...

Or maybe you have a different plan/solution...

The hacks that we have to do just because Apple just don't see the value in this is bonkers, really... :(

You're right, its a difficult situation to tackle. This is not something we've looked at internally yet, its just on the road map as a feature request. We will see how well we can tackle all those issues you mention though. What ends up may not be the "perfect" solution for everyone (a little like sub folders) but at least it'll give people a choice of how they might want to work.

RE What you mention as problems there though shouldn't really be an issue. We'll easily be able to make all "versions" of the same plugin you create share the same presets folder. Any old projects will also just load up the original ID plugin so it won't go missing and any future projects where you use the same plugin multiple times under its different alias' will just use your new naming scheme. Id be more concerned with making sure that if someone upgrades a plugin we're able to upgrade all the "duplicates" easily too.

When´s the update coming? I wanna buy it. ;-)

Extremely frustrated! Since I "tried" this tool, my TB Reelbus is set to default in all tracks I have it in (which is basically ALL tracks I have been working on since weeks). Wow, that is a MAJOR slap in my face.

Sounds like an easy fix looking at Toneboosters documentation

"VST/AU trial/evaluation plugins can be upgraded to fully functional versions with a separate registration ‘key file’. The registration key file can be acquired at www.toneboosters.com and must be stored in the exact same folder/directory as the corresponding VST plugin or audio unit component. This means that in one and the same directory, you should display the following pair of files for each registered plugin:"

Just make sure your key file is in the folder with the plugins (~/Library/Audio/Plug-Ins/Components) - Toneboosters won't recall settings if in demo mode. it appears you have your original plugins in either the system folder or a custom folder and thus the .key files haven't been carried across. (There is no installer for Toneboosters, as they say in their PDF they want you to manage the system yourself, so only you know where you dragged them and put the key files)

Nothing is lost or changed, just copy your .key files over, or, as with any plugin, click "lock" and you'll be using stock plugins in original location.

Very eager for the 1.0.2 upgrades and hope really soon is indeed really soon. I'm sure there have been many a sleepless night the last few days for the Auganizer folks.

We certainly are, in fact there are so many big new features and fixes its going to be v1.1

I can't wait to show them all to you and explain all thats new and different. Fundamentally the way a handful of plugins are slightly different has caused us to bring forward one or two big features we had planned for further into the future, which is a good thing, but its also brought on a rethink on the simplest way to implement them and the most intuitive and least confusing way to get around the software now.

Most of the functionality is there, all the plugin devs have been fantastic, we've literally be talking to 45+ of the major players this week to ensure compatibility with any changes they might make down the line and to future proof where Apple might be heading with sandboxing and signature checking (based on Garageband 10).

Anyway thats enough for now, I'll be back with a big detailed update and will try to launch with a full tutorial video in the next week.

I've been wanting this for a looong time.

As soon as it gets more stable I'll be picking it up.

I'm hoping it will be good for separating the UAD demos.

I can't believe it's taken a 3rd party to make this happen. Hopefully this will wake Apple up about the demand for this feature.

I love Auganizer, but if you want it solely to get rid of the UAD plugins you don't have a license for, you can use Logic's own Audio Unit manager to disable all the plugins you don't want to see.

True, but I still want to be able to use the demos. I just want them in a separate folder.

And I'm also very much looking forward to organizing my plug ins in a meaningful way.

Almost missed it.... COOL PRODUCT!!!

Any news on an update?

ETA Sunday/Monday for v1.1 - i'll do a big post on here with all the changes and updates. I'm really excited about it. Going to try and launch at the same time as some detail video tutorials as well.

Excellent. Looking forward to it.

Good news - we are excited here in Germany as well !

Cheers, Peter

+1.

OH where is it??

Eagerly awaiting the update here in New Zealand!

1.1 is up and ready for download.

k

1.1 is up and ready for download.

k

Is there a change log available?

Where do we download the update?

Do I download the demo and update the serial number?