Behaviour absolutepath . changed
Sep 14 2021 | 7:37 am
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.
- Sep 14 2021 | 4:05 pmCan you send along a simple device which shows this problem? You can read our bug reporting guidelines here. Thanks!
- Sep 14 2021 | 5:46 pm
- 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.
- Sep 14 2021 | 7:47 pm@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.
- Sep 14 2021 | 9:23 pmIt 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:
- Sep 15 2021 | 7:38 amI understand. 'path' message to 'thispatcher' is working here. So, bug can be closed.
- Sep 15 2021 | 2:53 pmWe'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.
