ForestCat

Could someone perhaps explain the following to me...

Create a fresh m4l MIDI device on an empty MIDI track.

With the patcher window open, paste in the following:

I know this patch won't "work". It's not supposed to. DO NOT move/edit any of the max-generated boilerplate, i.e. midiin, comments, etc. You want a pristine Max MIDI device template with my stuff pasted in, wherever it winds up. Don't save anything.

Open the Max output window, start the transport, lock the patch & click the "goto live_set current_song_time" message.

This will start generating a ton of errors, since the syntax is wrong. That's intentional. The point is, although I haven't saved the patch/device to disk, it is definitely "interacting" with live. That's fine.

OK, now unlock the patch & delete ONLY the objects you just pasted in.

On my computer, the stuff I just deleted is still continuing to generate errors, although the "object" column is now empty, and the "show object" arrow is greyed out. WTF???!!!

Now it gets interesting: close the patcher window. If you haven't modified the template, then it WILL NOT ask you to save, since you already deleted what you added, and the template, from the standpoint of Max, hasn't "changed".

On my system, when I close the patcher with the non-existant objects still generating error messages, the error messages stop. If I open the "empty" patcher window again, the error messages start again. WTF???!!!

Here's the best part: With the empty patcher open and the error messages flying, save the max device. On my computer, the error messages stop.

I do understand that there are some distinctions between the device in the track, and the device in the patcher, but this is wildly inconsistent behavior. An object can be instantiated in an open, unsaved patcher, but it can't be destroyed? It only affects certain objects/situations, but there seems no rhyme or reason to it. This is the first small test example I've been able to nail down.

I'm really hoping someone can shed some light on this...

I know this patch won't "work". It's not supposed to. DO NOT move/edit any of the max-generated boilerplate, i.e. midiin, comments, etc.  You want a pristine Max MIDI device template with my stuff pasted in, wherever it winds up. Don't save anything.

This will start generating a ton of errors, since the syntax is wrong.  That's intentional.  The point is, although I haven't saved the patch/device to disk, it is definitely "interacting" with live.  That's fine.

Now it gets interesting: close the patcher window.  If you haven't modified the template, then it WILL NOT ask you to save, since you already deleted what you added, and the template, from the standpoint of Max, hasn't "changed".

On my system, when I close the patcher with the non-existant objects still generating error messages, the error messages stop.  If I open the "empty" patcher window again, the error messages start again.  WTF???!!!

Here's the best part:  With the empty patcher open and the error messages flying, save the max device.  On my computer, the error messages stop.

I do understand that there are some distinctions between the device in the track, and the device in the patcher,  but this is wildly inconsistent behavior.   An object can be instantiated in an open, unsaved patcher, but it can't be destroyed?  It only affects certain objects/situations, but there seems no rhyme or reason to it.  This is the first small test example I've been able to nail down.

I'm really hoping someone can shed some light on this...


deleted-objects-still-exist-in-ram

I've tried to reproduce your test, but still on Max 5. When starting transport and clicking the goto message I get exactly 1 error message saying 'component current_song_time is not an object' which makes perfect sense. So why does it generate a "ton of errors" on Mac 6? I think this needs to be clarified first.

Interesting. I can also confirm that it only generates one error in 8.xx/5.xx. On Live9/Max6, it fills the Max window with that error, if I stop the transport, the errors stop, if I start the transport, they start again, all other behavior as described above. Thanks for weighing in.

Interesting. I can also confirm that it only generates one error in 8.xx/5.xx.  On Live9/Max6, it fills the Max window with that error, if I stop the transport, the errors stop, if I start the transport, they start again, all other behavior as described above.  Thanks for weighing in.


I can confirm the behavior you are reporting. We will take a closer look to determine if there is a bug here.

I can confirm the behavior you are reporting.  We will take a closer look to determine if there is a bug here.

i bet that an opened device has a running ID, which is reused next time you open the same file.

That's a good possibility. But I'm not sure if it explains why deleted Max objects are still "doing their thing" somehow. I've come to the conclusion that Max is a brilliant product in it's own right, Live, well it has it's moments of brilliance, and some aspects that keep a lot of people asking "what were they thinking?" (new browser, case in point...)

But the marriage of Max & Live seems troubled. The most glaring example is this live.path/live.object/deferlow hack, which sometime works on the third quarter of the moon, at high tide, on leap year. Maybe. At bare minimum, it makes debugging a max patch with any API calls patch in an open patcher edit window a practical impossibility, since the behavior of a max "device" in a track, and the same code in an open Max patcher are RADICALLY different in many instances, and there appears to be no way to know when or why to trust an open patcher in the Max for Live environment... One thing for sure, I have many API calls that throw errors in an open patcher that don't when the patcher is closed, and that, frankly, does not inspire confidence as to the robustness of this solution in a live performance scenario with a load of clips, devices, vsti's, etc...

Is it just me, or do 99% of the cool things that Max For Live promises involve "changes to a Live Set and its contents from a notification", which according to the docs, "is not possible". Is it me, or is that the most common expectation that any reasonable person would have when they read through the rich & inviting LOM when considering a solution like Max For Live? Reading that "not possible" part was like the cop with the flashlight knocking on the car window seconds before "liftoff", if you get the analogy...

I do understand why, and I'm sympathetic, but that doesn't help me when almost anything that I ever envisioned doing with Max for Live won't work without this "deferlow" magic smoke that may or may not eliminate the errors. It often feels like I'm waving some chicken parts over incense and chanting, hoping the DeferLow God will be in a good mood...

Not being able to reliably use debugging/watchpoints/breakpoints in the Live environment is a huge disappointment. It is one of the features that sets Max apart from most of its competition, and it's unusability when a patcher has to be closed to work properly makes Max For Live feel a little bit crippled to me...

I don't know if this is ultimately fixable, but if it is, it needs to be at the very top of the heap of bug fixes/features/whatever. By reading through the forum, I can see that I'm not alone in this thinking...

That's a good possibility.  But I'm not sure if it explains why deleted Max objects are still "doing their thing" somehow.  I've come to the conclusion that Max is a brilliant product in it's own right, Live, well it has it's moments of brilliance, and some aspects that keep a lot of people asking "what were they thinking?" (new browser, case in point...)

But the marriage of Max & Live seems troubled.  The most glaring example is this live.path/live.object/deferlow hack, which sometime works on the third quarter of the moon, at high tide, on leap year. Maybe. At bare minimum, it makes debugging a max patch with any API calls patch in an open patcher edit window a practical impossibility, since the behavior of a max "device" in a track, and the same code in an open Max patcher are RADICALLY different in many instances, and there appears to be no way to know when or why to trust an open patcher in the Max for Live environment...  One thing for sure, I have many API calls that throw errors in an open patcher that don't when the patcher is closed, and that, frankly, does not inspire confidence as to the robustness of this solution in a live performance scenario with a load of clips, devices, vsti's, etc...

Is it just me, or do 99% of the cool things that Max For Live promises involve "changes to a Live Set and its contents from a notification", which according to the docs, "is not possible".  Is it me, or is that the most common expectation that any reasonable person would have when they read through the rich & inviting LOM when considering a solution like Max For Live?  Reading that "not possible" part was like the cop with the flashlight knocking on the car window seconds before "liftoff", if you get the analogy...

I do understand why, and I'm sympathetic, but that doesn't help me when almost anything that I ever envisioned doing with Max for Live won't work without this "deferlow" magic smoke that may or may not eliminate the errors.  It often feels like I'm waving some chicken parts over incense and chanting, hoping the DeferLow God will be in a good mood...  

Not being able to reliably use debugging/watchpoints/breakpoints in the Live environment is a huge disappointment.  It is one of the features that sets Max apart from most of its competition, and it's unusability when a patcher has to be closed to work properly makes Max For Live feel a little bit crippled to me...

I don't know if this is ultimately fixable, but if it is, it needs to be at the very top of the heap of bug fixes/features/whatever.  By reading through the forum, I can see that I'm not alone in this thinking...


Completely agree with your thoughts about LOM, and the deferlow voodoo. As a fresh comer to max (2 years, with no programming background) I'm not confident enough with my programming skills to be sure the problems aren't on my side but it happened a few times that the deferlow magic worked.

Have you confirmed that this is a bug, and if so, any idea if/when it will be fixed?

Ben,
       Have you confirmed that this is a bug, and if so, any idea if/when it will be fixed?


We are continuing to take a look at it, but it appears to be a cosmetic issue that won't be cleaned up in the near future.

If you see some practical use problems or performance issues, after removing the bogus patching and saving the device, please do drop a note to support and we will take a look.

We are continuing to take a look at it, but it appears to be a cosmetic issue that won't be cleaned up in the near future.  

Are we talking about the same issue? I'm talking about the fact that the Max output window stops working, that any and all print objects stop working until you turn on debugging mode and bang them manually. The patch I gave you above simply shows you how to elicit the behavior, but it is happening repeatedly to me in many situations, in real-world use. Any number of Live API-related errors trigger this failure. I can't really agree with the conclusion that it is merely cosmetic, it effectively disables the ability to debug max for live, since Live API devices will not work reliably if there are open patcher windows, which is another serious issue that has been reported & confirmed by other users on this forum at least a year ago. The max output window is all we have, other than [message], which is not a substitute for console output. I hope you guys will revisit this & reconsider what/why is happening. I think you could agree that errors/bugs in user source code shouldn't bring down an IDE, which is essentially what seems to be happening here.

       Are we talking about the same issue?  I'm talking about the fact that the Max output window stops working, that any and all print objects stop working until you turn on debugging mode and bang them manually.  The patch I gave you above simply shows you how to elicit the behavior, but it is happening repeatedly to me in many situations, in real-world use.  Any number of Live API-related errors trigger this failure.  I can't really agree with the conclusion that it is merely cosmetic, it effectively disables the ability to debug max for live, since Live API devices will not work reliably if there are open patcher windows, which is another serious issue that has been reported & confirmed by other users on this forum at least a year ago.  The max output window is all we have, other than [message], which is not a substitute for console output.  I hope you guys will revisit this & reconsider what/why is happening. I think you could agree that errors/bugs in user source code shouldn't bring down an IDE, which is essentially what seems to be happening here.


I don't see that the print object is broken, although the Max window is simply overrun with errors. After getting rid of the bogus patching and saving, you should not see any errors. The Max Window and the print object should continue to function throughout. If this is not the case, then we need to get more info from you via an email to Support (support at cycling74 dot com), as that is not what we see here.

Also, when you write, can you describe the "Live API devices will not work reliably if there are open patcher windows" issue with more detail? This is not something I am familiar with. Please include a simple set of steps and a device that we can take a look at.

I don't see that the print object is broken, although the Max window is simply overrun with errors.  After getting rid of the bogus patching and saving, you should not see any errors.  The Max Window and the print object should continue to function throughout.  If this is not the case, then we need to get more info from you via an email to Support (support at cycling74 dot com), as that is not what we see here.

Also, when you write, can you describe the "Live API devices will not work reliably if there are open patcher windows" issue with more detail?  This is not something I am familiar with.  Please include a simple set of steps and a device that we can take a look at.

Deleted Objects Still Exist in RAM?????