pechnatunk

Is there a way to find out or flag any dependancies or externals in a device before sharing it? 

For example I use an object called ddg.mono - it doesn't appear to be an external in Max 7, but that may not have always been the case.

Also is there a way to find what the minimum system requirements would be for a device?

Basically - I have made something small that I have already shared with, and some people have paid, but a couple of people have told me they've had issues, and I'm wondering why it is.

I made the device on a Mac with licensed versions of Live 10 and Max 7, but when opening Max for live devices they open in Live 8, if that makes a difference.

I have definitely frozen my device before sharing, but someone using Live 9.7 with Max for Live on Windows was having issues - and what they described to me makes me think it may be the above ddg.mono object and perhaps I don't have the Windows version of this object on my machine.

Also - I would like to be able to state to people before downloading - what the minimum system requirements are to use the device - OS and Live/Max software versions

Is there a way to find out or flag any dependancies or externals in a device before sharing it? 
For example I use an object called ddg.mono - it doesn't appear to be an external in Max 7, but that may not have always been the case.
Also is there a way to find what the minimum system requirements would be for a device?

Basically - I have made something small that I have already shared with, and some people have paid,  but a couple of people have told me they've had issues, and I'm wondering why it is.
I made the device on a Mac with licensed versions of Live 10 and Max 7, but when opening Max for live devices they open in Live 8, if that makes a difference.

I have definitely frozen my device before sharing, but someone using Live 9.7 with Max for Live on Windows  was having issues - and what they described to me makes me think it may be the above ddg.mono object and perhaps I don't have the Windows version of this object on my machine.

Is there a way to find out or flag any dependancies or externals in a device before sharing it? 
For example I use an object called ddg.mono

test-max4file-compatibility

ddg.mono is a standard Max object as far as I can tell. You'll need to get the users to tell you what errors appear in the max window when trying to use the device if you can't test/reproduce on your system.

OK, Thanks - I'll do that - I just hope it is not my patching that may make the device perform differently on other systems/midi setups.

How about system requirements - are there any resources around to find out on what systems a device would work on?

So I'm on MacOS High Sierra with Live 10 Suite and Max 7...... what would be the typical minimum OS and Live with Max for Live version?

How about system requirements - are there any resources around  to find out on what systems a device would work on?
So I'm on MacOS High Sierra with Live 10 Suite and Max 7......  what would be the typical minimum OS and Live with Max for Live version?
Could someone with Live lite use it? 

A little confused why you're developing for Live 10 with Max 7? Max 8 is bundled with the app now.

As long as you're not using any externals, and avoiding any objects that aren't backward compativle (though if you're using Max 7, this shouldn't be an issue), and you freeze your device, you should feel comfortable saying any OS that can run Live 10, and M4L, would be sufficient.

You should keep a copy of 9 around to test with, if possible. I always try to run my devices in Live 9 periodically to check for compatibility issues.

A little confused why you're developing for Live 10 with Max 7? Max 8 is bundled with the app now. 

Ah! OK - so yes I did use Max 8 then. Only the very early stages were in Max 7 - then the rest I just built inside Live 10 - I just haven't bought Max 8 yet. (I just typed mc into Max 8 to test it's functionality) :)

Thanks for the tip - I'll re-download Live 9.

Ah! OK - so yes I did use Max 8 then. Only the very early stages were in Max 7 - then the rest I just built inside Live 10 - I just haven't bought Max 8 yet.  (I just typed mc into Max 8 to test it's functionality)  :)
Thanks for the tip - I'll re-download Live 9.

Thanks - sure enough my patch is completely broken in Live 9.

And it is really hard to debug too - because it behaves very differently when in patching view. 

I've just loaded the default Max Midi effect into a track and there is a significant delay to midi passing through it when in patching view compared to when closed. I think this is the cause of my first hurdle.

Also when opening a patch, in Live 9 they default to editing mode - is this normal?

And it is really hard to debug too - because it behaves very differently when in patching view. 
I've just loaded the default Max Midi effect into a track and there is a significant delay to midi passing through it when in patching view compared to when closed.  I think this is the cause of my first hurdle.

Yeah, there is always a delay when passing MIDI in/out, and also accessing some things from the API when editing, no way around that. 

As for opening in Edit mode, I would suspect that has something to do with the patcher properties.

Yeah, there is always a delay when passing MIDI in/out, and also accessing some things from the API when editing, no way around that. 
As for opening in Edit mode, I would suspect that has something to do with the patcher properties. 

You don't happen to know what pressing STOP in Ableton does to midi in a M4L patch?

Max console shows exactly the same data being sent to the midiout of the device in both Live 10 and Live 9. Except in Live 9 only the first note is audible - after that there is no sound - but I believe the midi is being sent as pitches are changing, it seems like just the note ons get lost - for some reason pressing the STOP button in Ableton resets this and the first note can be heard again.

Also - what is really weird now - is that when I open the device in Max 10 it works 100%, but it not only stops working when I open the patch, after closing - even if no changes were made - the device continues to not work and it has to be reloaded into the track....

OK cheers. 
You don't happen to know what pressing STOP in Ableton does to midi in a M4L patch?
As this might help me troubleshoot.

Max console shows exactly the same data being sent to the midiout of the device in both Live 10 and Live 9.   Except in Live 9 only the first note  is audible - after that there is no sound - but I believe the midi is being sent as pitches are changing, it seems like just the note ons get lost -  for some reason pressing the STOP button in Ableton resets this and the first note can be heard again.

Its really hard for me to say anything without seeing the patch at this point. To me it sounds like there's some incomplete MIDI Data being sent that is confusing Live. Not matching note on/off pairs or something.

Well that is exactly right! however for my purposes I did not need note on off pairs, as it was for a hardware drum machine that did not respond to them - so I stripped all note offs.

I used the MIDIMONITOR patch that comes with the Max4Live essentials - it showed that actually every time you press the STOP button in Live it sends out - "123 0" , which is the stop all notes CC.

My band-aid fix for Live 9 users of my device was to simply trigger this CC after each note is sent...

But - the thing I think I've found, is the difference between Live 9 and 10, or Max 7 and 8 maybe.

It is as if Live 10/Max 8 generates the note offs for me, to correct the MIDI, as I can see them in the MidiMonitor, but I am sure that I have stripped them all off in the patch.

I'm typing this from memory - so cannot double check or share the patch right now.

But I did learn from this that I should cross check in Live 9 as I go, instead of at the end - as it appears that I would need to rebuild this from scratch rather than debug.

:) haha
Well that is exactly right! however for my purposes I did not need note on off pairs, as it was for a hardware drum machine that did not respond to them - so I stripped all note offs.
I used the MIDIMONITOR patch that comes with the Max4Live essentials - it showed that actually every time you press the STOP button in Live it sends out - "123  0" , which is the stop all notes CC.
My band-aid fix for Live 9 users of my device was to simply trigger this CC after each note is sent...

But - the thing I think I've found,  is the difference between Live 9 and 10, or Max 7 and 8 maybe.

It is as if Live 10/Max 8  generates the note offs for me, to correct the MIDI,  as I can see them in the MidiMonitor, but I am sure that I have stripped them all off in the patch.
I'm  typing this from memory - so cannot double check or share the patch right now.
But I did learn from this that I should cross check in Live 9 as I go, instead of at the end - as it appears that I would need to rebuild this from scratch rather than debug.

Test Max4File compatibility