Behaviour absolutepath . changed
On Windows 10 here. Before 8.2 'absolutepath .' gave me the directory of where my M4L device is living to store files at runtime in some subdirs . Now it returns 'notfound'. M4L device is broken now.
Can you send along a simple device which shows this problem? You can read our bug reporting guidelines here. Thanks!
Summary:
autopath . not returning fullpath of the directory where M4L amxd file is.Steps to Reproduce:
Send "." message to absolutepath object. Capture output of absolutepath in message or variable.Expected Results:
Output of absolutepath should be the full path to the AMXD file lives. Worked in 8.1. like this: "D:/Ableton/User Library/Max for Live/MIDI Effects/Favorite MIDI Presets/"Actual Results:
Returns a standard M4L directory, "C:/Program Files/Cycling '74/Max 8/resources/tours/max_8_tour"Regression:
Windows 10. No other special constraints.Notes:
Sample patch provided.
@ANDREAS Thanks for the info. I had to make an amxd~ from this patcher in order to repro, but I can now and we will look into it.
It should be noted that the output from sending a dot to absolute path is probably unreliable, and you may want to use something like the 'path' message to [thispatcher] instead:
I understand. 'path' message to 'thispatcher' is working here. So, bug can be closed.
We've actually fixed the bug for the next beta since this pointed out an important regression in behavior, but generally relying on '.' to print out the default path is prone to any other operation modifying the default path. Usually during patcher loadbang it will be the case, but there are circumstances where that could also be broken by other operations, and certainly after patcher load completes.