How to force the use of the correct abstraction after unfreezing a device?
I have a Max for Live device that uses an abstraction. The Max device is frozen.
I adjusted the abstraction to add some improvements.
When I open and unfreeze the Max device, it still uses the old abstraction, which now lives in the Max for Live Devices folder. The new version of the abstraction is located inside the discarded subfolder. I would expect the opposite. Why discard another/newer version of a patcher that was not even part of the device?
Replacing the old patcher file with the new one breaks existing objects. Creating new ones works, of course. Even if replacing files would work, it would kind of defeat the purpose of abstractions as reusable objects. I shouldn't deal with file management.
What is the best way to have devices always use the abstractions from my Library folder rather than unfrozen ones?
This whole issue with m4l devices, abstractions, and paths is a nightmare, as can be attested from posts I've made to the forum in the past, including the problem you're having. Mattijs Kneppers has some useful tips in this thread I found very helpful (one of which was to use as few abstractions as possible!):
He's also got some good production guidelines here:
But I'm with you, the whole thing is very annoying, and hard to make sense of.
Good luck,
\M
It's good to see that it's truly a nightmare and I wasn't overlooking anything.
The only relevant takeaway from the first link is to never freeze your device unless you're distributing it, and then never unfreeze it.
I don't read anything about using as few abstractions as possible. Good thing too, because such a recommendation doesn't make sense at all.
I'm familiar with the guidelines. Useful info, but they don't address this issue. It could be more explicit about not freezing your device until distribution, and about freezing a copy.
It's hard to believe that this all hasn't been improved. At least the process of automatically making a copy when freezing could have been implemented as a band-aid. There will definitely be a moment when I freeze a device instead of its copy, especially since that's what I'm used to.
Just want to chime in and say I have the same issue with how m4l is looking for dependencies and by times the file organization at all. It is very confusing - especially as a beginner I spent some time to figure out I'm not crazy or overlooking anything. Should be really solved in the future.
Please provide the device with the abstraction and a set of reproduction steps. Otherwise we can only speculate.
Speculate? I can’t imagine the problem is entirely unknown (given the different posts on the subject), and this was never discussed with, for example, Mattijs Kneppers, who works for Ableton and advised against freezing the devices. This advice did not come out of the blue.
You could have at least tried to reproduce the steps yourself to see if it’s indeed a common problem: Use an abstraction in a Max for Live device, freeze the device, adjust the abstraction, and unfreeze the device.
Anyway, here you go. A simple Max for Live device that, when unfrozen, takes all abstractions used in the device but are newer than my Library folder and puts them in the Discarded folder. The older abstractions that were frozen in the device are put in the project folder. So now I have three copies of the abstraction. One from the Library, one in the project, and one in its Discarded subfolder. Imagine the chaos when I unfreeze more devices that use the same abstractions.
The unfrozen device, which is now a project, not using the newer abstractions, defeats their purpose. If the reasoning is that the device should use the exact abstractions as when it was frozen, why are the new abstractions copied to Discarded where they are not used at all?
What I expect to see is that when a device is unfrozen, the abstractions from my Library are used without copying them. So this means I don’t see those abstractions in any of the project folders.
By the way, it’s not only happening with abstractions. The same applies to all kinds of files, such as .js and .svg, as others have indicated.
beside the issues which appear additionally when you use m4l (or in other words, different runtimes at the same time), i believe it is true that you can avoid that if you always use different names for different versions.
even in regular max it was always like that: if you save an abstraction besides an already-save patcher which calls it, it will be found - i.e. even when that location is outside the search path. and even you move the abstraction file, for example to the trash.
only if you do never use double names you can avoid that.
if this leads to dead paths in a patch you will notice it early enough that something could not be found and loaded. then you have to correct that patch instead of changing filenames or file locations. the project will now reload here, as well as beeing portable.
To fix that problem I would not use abstractions,
or at least keep them local, out of max search path.
When device gets unfrozen, replace original files
with modified ones while device is opened in Max editor and save/freeze again.
When done, make a backup together with amxd file somewhere
and delete unfreezed folder from " Max for Live Devices folder"
to avoid further confusion.
P.S.
that patch was created with Max 9.2.0 ?
