Max 7: Removing a style from the Library.
The Documentation states:
Removing a style from your library
On your system, find the folder where your styles are located.
Library styles can be found at NNNN on a Machintosh, and NNNN on a Windows system.
Move the style file(s) you wish to delete to the trash and restart Max.
I am on Mac, where is NNNN :)
Ha i have the same question..
I have already plenty of test styles i want to erase..
I've noticed moving them to the library doesn't copy them to the documents folder. This searching made curious about "greenroom" styles in the application styles folder! But the question also remains for me.
Found the styles folder in /Users/Shared/Max 7/Library/Packages/Max/ !
LSKA there is no such a folder (Users/Shared/Max 7/Library/Packages/Max/ )
on Windows
Yes, that's the path in Mac OS.
It's /Users/Shared/Max 7/Packages/Max/styles on my machine (not /Users/Shared/Max 7/Library/Packages/Max/)
Yes, you're right. Sorry, I typed quickly and made a mistake....
C:\ProgramData\Max 7\Packages\Max\styles
on Windows
okay... so i accidentally hit "copy __ to library" with a style i didn't want and upon trying to find the original and the accidental one in both /Users/Shared/Max 7/Packages/Max/styles and C:\ProgramData\Max 7\Packages\Max\styles i could not locate them on my PC. i tried selecting the style and selecting "clear style" to no effect. it's kind of driving me insane. like... there is no files that even come up with a hard-drive search of my computer. how do i get rid of these things?? maybe i'm dumb? *scratches head*
No Tony..you are not the only one..when i posted the path i have found the styles i have created inside this folder C:\ProgramData\Max 7\Packages\Max\styles..But although i have deleted them the styles reappeared magically..so the question remains (at least on Windows OS).
The library styles can be easily managed as above described by Frans and in the doc, but not the patcher local styles: I found no tool to remove them even if they are no longer used in the patch, or replaced by new styles. As everytime I modify the style of an object a new style is created... the patcher file size increases more and more and max becomes slower and slower, then crashes. Has anybody any idea to purify the code from undesirable obsolete styles as asked by Tada?
I think I have found a workaround: open all my patches and abstractions with Max 6, then record them again, then reopen with Max 7.1 . So all the local styles are lost, but Max works better and faster, and the file sizes are drastically reduced.
I also dropped ~/Library/Application support/Cycling '74/Max 7/Cycling74 directory to thrash and reinitiated Max 7 license.
hey guys,
is there a solution to this meanwhile? because i need to remove the 50+ patcher styles
from a m4l device. they are all saved in the device and unnecessarily increase the filesize.
how do i get rid of them without opening and saving patches in previous max versions?
Hi Guys,
I don't know if this problem has been treated again in the forum but.
Is there another way to erase the local styles from a patch than open it with Max 6?
It seems a bug: local styles simple proliferate and one cannot erase them in any way.
Am I wrong?
thanks
Correct.
It seems that the spontaneous proliferation increases for patchers including many levels of subpatchers
i'm just wondering what the heck this is. and how to get rid of it. its like some self replicating virus (and extends far beyond this screen shot)...???
after all styles are cleared, this remains.
all my patches start doing this as soon as i define a new style, save to to the library, make any changes, then re-define it.
thus far, the only way to clear all these replicas is to do what PIEDAGILE says and open every subpatch in max 6 and reset default. then all replicas go away but I have to restyle everything again... then the self replicating begin again...
moreover, I guess: why this local style proliferation takes so much disk space?
This is not only question of disk space but the application become irresponsive, saving process very long and there are a lot of crashes for a purely graphic matter.
Hope that Cycling will add some "clean-up" function to get rid of this.
I reported this to support a while ago. I used similar words like WIL "It's like a virus" "self replicating styles".
They didn't understand where the problem is. I gave up.
I had to edit the patches in a text editor to get rid of all this replicated styles, they made up a quarter of the overall filesize.
And never touched the local style feature again since.
I'd like to find a better way to get rid of this than saving with max 6.
So what is the solution you found?
Open the fine in a text editor and erase the local styles?
You can search for "styles" : in a text editor and remove everything between the following [ ]
I did it with a m4l device where i also had to use a hex editor to change the file lenght written into the header of the amxd file. I also had to do this with all external patches used by the device. Otherwise the styles came back to the main patcher local style list once reopened and saved.
Is there any logic to this style proliferation? It's becoming a PITA saving in max 6. Any ideas how I can avoid this until it is fixed?
We are working on fixing this bug. It is a difficult one to cleanly reproduce. Apologies for the difficulty in the meantime.
-Ben
in the meantime https://cycling74.com/tools/styleremover/
hey, this issue hasn't been fixed since 2015?
I am never using styles but just figured that I have hundreds of embedded styles in my Max For Live devices and it's probably why my devices are super slow to load.
I have no idea how these got in there and how to get rid of these. Any idea?
thanks,
Florent
can't you use my tool to remove them? https://1cyjknyddcx62agyb002-c74projects.s3.amazonaws.com/files/2015/05/styleRemover1.2.zip
copy the complete folder into the search path before opening the styleRemover.maxpat
yes, many styles will dramat. increase the filesize and loadtime. Cycling fixed something regarding this problem. But I also still find local style lists in devices without using the styles feature at all.
O.
thanks so much 11Olsen! it works great. I had multiple instances inside a poly~ that were 5Mo and super slow to load, and now they're 33KB and loading fine. I guess I'll fill a bug report.
Do you guys at cycling 74 have any intention of ever fixing this mess ??
Interested in the status too.
Every time I think it is my patching skills, but after checking the styles I remember it wasn't me...
11OLSEN, you rock
11OLSEN, how do you open an amxd as a text file?
For some reason your style remover doesn't work on my amxd files; or it works but then the files won't open.
I'd like to remove the styles from the text file if that's possible.
I am still experiencing this issue on many of my max for live devices. They are huge (between 5 and 30Mo) and take forever to load/save...
well your style remover actually works, seems like the issue was a space in the path
thanks again for this, I don't know how I would do without it!
I'm glad that it is still helpful. You say you end up with bloated devices using latest Max (>7.3.0) ?
I guess you are working with m4l devices created at the time the bug existed in Max. (I don't even remember, think it started when 7 was released and got fixed in 7.1 or 7.2)
BTW: the styleRemover tool is just automating you opening the patcher in a texteditor, find the "Style" tags and clear them out.
EDIT: in amxd files it updates the header which holds the filesize. That would require a hex-editor (and a little knowledge about hex and endianness) if you do it by hand.
thanks 11OLSEN
I have no idea of what's going on, but on my machine (os 10.12) running Max 7.3.4, and with devices created from scratch and no copy/paste from old patchers, I still get the self-replicated styles issue. Cycling 74 can't reproduce the issue so it's hard to figure out where it's coming from.
I tried by hand, but I think I broke the code somehow... I guess I don't know enough about hex.
Thanks for your style remover once again, it is still very useful to me!
Hi 11OLSEN, i'm having months ago this local styles problem (my list in a patch is really huge).
i downloaded your tool, when i try to clean a file (amxd) it reduces the file size a lot, but when i try to load the patch in ableton live it says that "the max function 'createdevice' gives error6: broken file"
what i'm doing wrong?
many thanks in advance
Hi rubén , I don't know.
Two things: Please use v1.3 https://cycling74.com/projects/styleremover-1
and make sure the device is not frozen.
If it still doesn't work I can only help if you send me the amxd files(the original and the broken one).
Hi 11OLSEN, i was using 1.2 version, with the 1.3 it works.
i cant't thank you enough....you really save my workflow and mood, i had patches 5MB big which now are 100Kb and open and save fast
al the best
rubén
Hello, I am still having this issue with super big subpatchers accumulating styles for some reason and then taking forever to load into a poly~. This is really problematic for me. I basically cannot work because of this issue.
For example, this poly subpatcher is 11.2Mo: https://www.dropbox.com/s/weocqf8m4g66xue/PolySampler2.maxpat?dl=0
11OLSEN's style remover does not work on this file. Could someone help me clean this file?
I really hope this issue is going to be fixed soon.
Max 8.0.2 - macOS 10.13.6
Florent
I work with sound mass design...my current project has 450 poly~ instances, communicating via OpenSoundControl with Unity. Even in Max 8 here in 2020, I somewhat regularly find styles somehow "infecting" my patches - an abstraction, a poly~, a subpatcher. There they are again, even though I ran 11Olsen's styleRemover some time ago. When this happens, it results in the patch needing to take ~ 10 minutes to save if I make any edit whatsoever. That's a very frustrating workflow. Then I need to (yet again) remind myself its probably that Styles problem in Max. And then I go back through all of my abstractions and poly's and apply the styleRemover again...unfortunately this is still not remedied in 2020 for Max 8. Thanks so much to 11Olsen for the work around. I really wish it would be a priority to eliminate this issue in an update of Max, sooner than later. This not-so-well implemented and largely visual feature in Max really does interrupt the flow of my sound design and composing.