Max 6.1.4 Released

    Oct 16 2013 | 9:26 pm
    We are happy to announce the release of Max 6.1.4.
    You can download it here:
    Please see the list of new features and fixed bugs below.
    Enjoy! -Ben
    New Features: • join: argument usage for @triggers • plot~: added 'definexorigin' and 'defineyorigin' messages to set the plot origin using max messages • plot~: grid color is definable
    Fixed Bugs: • 2d.wave~: no longer crashes when the buffer is empty • bpatcher: audio works in embedded bpatcher • buddy: no longer corrupts memory with big lists • buffer~: read/import and offset argument fixes for x64 • buffer~: fixed import .mp3 crash on Win • buffer~: write 32bit wave no longer produces files with bad values • buffer~: fixed write format/samptype issues • coll: fixes for closing a dirtied text editor window • colorpanel: interaction improvements • debugging: opens subpatchers and reveals send/receive pairs • dict: fixed crash when setting subdictionary values in M4L • dict: fixed problems saving dict data as param in MFL • dict: improvements to 'set' message to dict when there are many dict instances • dict: setting a subdictionary triggers notifications • Gen: improvements to variable aliasing • info~: no longer reports erroneous information • javascript: fixed crash when setting a attr • changing drawto of gl.cornerpin to a gl.node no longer posts error message • index matrix and autonormals improvements • memory use improvements • jit.gen: fixed SWIZ 0 1 and SWIZ 2 error • @args work as expected • fixed errors with vbo mode • fixed matrix parameters bug • precision attribute is easier to set from an inspector/attrui • jit.qt.grab: no longer crashes when there's no available devices • JS: file creation fixes • jsfolder: no longer corrupts memory with very long file names • jssqlite: no longer crashes on open with incorrect arguments • live.arrows: no longer grows when activating the same arrows • live.grid: no longer corrupt memory in matrix mode • live.text: easier to resizes when in button mode • live.toggle: in right category in object browser • Max for Live: help audio works in unauthorised Max • packages: update searchpaths and menus when packages are added/removed while Max is running • patcher toolbar: tooltips show in correct location when patcher is narrow • pattr: can set @type attr • play~: fixed issues with playing back long sound files • polybuffer~: reports correct buffer~ information • projects: paths are correct when updating dependencies for dicts • standalone: unchecking usesearchpath attribute works as expected • tab/ drawing improvements for when in multiple views • table: respects load/normal historic mode • translate: no longer crashes on close • udpreceive: no longer crashes when packets are dropped • uzi: fixed threading problems • waveform~: redraws properly when the size of the buffer~ increase • Windows OpenGL: improvements for some ATI cards • zl.dequeue: properly dequeue with recursion • zplane~: no longer crashes with unsupported order

    • Oct 17 2013 | 11:17 am
      thanks for the fixes ! especially 2d.wave~ and buffer~ realted ! had trouble opening some old patchers recently, this comes right on the topic !
    • Oct 17 2013 | 12:31 pm
      i have to make a request : could it be possible to be able precising a different repertory of destination than "Max 6.1" ? for numerous reasons, i had to rename my "Max 6.1" folder into "Max6" ; as a consequence the first time i tried to install this update it created a whole new "Max 6.1" folder. Now i just renamed my "Max6" folder temporarily for the update into "Max 6.1", which seems to have worked as expected ; though if i was given the possibility of choosing myself a Max folder in which to install the update, it would really be much more convenient.
    • Oct 17 2013 | 1:23 pm
      Despite bug report forms filled (twice, without receiving any confirmation from c74), and a post on this forum, there are still problems with buffer~'s number of channels. After so many monthes waiting, I will probably need to build a workaround...
    • Oct 17 2013 | 3:30 pm
      ah, that's true, those adressed bugs haven't been fixed
    • Oct 17 2013 | 3:43 pm
      Hi Patrick,
      At this point, the current behavior is the way that buffer~ is expected to work with regards to replace and # of channels. To change a buffer's number of channels, you will need to use the 'channel' argument (the third arg) of the 'read/replace' messages, so something like 'replace drumLoop.aif 0 -1 1' to read in one channel.
      We were having some difficulty with the Bug Reporting Form a while back, so if you didn't get a response, it wasn't because we were ignoring you! Feel free to try again or send an email directly to support at cycling 74 dot com.
      Thanks, -Ben
    • Oct 18 2013 | 3:21 am
      A few months ago i have reported a very serious bug of pattrstorage(max6). RAM memory is constantly increasing when interpolating between presets of pattrstorage (until max crash)! This is more obvious if you have a large number of parameters inside your patch. RAM memory is released only when you close max. Because of this i use max5 on my last projects. Please Cycling fix this bug. Pattrstorage is dangerous! (windows 7, intel i3 2.5 GHz, 4GB RAM)
    • Oct 18 2013 | 11:15 am
      hi Ben, is it the intended behaviour now that buffer~ doesn't load a soundfile which has no extension ?
    • Oct 18 2013 | 1:23 pm
      I really wonder what's the benefit of such a weird (and silent) decision. From a user point of view, I can't see any. So now you always first have to use sfinfo~ if you need to know the number of channels, like in the included patch?
      I also wonder what "automatic duration and channel resizing" in the reference does mean...
    • Oct 22 2013 | 1:43 pm
      There is a strange behavior of waveform~ object after new update was installed. I have a bpatcher and there is a subpatcher, which opens as a window with two waveforms~ in it. After loading a patch and selecting a sample it plays properly but waveform~ doesn't reflect any changes instead it just shows an initialized buffer window with no waveform in it. Sometimes it happens sometimes not.
      I'm posting this here and not in the bug reporting form because I can't reproduce this behavior. I repeat sometimes it happens sometimes not..
      I wish someone can confirm this or you guys at Cycling 74 can check this.
      My system is Max 6.1.4 (32-Bit also happens in 64-Bit), Windows 7 64-Bit
    • Oct 25 2013 | 11:00 pm
      Vichug, re: buffer~ not reading sound files without extensions, I can't reproduce here, though I can recommend to not use files that don't have file extensions. If you have a simple example, please drop a note to support and we will be happy to take a look.
      Ruslan: re: waveform~, I believe this should be fixed in Max 6.1.5, but do drop a note to support with an example so we can make sure.
    • Oct 31 2013 | 4:26 pm
      "A few months ago i have reported a very serious bug of pattrstorage(max6). RAM memory is constantly increasing when interpolating between presets of pattrstorage (until max crash)! This is more obvious if you have a large number of parameters inside your patch. RAM memory is released only when you close max."
      Is that the case? When testing the patch posted by TADA and watching my Ram-Status, i also see increasing used ram on my computer (OS X 10.8)...
      I plan to make heavy use of pattrstorage interpolation for a long-running videoinstallation early 2014, if there would be a serious problem i would need to figure out a plan b... please sb from cycling with a small feedback ...
    • Oct 31 2013 | 4:32 pm
      Hi Tobias. Yes, this is still an open bug.
    • Nov 04 2013 | 5:43 pm
      I am having trouble playing a recorded .aif file in which I recorded using my mic and uploaded it to a [play~] object. The only way I can play the sound is to set the speed in increments of 3. The forum post with more information and test files can be found here
      Is this an open bug?
    • Dec 17 2013 | 4:04 pm
      refer [buffer-name(sym)] [channel(num)] [start-point(num)] [stop-point(num)] for a multi-channel buffer in plot~ doesn't work. Bug?
    • Dec 17 2013 | 4:46 pm
      Hi Aliatzori,
      Yes, this plot~ multichannel buffer~ reference issue is a known bug that we are still working on.
      Best, -Ben
    • Dec 29 2013 | 3:58 am
      Hi, is this a bug in Plot~ ? : if you send it a 1KHz tone (with a cycle~ 1000 obj) and then change the sampling frequency in Audio Status, from 44,1 to 96 KHz, the plotted curve shifts from the 1KHz to the 500 Hz position. (from 44,1 to 48 KHz that's the same, but it's not visualized well). Audio out is not affected, you don't hear changes in the frequency.... this issue occours in both unwindowed and windowed curves, and that just in the max example, without any other edited patching. Thanks for your support. Italo
    • Dec 29 2013 | 2:03 pm