I'm having a hard time getting Henke's Granulator II device to work properly in my Max 7 patch. It uses the 3 dashes prepend to object names to isolate 'm between device instances. Are these supposed to work correctly when copy pasting the device contents into a Max patch?

I'm doing this copying because the device doesn't work properly when embedded in an amxd~ object in Max. When dragging a sample onto it the waveform and filename is displayed but the sample length isn't and the grain visualization doesn't draw in the correct position.

When opening the amxd file as a patch it also doesn't work correctly in presentation mode but does in patching mode... That's why I try to get the full patch out of amxd and into a regular Max patch to customize it to my needs. I don't intend to use it in Live.

m4ls-3-dashes-in-max-7

Granulator II works fine here inside amdx~. The broken functions you describe are related to JS files - some of them are probably not found in your case. Is the device frozen in Live?

"---" only works in M4L devices. When converting to a regular Max patch you should probably convert the "---" to #0, keeping in mind the differences: while the dashes will be substituted in subpatchers/abstractions always with the same value inside a device #0 will have different values - also unlike "---" #0 doesn't work in top level patches (as you of course know ;) ) so there might be some more adjustments necessary.

Hi DTR,
Granulator II works fine here inside amdx~. The broken functions you describe are related to JS files - some of them are probably not found in your case. Is the device frozen in Live?

Are you sure it works 100%? In my case it loads the buffer and plays grains but the display isn't updated correctly (sample length and grain positions). Sample length for example stays at 10 sec, whatever file gets loaded.

I had the js files sorted. Took 'm from the unfrozen folder and put 'm next to the patch file.

What you're saying about "---" confirms my hunch. C74 could perhaps consider making this transition smoother to improve interchangeability between Max and M4L.

Are you on OSX or Win? I'm running Win8.1

I've completely stopped trying to use amxds in my setup now. I've resorted to copying things over from them instead.

Also, why isn't there the "open new view of..." option like with bpatchers? I'd like to check what's going on in the guts of an embedded amxd while it's operating (just look around, not edit). Seems I can only open the original amxd from the context menu, not the embedded one. Am I missing how to do that?

Edit: Ok I just worked it out myself. In edit mode, control+double click the amxd~ object's title bar. That opens up a new view of the embedded device.

Now if I could work out how to use Live adv preset files on amxd~ devices in Max...

@DTR I am on OS X (10.9.5). You were right, the same behavior here: in edit mode the device works correct but not in display mode. It's a bug in the live.drop object, in presentation mode it does not output the filename properly here. I have seen that behavior before in M4L of single objects gone bad. try substituting it with a new live.drop (not delete/undo). works here.

Now if I could work out how to use Live adv preset files on amxd~ devices in Max…

To my knowledge it isn't built in (yet?). inside Max - for whatever reson -there is the concept of snapshots vs. Live presets. It would be great if the restore message could read .adv or if there would be an importpreset message to include existing .adv. But not for the moment .... :(

live.drop: Great, thanks! That works. Can't believe how much time I wasted on that one. I should 've known upgrading to 7 just before a big show is no good idea... Now on to actual production.

No it is never is ;) I still have 4.6, 5 and 6.1 up and running in case some old work is requested :)))) suerte para tu concierto.

A friend of mine uses to say "never trust a dot zero".....

This is usually my stance as well but the proposition of using m4l devices in Max lured me in...

To me it's more an omission that is now repaired ;)

Next puzzle: I edit the poly~ patch inside the amxd, save the poly~ patch under new filename, edit the poly~ object to load the new one. Works fine the first time round. Now when I edit and save the new poly~ patch again with same filename the poly~ keeps loading the first edit, not the 2nd. I've tried deleting the poly~ patch file from my HD altogether. The poly~ inside the amxd keeps loading the first version of it, even though the file is deleted. Is there a cache somewhere (that apparently can't be found by Windows' File Explorer search)?

It's not in \Documents\Max 7\Max for Live Devices\

when you edit & save a M4L device in max and close the editor the device is frozen automatically therefore it loads the version stored inside the *.amdx file.

Then how do I get it to load the latest version of the poly~ patch?

In short you'll always have to edit it from within the opened M4L device. You can't edit it outside that scope and reload. If you edit it "externally" and then re-open your device in Max the new version will be overwritten with the stored version inside the *.amxd.

The workflow is at the moment the following:

- Open device in Max, (will create the Project if it does not exist)

- edit/save poly subpatch -> will update the file inside the project

- SAVE the device top level patch (even if the window is not flagged dirty) -> This will create a new *.amxd (frozen) and you'll be asked for the location.

now always the version included in the *.amxd will be loaded. To edit the poly patch one needs to open the device again in Max.

The limitation that a device is always frozen an save in Max is on the one and understandable from the point of view of dependency integrity in the combination with Live but is quite argued here already ...

I agree that this process could be probably streamlined better, i.e with an option for "don't freeze on save" to be used during dev-time.

- Open device in Max, (will create the Project if it does not exist)
- edit/save poly subpatch -> will update the file inside the project
- SAVE the device top level patch (even if the window is not flagged dirty) -> This will create a new *.amxd (frozen) and you'll be asked for the location.

I agree that this process could be probably streamlined better, i.e with an option for "don't freeze on save" to be used during dev-time.


That sounds clear and feasible enough. Though saving the poly subpatch consistenly crashes Max...

Does it also crash Max when you edit it outside the device- scope ?

* open the poly patch outside the device, edit, save.

Does it also crash Max when you edit it outside the device- scope ?
If not maybe this hack could work:
* open you device in Max
* open the poly patch outside the device, edit, save.
* reload the poly inside the device.
* save the device.


For this I think I need to give the poly file a new filename for every new edit. Quite inconvenient.

I did test your first method with a pluggo device too and there it doesn't crash upon saving the poly file. Seems to be something specific to Granulator II that makes it crash. Perhaps a certain object used here but not in the other.

you wouldn't need to rename it, you can edit a max patch that loaded as abstraction.

I've been going through this whole ordeal myself, getting my own devices to run from amxd~. Disappointing to hear confirmed that the devices will always be frozen and must be edited in this roundabout way.

So --- really doesn't work to differentiate objects between two different amxd~s? If that's true and I'm going to have to rename a bunch of stuff anyway, it seems there really isn't any advantage using amxd~ over just copying the guts of my devices into sub patchers.

Oh, I misread. --- WILL differentiate objects in different amxd~s after all. It would be strange if it didn't. Still, the amxd~ object seems to be far more trouble than it's worth.

AMXD in Max 7 issues [was: M4L's --- (3 dashes) in Max 7?]