Workflow in M4L - thoughts?

Questions and discussion about building and using Max for Live devices
Post Reply
jayemell
Posts: 95
Joined: Wed Nov 18, 2009 6:05 pm

Workflow in M4L - thoughts?

Post by jayemell » Thu Jun 12, 2014 6:12 am

I'm just getting into a situation in which I want to do the following:

1. quickly edit devices on a test session (apparently makes all instances of devices on my particular session lose parameters, so I can't edit on someone's session that I want to update the plugins on)
2. send devices that work to people (even if there are bugs I need to know that the data that they are editing in my devices is saved and will be retained, and that they can keep working with them)
3. keep working on my local copy and sending them updates

Now, I realize that there are a few ways to do this, but I have to ask:

--- Should I be keeping my devices in a project folder that I can send them, or should the devices be in my Ableton user lib (/Users/me/Music/Ableton/User\ Library/Presets/*)

--- Is the answer to freeze the devices every time I send them to them?
For example, I could
1. freeze
2. send the frozen plugs to them
3. un-freeze
4. keep working

Anyway, I just wanted to know what people are doing, or if there is an "official" way
I'm aware of "collect all and save" - wasn't sure if this was the best way to pass things, or what the general methods are between collect-all-and-save vs. freezing vs. user lib, etc.

Thanks for any and all thoughts!
jml

T0n1
Posts: 13
Joined: Wed Apr 10, 2013 11:23 am

Re: Workflow in M4L - thoughts?

Post by T0n1 » Sat Jun 14, 2014 11:36 am

I'm still on Live 8.4.2. Parameter pesistence behaves differently when editing devices in preview mode (see http://cycling74.com/docs/max5/vignette ... eview.html) where parameters often get lost upon saving or in normal m4l mode when just the device files are updated without editing them in Max. On the last page of the Production Guidelines (see http://downloads.ableton.com/misc/maxfo ... elines.pdf) they state: "When providing an update of a previously published Max for Live device, avoid changing the “Long Name” of any live.[x] object." Then the parameter values won't get lost.

My workflow therefore is to edit a device in a development project in a "single instance" Live set with just one instance of that device where I don't care about parameter persistence. In the same project, there are other test Live sets with several instances of the same device where I avoid editing the device itself to retain parameter values. Thus I save the device in the "single instance" set, close that, open the test set and check how the device works in context.

Only when I'm happy with the new version of the device, I freeze it and copy it to the user library where other live sets in other projects will pick up the updated version when opened. But freezing is just necessary if the device contains auxiliary files like subpatchers or JavaScript files. In the development project, these are picked up from a specific subfiles folder in the project where I edit them, in other projects, they reside in the library in the frozen device itself.

Things get messy when the devices are saved in rack presets as .adg files. Then Live will copy the m4l devices into a Max folder in the Live project folder, pick it up from there when inserting the .adg file in a Live set, and when working with multiple .adg presets, Live will create duplicates and pick up these instead of the eventually updated device files from the library. This makes sense if you consider the .adg file as a "device group" with a specific version ot that device. If I get lost, I use Live's File Manager to appoint the Live set to the updated devices with hot swapping. If you delete the old versions before opening a suspect set, Live will appoint you to the missing devices by itself for easy hot swapping.

stkr
Posts: 35
Joined: Wed Apr 30, 2014 10:52 pm
Contact:

Re: Workflow in M4L - thoughts?

Post by stkr » Fri Jun 27, 2014 9:10 am

in max6 .amxd is almost exactly the same format as .maxproj, except .amxd automatically consolidates _on freeze_ whereas .maxproj you choose.

i collaborate on builds, and we even have a shared max library in package format backed up automatically across various machines, but still we freeze. it is the only way to be sure.

amxd rule 1)
freeze
amxd rule 2)
freeze
amxd rule 3)
freeze

hth.

p.s. - amxd rule 4)
freeze

S4racen
Posts: 5172
Joined: Fri Aug 24, 2007 4:08 pm
Location: Dunstable
Contact:

Re: Workflow in M4L - thoughts?

Post by S4racen » Fri Jun 27, 2014 9:14 am

stkr wrote:i but still we freeze. it is the only way to be sure.
This....

Cheers
D

Post Reply