Max 8.1 Released


    Sep 25 2019 | 5:04 pm
    We are pleased to announce the release of Max 8.1. This update brings initial Mac OS 10.15 Catalina support and "darkmode" window toolbars on Mac. We've also decided to include jit.mo in the distribution as a "factory" package (it has a few improvements as well). Additionally, the Inspector has been improved to have a "per-object" view (among other things). Be sure to take a look at the change log below for the complete details of improvements in this release.
    All of this is just a download away: https://www.cycling74.com/downloads
    Happy patching, Ben & Cycling '74
    New Features: • Inspector: save, restore view, disclosure, filter etc on a per-object basis and other improvements • jit.gl.graph: matrixoutput support • jit.mo: added to the standard Max distribution • live.comment: new object - text color follows live interface colors • MC: initialbusystate attribute to set the default busy state to zero to avoid high CPU usage • pattrstorage: added filter bar to client and storage windows • Themes: allow loading from Packages (interfaces/themes) • thispatcher: can get path of .amxd • vst~: valuemode attribute to set output format
    Fixed Bugs: • Audio Settings: Fixed crash with mismatched sample rates • Autocomplete: holding down arrow key works as expected • Database: fixed crash when harvesting a patcher missing a 'box' dictionary • Debugging: Window properly drawn at all sizes • dict.view: fixed issues and possible crashing with dictionary display • expr: random no longer produces an offset of -1 (Win) • Fonts: “light” and “italic” fonts fall back and render properly (Windows) • groove~: plays back without artifacts when sample rates do not match • jit.gl.render: high-res rendering enabled if enabled on app (via open in low resolution checkbox) • js: fixed logic of multi-line posts • jweb: fixed drop position with drag and drop from jweb to Max patcher • jweb: fixed flashing when deleting jweb (Win) • jweb: works in Max for Live • kslider: range no longer resizes object on reopen • live.banks window: fixes and improvements • live.drop: fixed issues with recalling large files • live.text: fixed crash with changing picture attributes • Mac OS: 10.15 Catalina Support • Mappings: all entries properly shown in window • Mappings: fixed issues with removing entries • Max Console: fixed crash after an object that posts is deleted • Max for Live Device: border color follows Live theme • Max for Live phasor~: @lock 1 does not degrade • Max for Live: fixed crash when editing a device while a large number of files are open • Max for Live: fixed errors with floating point arguments like in sprintf • MC amxd~/vst~: fixed issues transforming to multichannel versions • MC: objects in a subpatch can be muted • mc.selector~: wrapper no longer converts int to float • opened object: works at app launch • Packages: max.db.json respects exclusions (Win) • Parameter window: fixes and improvements • Parameters: fixed crash when automating a parameter via another parameter • Patching: patch rendering improvements • pattrstorage: client window updates interp column when default_interp is set on client pattr • pattrstorage: corrected cell colors • pattrstorage: fixed crash when double-loading a file • playlist~/jit.playlist: loop button always appears • poke~: protect against zero sized buffers • poly~ / thispoly~ outputs voices in correct order • print: no longer adds a space before list messages • Templates: "New from Template" no longer triggers duplicate loadbang, loadmess, and js post • text object: entering cr works as expected • textedit / pattrstorage: recalls properly • textedit: set message is synchronous • vst~: eliminate double output of some parameter values • vst~: fixed crash after plug_vst followed by params message • vst~: fixed setting attributes in object box • vst~: parameter names correctly reported with Reaktor plug • vst~: state restored when plugin name differs from plugin display name

    • Sep 25 2019 | 7:26 pm
      This is great!
    • Sep 25 2019 | 8:44 pm
      Same here!
    • Sep 25 2019 | 9:13 pm
      Thanks Max Santa!
    • Sep 25 2019 | 11:13 pm
      Despite reporting this in 8.0.6, and following up with this on release 8.0.8, there is still garbled font showing on comments using Lato font, and tooltips in various parts of the platform. There seems to be only one improvement visible - the reference tab finally displays text properly. I'm beginning to feel very discouraged by this - font is garbled across so many of my patches, where in previous releases of 8 everything worked fine.
    • Sep 26 2019 | 9:27 am
      @MUSIC_SDP Mentioned in a couple of days ago on the 8.0.8 thread but that'd now been buried: I had exactly the same issue, but have found a fix :) I deleted all of the Lato fonts from my Windows/Fonts folder (right click on them and click delete) and re-downloaded them from here - http://www.latofonts.com/lato-free-fonts/   (click the Down­load TTF button). Installed them and am now back in business with no corrupt tool tips etc!
    • Sep 26 2019 | 6:33 pm
      Thanks a lot Ben, and C74 for this 8.1
    • Sep 26 2019 | 7:46 pm
      @MCBPETE, thank you very much for sharing this fix. It did, in fact work, but I still feel troubled by the problem.
      The issue only occurs as far back as 8.0.6, and if I revert to the previous versions, Lato works fine. I would love to know what happened in the meantime, as I distribute an application, and I want to know what my users should expect.
      I think it's going to be a little rocky for my Windows user base, as they may need to replicate what I did. Asking users to follow additional steps frustrates me, and you'd be surprised how something as simple as that can keep users from coming to a platform. I would much rather see a Max bug fixed, than ask my user base to manually implement a workaround.
    • Sep 26 2019 | 8:20 pm
      @MUSIC_SDP I believe the problem relates to having a bad/different version of Lato on the machine, though as we have been unable to reproduce in-house, it is pure speculation. I'd be curious if Lato worked in other applications, and if our other embedded fonts worked (f.e. Ableton Sans), given the old condition of your system.
      You and the other poster on this thread are the only reports of this that we've come across, so it appears to require a very specific set of conditions that are not widespread.
      In the future, we can look into the possibility of prioritizing our "embedded" Lato font over any that are on the system, which seems like a good idea, regardless of if it relates to your problem.
    • Sep 26 2019 | 8:26 pm
      @JULIEN BAYLE Yes, I believe this has been fixed; jit.world should pull in the appropriate dependencies when building a standalone.
    • Sep 26 2019 | 8:59 pm
      I also have garbled font in help window, context sensitive help, and other places as reported by other users, open both Windows and MacOS. It may have been due to installing Ableton Live 10 before installing a new version of Max 8, and it started with v8.06. This problem has reappeared and been fixed at least twice before since v6. If I may venture a suggestion, using a font other than Lato in the next release may be a better option.
      Last week, Cycling74 has kindly filed bugs in their database on the following issues: * umenu and live.menu: changing window zoom does not change font size inside opened menu. * chooser: font size stays the same when changing window zoom. When increasing zoom, a dotted line appears at the old chooser object width and text is truncated to it. * plot~: documentation states buffer~ channel and offset can be set for each inlet, but it always displays only channel 1. * gen/gen~ : compiler does not catch undeclared variables inside conditional statements until condition is exercised. It appears to compile, but in some cases, the code is not compiled at all. In other cases, if the gen editing window is closed at the time the undefined value is reached, Max can crash inexplicably. Any edits after adding the undeclared variable will be lost without error reporting. In some cases, the codebox will be entirely empty. Example, outputs 0 instead of 1:
      * gen/gen~: variables in the main routine, or lower in a sequence of function calls, inherit the value of variables with the same name in called functions, as if all variables are global; but not vice versa, as if variables are not global. Example, outputs 2 for p1 instead of 0:

      STANDALONES

      Writing files. As of at least two weeks ago, it is no longer possible to write files from Max standalones in macOS Mojave and later. Apple has added a new requirement that the computer administrator must approve apps trying to write files (as of this week, this is stated on the main Catalina feature page). But in Max standalone, no window appears asking for admin username and password, and silent saves fail without notice. Additionally, as the user is not prompted for approval, it is no longer possible to save app state on exit via the 'freebang' object. Previously, pattrstorage save failures, and file dialog save failures, were reported with a '-1' flag. Failed saves in MacOS standalone now generate a '0' flag. On JUCE C++ forums it was suggested that the app save to a 'preferred secure location' about six months ago, and users there have had success with that approach, which moreover assures backup on iDrive (previously iCloud). However, there is no way to safely determine a secure file location with the current available paths in Mac standalones.
      Sharing a Standalone to Mac Users. To share a standalone for Mojave and later, you must now pay $100/year and download certificates as described in video https://cycling74.com/forums/advanced-max-standalones-part-5. However the terminal/script commands, required for Apple codesign and notarization of standalone, require different options than before.
      1. For codesign, you must now also specify --deep (not -d) and depending on your inclusions, you may also need to specify the -v option (which is meant to be only verbose output, but the verbose option also now triggers timestamp validation, which is also now required; and at least four more levels of certificate stripping and replacement).
      2. Notarization is now required, not just codesign, even if app is not distributed on Mac App Store, for any new user. If you were a notarized Apple developer before Mojave, you may be able to skip notarization for independent standalone distributions. But now notarization is required for apps from newly registered developers. Do not lose your Apple ID! It is possible to complete the first step of notarizing a c74 standalone if it is placed in a zip file.
      3. Hardened runtimes cannot be built.
      4. The second step of notarization, stapling, corrupts the Max binaries.
      5. After its expiration In 12 months, additional steps to update the certificate might be required.
      6. After successful codesign and notarization, the app will still be rejected by MacOS versions earlier than Mojave.
      Currently one can share an app outside the App Store with codesign and notarization by skipping the stapling step. However it is now impossible to make a standalone for the Mac App Store, or to make standalones that can write files. Your QA kindly added this is as a feature request for an example which works, yesterday.
      There are still about 60 missing files from the Windows10 standalone, and some other minor issues I could report, but I had already added scripts and redesigned my app to fix the other issues. So I am waiting for a working standalone example that can write files on Catalina before providing further feedback or updating the application.
    • Sep 26 2019 | 9:41 pm
      yes the jit.world standalone thing should be fixed. please let us know if not.
    • Sep 26 2019 | 10:01 pm
      @ Ben Bracken thanks for the insight into the issue, it helps to have someone from C74 finally address this concern.
      For the record, this is happening on other systems. I have had reports from five of my users that the Lato text is garbled, and it has been frustrating that I haven't been able to help them. I'm sure there are others who have not filed a report with me. I will try including new Lato font files in my distribution, and at least now I know how they can manually fix the problem. I do hope that this is an issue that can be addressed at some point in an update.
    • Sep 26 2019 | 10:07 pm
      If anyone does have these Lato issues, we'd love to get you into Support, see what versions of Lato are on the machine, and try some other debugging.
    • Sep 26 2019 | 10:15 pm
      @ Ben Bracken Yes, please! I would very much appreciate that and I would be glad to help in any way that I can. I've reported this previously and have been told to wait for a future fix, which is why I only mention the problem when an update comes out. It is always my pleasure to take an active role in troubleshooting, and I would be happy to provide any useful information.
    • Sep 26 2019 | 10:23 pm
      Thank you for the offer. Im glad to help with troubleshooting later, if you want me to try a beta. But I've been doing nothing but trying to figure out Max bugs for six weeks so far this year, so If you'll excuse me, I need a break from Max until I can be assured of a working Catalina standalone for the Mac App Store which can write external files by way of working example.
    • Sep 27 2019 | 10:42 am
      Thank you, Ernest for your in-depth report of the the standalone issues. Can I just add my voice to the call for the Mac standalone issues to receive some serious attention now?
      I appreciate that Apple seem to shift the goalposts with tiresome regularity, but it's been some time now since sharing a standalone on MacOS has been anything like straightforward, so I'm sure I'm not alone in hoping that Cycling 74 will now be giving this a really good looking at. TIA
    • Sep 27 2019 | 3:58 pm
      thanks @ ERNEST
    • Sep 29 2019 | 12:37 pm
      I did have a final goodbye spin on Max 8.1 today, here are last things:
      * javascript: Dict object still not available in windows standalone (reported to C74 2 years ago). * javascript: Buffer object still cannot do batch reads or writes in Windows standalone (reported to C74 2 years ago). * buffer~ and Data: accessing buffer~ data and Data structures in gen~is faster when inside a conditional test of codebox, for some reason, but still slower than two transcendental calculations. Not possible to read or write more than one value at a time (no batch read or write). * poly~: impossible to use >50% of available cpu on MacOS. poly~ does spread processing across cores, but on MacOS the reported Cpu metering reaches 100% when CPU is equivalent to one core no matter how many cores in system, after which audio or video starts to stutter, and, CPU metering still does not take turbo into account (reported to C74 by multiple users 8 years ago). MC cannot run on >1 thread unless inside poly~. Putting MC inside poly~ is lower performance than using just poly~ as it was.
      Im sad to say the last item is a bit of end of line for me on Cycling74 for now. I may be back when I have something working in C++ to share something built in the SDK. I have greatly enjoyed working with all you folks and do wish you all well.
    • Sep 29 2019 | 5:46 pm
      @ ERNEST
      Unfortunately, the same thing happened to me, after a subscription I bought the license (I live in a difficult country) so that in a few months I would announce the next version and put the "cut" arbitrarily beyond my purchase, for me that was a commercial move, but personally I felt very unfair.
      Anyway I was already angry with the change of license in gen, which for me means one of the most unpleasant milestones, within the attitudes of software companies.
      All this having been insulted in my condition as a woman in some cases by fanatical users who incredibly put themselves on the side of the company (if that is ethics on these sides).
      I also made the point that before moving from a version at least the company had to correct errors that would affect the functionality of the version they plan to leave behind (without support), instead of doing this the answer that I felt somewhat cynical, was the announcement that an error that had been there for twenty years was finally corrected in version 8.
      With this software, I do educational projects to apply in education in slums and poor areas, this year I seriously thought of acquiring the license of Max 8 to leave behind things that do not work and will never be fixed in Max 7, but I could not leave the incident of the license and the whole issue of aggression and detraction by the institution.
      I respect your effort, and I respect some users of this community, many of them in fact no longer post so much.
      For some time I managed to replicate what I did and needed from Max and Pd in ​​C ++ with a little decision, happy then, the path of freedom always implies growth and is opposite to comfort and dependence.
      People cannot be harmed on the grounds that they do not have resources and it is a small business (which I understand after the purchase by Ableton is no longer true) ...
    • Sep 30 2019 | 7:11 am
      @Ben Bracken - I wrote to support about this Lato problem, but was told this : "Max 8 is only supported on OS X 10.11.6 or later. The font issues you're seeing are probably the results of using an unsupported OS. My first suggestion is to update the OS and see if the problem persists."
      Not exactly the kind of answer I expected…
    • Sep 30 2019 | 1:23 pm
      Intriguing - So the Lato issue isn't just restricted to Windows 10 users like myself then?
    • Sep 30 2019 | 2:27 pm
      Just my 2 cents. I'm using Max since the beginning, or almost. I used it for sound (analysis, synthesis, acoustic research, visuals, database contexts, connected or standalone, vst design, shader design, all in live performance context or installations, file processing and more and I never had found any blocking things. Maybe I just have been very lucky, maybe everything just worked because it is well done. Support always helped me a lot and especially on this forum, and I'm not paid at all for writing this.
    • Sep 30 2019 | 2:38 pm
      I agree with Julien, C74 has always been very nice to me too. I don't think being bought by Ableton Live means it is 'no longer a small company.' It means it has a group on the other side of the world deciding its priorities, in particular, being able to build standalones or plugins for other DAWs is just not in Ableton's interest, so Im not surprised I am having problems, and realistically, the situation is not going to change much.
    • Oct 01 2019 | 6:14 pm
      We have just published a short article on Max 8.1 Mac 10.15 Catalina support and notarization issues that hopefully clarifies some things: https://cycling74.com/articles/max-8-1-mac-os-10-15-catalina-support-and-notarization
      I've attempted to collect the issues raised on this thread with some answers below: Writing files from a Mac standalone: In our tests, as long as the appropriate entitlements are used during signing/notarization, writing files from a Max standalone works, anywhere that the user has permission to write to. If you have an example of when it doesn't, please drop Support a note with it.
      Notarization flags: Ernest's observations about needing to use '--deep' instead of '-d' appear to be correct. FWIW, we have not needed to use the '-v' flag during notarization. The '--timestamp' flag is not currently mandatory, but it appears it is planned to be in January 2020.
      Building a "Hardened Runtime" Standalone: There is no need to build a "hardened runtime" as the Max Runtime included in a Max standalone was built with this enabled, similar to the full Max application itself.
      Issues with Stapling: We are unaware of any corruption during stapling. Perhaps the standalone wasn't notarized fully in the first place? Are you using an '.entitlements' file to set the exceptions for your app?
      Earlier MacOS support for Standalones: Standalones that have been code-signed/notarized with the new system appear to work on all supported OSes (10.11.6+). We would need an example of it not working in order to investigate further.
      Missing Files for Windows Standalones: Without seeing a standalone, it would be hard to know, but it may be that you need to include the C74 Resources and Database support. If that is not included, perhaps you need to explicitly add specific dependencies? It sounds like Ernest may have worked this out with some custom scripts moving specific dependencies over.
      Dictionaries in Standalones: The dict object (and general dictionary usage) appear to be fully functional in standalone applications. Perhaps, as above, the database and/or other C74 resources need to be included to perform a specific activity? We are happy to investigate further if things do not work as advertised, just follow up in Support.
      Lato font "garbling" issues: As mentioned previously, we believe that this is due to a system that has multiple/conflicting versions of a font present on the machine, causing measurement issues for font rendering. If you have this problem, the immediate fix is to remove Lato from your machine completely, then reinstall the latest version (if needed elsewhere). If you have font issues on a supported Mac OS (10.11.6+), we'd be keen to hear about it. In any case, we are looking into how we choose which version of a font is used and this behavior will hopefully be improved in a future update.
      poly~ CPU usage: In order to get full CPU/Core usage, set the poly~ object's @parallel attribute to '1'. Regarding MC, it does not currently support parallel processing on its own, but when used within poly~ @parallel 1, each top level patch has the option of dispatching to multiple cores. The MC system is not presented as a performance improvement over poly~, but as a different functional workflow for more fluid development working with many audio signals. I believe the other issues raised have been previously reported and ticketed. If you have additional bug reports, please follow up directly with Support so we can ensure it is investigated and tracked.
      Thanks everyone!
    • Oct 01 2019 | 8:15 pm
      About the company side of things, I hope C74 keeps his decisions power. (and as I'm an ableton certified trainer, some will think it is not politically correct to write this but I'm free)
    • Oct 01 2019 | 10:55 pm
      thanks for writing a full reply.
      Regarding the multithreaded performance, when PARALLEL has already been set to 1, the problem still occurs. It doesn't matter if the THREADCOUNT attribute has no or inconsistent effects. It seems THREADCOUNT should just be deprecated currently. Whatever the state of the PARALLEL attribute. It's still not possible to use >50% of the available CPU on an i5. When the cpu meter reaches 100%, which is measured for one core without taking burst mode into account, regardless whether Max is set to limit cpu or not, the audio starts stuttering, and it doesn't matter what the PARALLEL attribute is, or how many more cores there are in the system. While I understand this could be an OS issue, rather than a C74 issue, it remains a problem for C74, because, as long as there is no accurate CPU usage reporting, it will never be possible to add parallel processing inside Ableton Live either, which is why I mention it at all after so long. Maybe we are all so used to seeing MacOS report 167% of the CPU is being used, we stopped thinking it might be an obstacle to future progress. These issues have been true at least since 2007, and maybe some things have been true so long, people started just taking them for granted, but that's how it's been for at least 12 years, and now its going to be a problem for C74 moving forward.
      And regarding all such issues, the story goes like this. When we say somethings, we are asked to send support an example. But for standalones, we have no example from C74 as a starting point. So now I have to turn the tables and again ask C74 for an example of how we are meant to make standalones with auto restore, and a pattrstorage object that reads files on open, saves user data on app exit, and which work consistently in patches, windows standalones, and Macs standalones, and it would be nice if it worked in M4L too. If it is true that it is merely a problem with permissions, there is no logical reason why the patch just modify itself, which really would make things much simpler for us. Of course I doubt that is such a simple solution.
      Whatever be the answer to that, I don't believe a working example of a patch which does have auto restore and a transparent save of preset changes in standalone and M4L is an unreasonable request either. It has ALSO been an ongoing request for users since 2007. C74 first reponded by adding a 'project' feature which moves files around and thus makes it even more difficult to save files. So we stumbled along doing everything for ourselves a new way, without any working example, and discovered really the project file doesn't do anything new at all. So first users shared ways for windows7 and macOs prior to High Sierra. Then users shared how to do it on High Sierra. Now the way which worked on High Sierra doesn't work as before.
      I just reached the end of my patience on this problem. I don't understand this thing about missing Windows10 files being a problem for the user to solve because it depends what objects are in the patch. That was meant to be the problem which C74 said it was solving in the first place with its build system a long time ago. Also, the Windows64 build is now as large as the Mac build, I typically get 125MB builds for my apps, which do need C74 resources and gen, but what confuses me is, the Windows build is now 80MB larger than it used to be, but we are still being told to add files manually, and if we object to the file size, prune files out manually too? Isn't that what the build system is meant to do automatically??? Do you have any idea how many people have said exactly the same thing in the past???? It is easily in the dozens, maybe even a hundred times, Ive seen this same statement in the forums, then sometimes the options change, and the build gets smaller for a while...then it gets bigger again and the same things come around again...how many more times will people go through this loop again????? As there is an automated build system, why are we going through it at all??????
      That's why I have lost patience. Basically, I don't believe it should be the customer responsibility to figure out new solutions every time a new Max version is paid for, that's all. When we purchase new Max upgrades, we kind of think we are paying for these kind of things to be fixed so we can enjoy the new features. I don't believe that is an unreasonable expectation. The reason I am out of patience is that there is another tier of standalone issues we'd like to get to, like being able to remove 'overdrive' from the menu, or being able to write makefiles, or being able to get accurate window coordinates (that was fixed once, but since the new sliding toolbar thingies were added, I have to measure them manually with another application again). It's pointless even thinking such things could get resolved, because we are still going around in circles on many exact same bigger issues which have been going on for at least a decade now.
    • Oct 01 2019 | 11:57 pm
      Anyway, regarding the js Dict object, I am very happy to find the sequencer data in the 'big three' M4L Ableton Live Pak is working again. I have no idea why it wasn't for several years, and I had thought it was the js Dict object, but whatever the reason, thank you very much for fixing it, and I look forward to playing with it very much.
    • Oct 03 2019 | 2:09 pm
      Max 8.1 crashes on my MacBook Pro (Retina, 15-inch, Mid 2015) with patches using VST plug-ins like dearVR Pro or Sennheiser AMBEO Orbit. This didn't happen with the previous version 8.0.8.
      Any clues?
      "osversion" : "Mac OS X Version 10.12.6 (Build 16G2128) x86_64", "samplerate" : 44100, "iovs" : 128, "sigvs" : 32, "scheduler_in_audio_interrupt" : "off", "audio_drivername" : "Core Audio",
    • Oct 03 2019 | 3:46 pm
      Karlheinz, I'm sure support would be glad to have a look at a crash report. I think you can get one from the Console app -> User Reports.
    • Oct 04 2019 | 12:27 pm
      I had the Lato font garbling issue too, and I'm reasonably sure that I had previously installed a version of Lato downloaded from Google Fonts.
    • Oct 07 2019 | 8:17 am
      About Lato… on my now unsupported system (OSX.9) the only Lato fonts I could find (system wide and user) was the one into Max' package. I tried to remove them and install the latest version in the system, cleared the font cache, but this didn't help.
    • Oct 14 2019 | 1:39 pm
      8.1 Standalone crash in asio new version.
    • Oct 19 2019 | 10:11 pm
      Max 8.1 is crashing my 2014 MacBook Pro Retina Mojave 10.14.6