Max 6.1.8 and Beyond
Every once in a while, I have the privilege to reveal the secrets about what we've been working on. A new software release is the big milestone for us
[See the full post at: Max 6.1.8 and Beyond]
exciting news indeed.... can't wait!
thats wonderful news which for me could only be topped if:
if there would be a way to use gen in a similiar fashion like jit.gl.shader with jit.gl.multiple, that would mean to set unique parameters for the instances? (aka jit.gl.shader @name xy, drawn mesh with @shader xy, multiple with glparam shader.abc)
Well I am excited to hear some news! I was getting worried there at the silence from Cycling74 on future plans. I am glad to hear that Jitter performance will be improved. Yay OpenGL shadows! I was hoping for more on the MSP side… But I have to say, integrated VST parameter saving and restoring, FINALLY!
In all it sounds like some solid improvements. I am very excited to hear more about the new features of Max7. Most of all I would like to thank every one at Cycling74 for keeping such a visionary product going. I don’t know what I would do without it!
oh my gosh.
I'm now TOTALLY impatient !
"Oh, and one more thing…" (opens Safari, loads patch in browser).
Peter has it right; I too have been thinking about this a lot lately, and it seems everyone is on the same page. It's only natural
Peter is absolutely right there.
Great news. I just can't wait ;-)!
After reading very promising informations on the blog I have 2 questions (or maybe "feature requests"):
1) In connection with render-to-texture feature in Jitter... will it be possible to render objects over transparent background (very productive discussion about implementation of this feature in [mgraphics] object I had some time ago with Rob Ramirez: https://cycling74.com/forums/jit-mgraphics-alpha-drawing-on-transparent-background/). This is extremely useful not only for "inside Max" applications, but e.g. if you are using Jitter as a professional tool to produce materials intended for further processing in external video-editing software.
2) Is there a chance to implement any modern computer vision library in Jitter? Currently even simple blob recognition and tracking requires third-party externals...
Cycling ’74 just celebrated its sixteenth birthday. I guess that means we can finally get a driver’s license.
Never mind that, when can you legally get drunk?
Plenty of questions in mind, but a handful of obvious ones here:
Authorisation: can one *either* have a permanent install *or* have it dynamic and network-based? And how resilient is the network install? (Is my gig busted if the wifi fails?)
What's the story re: Max for Live? What's needed in terms of Live versions?
Is there still backwards interop (old versions opening new patchers)? I may have occasionally used that in MfL.
No VST~ issues addressed?
pd's on iOS, would be mental to have max patches on there too, I'm sorry I didn't say nuthin!
I'd really like to see a Linux version, seeing as how you guys finally have account-based authentication. God knows ever since the max 5 announcement mentioning the possibility of more platforms opening up, I've been just sitting here and hoping to become a customer....
Haha the mention of Linux and DAED!! It's mouldy mate! Ian it would be sick if you started to use max, I could finally have a buddy to make crazy algorithmic weirdness with! Or just install it on a PC :P
x
Happy!
To include Gen for all: smart decision!
Rich! Good one bruv!
I'm a stubborn bastard. Once I see a port to my native platform, I'll gladly give C74 all my munnies!
In the meantime, I represent one less customer.
Good to run into you here, man!
"We now save your patch as you’re editing it, so in the event of a crash, you won’t lose all your work."
Oh boy, I thought we 'd never see that one. Tanx a million :)
Im happy because a lot of the features presented prove that you're listening a lot to the rants of users (well, maybe except from the linux bit :) ). However a question comes to my mind : will osx 10.6.8 still be supported ? i know it's a pain for developpers to continue providing compatibility with prehistoric computers, but from my understanding quite a few of us are still using such antic mechanics. (or am i wrong ?)
Thanks everyone for the feedback! We hope to share more details soon that will address many of the questions you all have. For now, we are happy to hear about your wishes and concerns for the future of Max, as always.
I hope the jit.gl.model animation will work with the kinect.... Like an easy way to have an avatar moving with Max...
Please ditch the wheel. Please
> Please ditch the wheel.
+ 1
+1 for linux. I'd really like to be able to create fixed installations using a Raspbery Pi
Presumably Max7 will still allow 32bit mode? I'm never going to break my addiction to 3POs!
> Please ditch the wheel (or have a preference)
Incorporate Max toolbox, some advanced patching for advanced users !
No! Keep the wheel! Instead allow us to customize it.
@DAVIDESTEVENS as much as i agree that it would be wonderful to use max on a RasPi, that's two different "project": 1st porting max to linux and 2dn porting it from an x68/64 architecture to ARM.... that's a lot :)
thanks. exciting. good that dict is finally fixed.
what i often miss, is a way to do things in another thread in max4live. heavy calculations (uzi) or js sqlite access are freezing the gui and you'll only get around it with custom externals creating threads. something like poly~ but instead it creates a thread for every instance.
+1 for ditch the wheel. or at least let me switch it OFF completely.
But great announcement, good motivation.
Actually, what I would really like to see is a higher level interface for creating computational geometry, similar to what Open frameworks and CGAL have.
I think an optional wheel makes much more sense than ditching it. I would argue that customizing it could add a more complicated user experience but... it's optional. I would add though that Max could afford more key commands and customizable key commands.
Here's my list of needs/requests:
- "Group objects" option similar to Adobe Illustrator. It saves time instead of having to select many objects that might be displaced or drag around a scattered collection of them.
- "Goto Anything" feature similar to Sublime Editor's. It's a key command that brings up a search prompt in the editor that immediately makes a list of EVERYTHING according to your query - http://www.sublimetext.com
- The ability to create key commands. There are FAR TOO FEW!
I also never use the wheel, but from my teaching experiences I know that it is helpful for newbees. so +1 for the preferences to disable it, but leave it as an option.
using the fantastic Max tool box, I can patch nearly without using the mouse. Really. It's possible to really hardly ever touch the mouse. Please scratch the nearly! Patching on the keyboard only would be sooo great..
@WOYTEG: great, now it is time for [feature request] mental patching ;-)
@estevancarlos: "Goto Anything", how does this differ from doing cmd+f in Max?
@WETTERBERG The "Goto anything" functions like Google's universal search. It will find all things relating to that word/set of characters. In the case of Max, I can see this search also including all folders (that are set up in the preferences) in case you're searching for a patch. UI-wise this search box would differentiate files so that you can tell the differences between objects, patches, etc.
The truth is that Goto Anything in Sublime is more advanced than I'm describing. I just kept my description simple. You can also type keywords into the search field, in Sublime, in order to narrow the type of search you're doing. For example, in Max could do something like this:
- CTRL/CMD + Q: a search field appears
- p+spacebar (specifies you want to search patches)
- "Name of your patch"
- Select your patch
OR
- CTRL/CMD + Q: a search field appears
- "jit"
- Several patches with the characters "jit" in the file name and several objects with the characters "jit" in the object name all appear in a list
- You select what you want
This video describes it in more detail. It's very advanced and extremely useful. Includes qualities like "fuzzy matching" as well.
Great news, Cycling!
I'm very happy about most of the new features, particularly regarding some of the features I've been wishing (better jitter performance and new features permitting shadows, depth of field, etc.)
One thing I did not see explicitly mentioned but I'd love to have is better/more multithreading. For instance, I’d love for the [patcher] and [bpatcher] objects to have a simple checkbox on the inspector: "separate thread" or something like it. This way, everything inside it would get its own thread, like a top level patch! Would it be technologically feasible? It would certainly be practical…
Looking forward to the upgrade!
It all sounds fantastic. The lower upgrade price is also most welcome, I think it was $249 last time and that seemed a bit steep.
One idea for a new object I think would be useful for many - a multirange slider which outputs a list. You could use it for splitting up frequency bands or if it could also be coloured, slicing up beats or effects routing as in DBlue Glitch.
+1 also for better multithreading.
What’s the story re: Max for Live? What’s needed in terms of Live versions?
+1 for NICK ROTHWELL / CASSIEL
I would like to know if Gen is free for all, then maybe M4L synths with Gen implementation will not need full Max 6 license?
1. Disable totally the wheel via Prefs
2. Include Maxtool box
3. Auto-patch feature like in Pd
4. More customizable shortcuts (ie. more keyboard patching)
Please !
New account based registration:
I am probably the only and last user who still uses Max with iLok.... :) Never had any problems and I love the flexibilty in switching working machines offline fast. On my pen drive always carry a Max installer which saved my a... quite some times in offline installations.
Will the new system replace iLok?
Nope. I use iLok too, exactly for the convenience of being able to work easily on installation computers.
Wonderful news Cycling! Very exciting, especially the Jitter stuff.
I hope this idea is included in Max 7-
having a side drawer with the overall patcher-subpatcher hierarchy displayed, which is navigable (ie click on a node/leaf and go straight there, command-click to go there in a new window, etc) would increase patch maintenance efficiency, especially for extensive patches with lots of subpatchers.
Please uncle 74, please!
+1 for that - great idea. I can also imagine an optional map of the whole patch being useful, a bit like the 'universe' view in Pro Tools. So you can scan round big patches easily at any zoom level.
I'd also like a keyboard shortcut for creating sends an receives with one press, ie you have a send~ or send selected, press the key and a receive~ or receive with the same name is generated.
^ macro recording?
can people that bought gen get a discount on the 7 upgrade? :) doesn't seem that long ago that i bough both max and gen. although i guess it works out to be that i only paid only about 12 dollars a month for gen and tbh, i probably should've known this would happen.
anyway. yay autosave. versioning?
cloud support? the uhhh pure data :o of max patches without samples, etc for me at least, is pretty tiny. could be a good fit with account based authorization, especially for temporary authorizations. a folder you could save into that would sync when opening and quitting max?
it's cool that max is one of the only programs i use where the feature requests off the top of my head are pretty mundane, other stuff i can think of i can make. :)
a more advanced version of attrui with pattr/preset association :}
request : move all selected patching cords segments at once ! with clever rules to guess which segments have to be moved.
edit : maybe by keeping track of which segment of a patchcord was selected
a tutorial on how the "Clear Some Space" feature works...
My another question is: what with GUI performance on Retina Macs? Any improvements?
A patcher-subpatcher hierarchy view like Floating Point suggested would be really, really great to have!
I agree with the "patcher-subpatcher hierarchy view" thing.
Since M4L (Live API) uses mostly "beats" as float number for tempo-relative timing it would be nice to include it in the standard tempo-relative time values like ticks, note values and bbu for convenient usage in metro, delay, translate etc.
Request: a hostphasor~ object for Gen implementation. It is useful for exportcode and creating VST and AU sequencers and synth.
+1 for the side drawer with the overall patcher-subpatcher hierarchy that Floating Point suggested.
+1 from me. good idea!!!
Ah yes, the inevitability of a "new product!" thread becoming a "feature request!" thread.
let us dream ;)
re authorisation: I use Lemur on iPad on an ad hoc network. Would this mean I had to use the permanent authorisation?
Any news about multi touch screen support on Windows?
It's a shame to use my touch screen in Max as a mouse...
Awesome to hear about the new features, very excited.
I thought there was some thought put to whether objects in Jitter for Max 7 were going to lean on AVFoundation instead of the deprecated Quicktime... Is this the case, or is that going to wait for Max 8? Or am I missing what actually needs to happen under the hood?
Although I'm on the forums sparingly, I've been using max for 6 years now, and this is very exciting and my personal input is simple:
For my input, I'm FAR less interested in any more user-interface capabilities; I really think that what we need for Max to grow in to a serious development environment is multi-platform support; Linux (most of all, we've been saying this for years! and now with RasPi it seems necessary), iOS and Android... I know that it seems like a big leap to move into smart phone territory but it would really really really mean so much for a lot of us if we could write apps with Max. Even just for music and video, I'm sure it would be a dream come true for a lot of us if we could just turn up to our gigs with a tablet....
I know there are a lot of wants and needs in terms of the patcher-interface, but personally for me there is already too much going on as it is... I'm still nostalgic for the Max 4 classic patcher -- what I would really take all of this to the next level for so many of us I think would be Linux, iOS, Android development... and in terms of smartphone dev, I don't think most of us need to be able to patch on our tablets and phones but if there were a way to run patches on these platforms, it would change the whole game for a lot of us.
Thank you for listening.
@PARSELY TURNIPS
I think some of the motivation for UI updates is for the sake of efficiency and speed. Let's be honest, it is inherently a faster process coding with the keyboard than with the mouse. Moving fingers around in a rapid fashion produces faster results than moving a mouse. I would argue that this issue, issue of key commands, could dramatically increase productivity.
However everything else you suggest sounds great.
Finally after 16 years: Auto-save!!!
Guess after all the night-sessions I lost in a moment-crash - Could NEVER stop the Ctrl+S reflex I developed using Max! :)
Sounds good, although, as an irregular user of Max, I'm apprehensive about having to figure out changes in the UI on the fly.
Will it still run on my old Win XP 32 bit clunkers? Or is this another prod to buy new hardware?
The only request I think is highly necessary is to do what you did jit.gl.cornerpin
and have a built-in plane-mesh warper. Having the equivalent of the pen tool in photoshop.
They have this built-in feature in TouchDesigner and MJ ,a user from this forum , has built one.
This would make jitter even more a tool of choice for project involving 3D mapping.
Thanks and keep up the great work
phiol
The wheel is a bit annoying. I never use it and it pops up when I don't want it. Maybe if I understood what it's for I'd use it more and it wouldn't bother me.
Looking forward to the new playback features and gl stuff. I'd love to see more VIZZIE style clippings, maybe for OpenGL or just newer video applications in general.
In addition to the great suggestions already made (1+ for threading, side bar showing subpatchers, multifunctional search bar), some small nitpicks from me.
Making coding faster, more managable/ having an overview is always welcome.
- attrui: when assigning a scripting name and having a autopattr, store the values.
- being able to clear the message window with a message (less travel to the clear button etc) I would use this with mira while developing.
- have radiogroup buttons allign with the default font size when placing a comment beside it and using enter for the next line.
- having a way to manage state via pattr/storage. So that multiple instances of the same name get updated globally. (or maybe I don't understand how it works. I use send with prepend set to update state across a patch....)
- have an object update visually when the attributes are changed with set(?)
- abstractions in subfolder of the patch folder (maybe with sensible limitations on the levels deep) (https://cycling74.com/forums/patcher-as-abstraction-in-root-folder-of-parent-patcher/)
- being able to set a send name so that you can make send/ receive pairs in abstractions (but I guess this won't added from a backwards compatibilty viewpoint, and why there is forward?)
Great features mentioned for max 7 (shadows!), looking forward for it!
@estevancarlos I totally agree with what you are proposing, if we can simply for example, press command+o and generate an object that is connected to the one that was previously initiated is both a major and seemingly simple operation that could be implemented in max7, moving towards speed and efficiency in this sort of optimised workflow would be greatly accepted with open arms -- what i'm concerned with is making the patcher interface "heavier", bringing (even if only by a small amount) more weight on the CPU. your suggestion doesn't seem to imply this.
the reason why my main concern is moving towards a smartphone/tablet development environment is that I know the majority of us who have making patches for a few years have troves of small patches/experiments/fun things we've made over the years but may not use that could easily be reconfigured in to consumer products -- while most of us are artists, i'm sure we wouldn't mind being able to sell fun apps that come out of our intermediary work that would also allow a larger audience to play with the interesting experiments we've all developed within this programming environment. people seem to be very excited to experiment with experimental media if they can do it on the bus/subway/meantime, but to do it on the machine you work from requires an expectancy of fully integrated and maintained software with real use-value. most of the open-source media art IDEs have provided this support and the programmers involved have benefitted tremendously... I think it's time that c74 steps it up to that level (and I do recognize that GEN is a great move in that direction, for which I am very greatful)
Agreed that these changes sound quite exciting - I'm particularly enthusiastic about the tantalizing Jitter advances, especially shadow support.
As for the recent comments: given that Jitter was built on top of QuickTime and likely still uses much of its internals to operate, I do not hold much hope for a wholesale Linux port. It would be nice, but I'm not holding my breath.
A rewrite of the entire Max system to accommodate arbitrary user-defined threads from the patcher interface would also likely be impossible. I do, however, think an object similar to ubumenu for pwindow would be a much needed addition - operating complex Jitter patches without in-patch preview windows due to performance concerns is quite limiting. I'd love to see a single thread added that could perform low-priority UI updates for pwindow and other visual objects that may be used to represent state within a patch. Perhaps this could be signaled via an object's inspector flag?
I've long advocated for the ability to place objects explicitly in either Patcher or Presentation view. This would make GUI organization a lot easier and result in much less cluttered patching space. It would be very helpful to have font attributes (size, style, etc) independent for each view as well.
I'd also love to see a @dimstride attribute added to jit.gl.mesh to accommodate arbitrary remapping of that object's internal data structure. This is relevant when applying bound displacement shaders via jit.gl.shader where the displacement map does not conform to expected dimensions.
From the perspective of someone who teaches Max, the consistent availability of (optional) attributes to initialize state for all core Max objects would go a long way to making things more sensible to beginning students. I often have to explain inconsistencies between objects, which is very counterintuitive for those who are just starting their Max journey.
for what it's worth: it would be cool if you could drag/resize objects so that the text size automatically adjusts.
Would be nice too if you could stretch kslider's image just as you can with ggate and gswitch.
^ hold [shift] while dragging the handle of an object.
A follow up on Epatricio's multi-touch on windows comment.
Will Max at some point support multi-touch input natively on Windows 8 computers?
It would be fantastic to be able to perform on one device with multi-touch. The hardware exists, it'll be great when the software catches up :)
Keep up the good work!
+1 for touch support! Especially I would like to see scrolling support for lists and tables like on moble devices.
Shadows in jitter !!! Jitter world sounds great !
I would just love to see more tutorials and examples built in. Like a few good examples for us Noobs on how to use DICT, basic examples with Gen/jit.gen objects , just practical basics :)
And last but not least can we please go higher than $9 ??
Getting the reply just learn javascript to get around it isn't what I expect with a program like Max, on my level I have Max SO i don't have to do Javascript (and yes I'm learning it :) )
I'd love to see to have more display options in objects so that you are not obliged to connect it to a numbox to see the current value.
For example:
"route 1 3 5 7" will route the number 1 to outlet 1, number 3 to outlet 2, number 5 to outlet 3 and number 7 to outlet 4.
There are 4 inlets to change each value (1, 3, 5 & 7). It would be cool to see the object's name automatically change to "route 88 3 5 7" after you have send value 88 to it's second inlet (=selector for match 1). This way it becomes easier to follow what's happening in your patch.
Think of the many times you have to type "0." after the object's name to make sure it outputs floating-point numbers. Would be nice if the "0." changes automatically to it's current value.
@andro we're all still learning. That's the beauty of something as deep as Max. For your needs, you may want to look at [zl nth] and [zl slice], as well as the rest of the zl family. ZL nth will happily go above $9, as well as parse really big lists in that manner.
@n871 I prefer separating UI/display elements from the functional parts of the patch, for performance reasons. I think that's the main benefit of keeping them separate, that we can choose to monitor elements.
@Wetterberg very good point, but it could be available as an option in the inspector window.
Thanks Wetterberg ! I'll check them out as it's something I hit on a regular basis.
I hope Max7 is going to strengthen the 'project' a bit more
in particular:
- namespaces ... perhaps a [include ] object which you could add to a patch to include a search path only in that patch, or a [namespace], [include] syntax
- hierarchy directory view in project window, (I use search path in project to add my 'sub libraries'- so searchpath name + subdirectory ? as i don't want full paths, too long)
- alphabetical ordering in project window .. or make the drag n drop moving of files in it persistent!
- some kind of renaming support of a patch, which then updates patches using it (refactoring)
Surely the devs at Cycling must use moderns IDEs with C++/Java (or alike),
I cannot think of one, that has a non hierarchical browser,or a global namesspace
and they would know as programmers, these things are essentially in anything other than trivial projects :)
But really looking forward to Max7, I can dream that some of these things will be in it... but at least I know if its crashes I wont loose so much work
(of course would be nice if it didnt crash as much in the first place!)
"route 1 3 5 7" will route the number 1 to outlet 1, number 3 to outlet 2, number 5 to outlet 3 and number 7 to outlet 4.
There are 4 inlets to change each value (1, 3, 5 & 7). It would be cool to see the object’s name automatically change to "route 88 3 5 7" after you have send value 88 to it’s second inlet (=selector for match 1). This way it becomes easier to follow what’s happening in your patch.
But what do you want to happen when you save your patch after an object's visual name has changed due to a message updating one of the values? Do you want the object in the example above to be saved as [route 88 3 5 7] or to revert to its original state of [route 1 3 5 7]?
There will be cases where some people will want the one approach and others will need the other. Be careful what you wish for.
There are ways to address what you're after. Perhaps other options for displaying an object's current state.
When will Max 7 be avaailable?
Scheduler interval lower than 1 ms!!!
When?
Max 7 release date. Pleaseeeeeeeeeeeeeeeeee !
+99 to remove the wheel or at least a pref to turn it off! Thanks!
Better support for sample-accurate granular synthesis please: https://cycling74.com/forums/sample-accurate-granular-synthesis/
It would be cool if you could choose if an inlet of an object is cold or warm..it's a bit silly how many trigger objects I have to use in my patches..
an obsessive-compulsive quality might include checking the C74 website every hour of every day expecting to see the Max download link updated to 7.0... help... me... pleeez...
Just release the damn software! :) it's already november for god's sake..
While your enthusiasm is certainly commendable, it is good that Cycling74 works on bugs.
I actually have a feature request for Max 7. it would be very useful if there was a way to stop the compiler inserting a statement to automatically set the result to zero at the beginning of a expr or codebox, as illustrated in the attached example. When processing params that rarely change, with the automated setting of the result to zero at the beginning, there is no way at all to write truly efficient code without exporting the source and using C++ or equivalent instead of Max. One can't even copy the code into a code box and delete it, because it gets inserted again.
Whats the word on 2d.wave~? Will the pitching and time stuff apply? That'd be a dream for me.
I already asked the same thing in another topic. 2d.wave is an awesome object, hope it's on their list.
@Ernest: is this really something that has bogged down your code to a level that's unacceptable? Just curious. A few years ago, I taught C++ to a bunch of extremely advanced embedded programmers and they of course wanted to know what was going on at the machine level. This was such a revelation to me. The compiler that we used back then translated what we did in C++ to completely unpredictable machine instructions. Loops were optimized away, NOPs were inserted, stuff got assigned more than once, things were lined out at quad word boundaries... it was such a revelation. So my point being: I'm quite sure the gen compiler creates something that's highly optimized, beyond anything you would've imagined and I dare to think that those who wrote the codebox/gen instructions are better aware of the consequences of the "x = 0" assignments at the beginning than most mortals. But still, if you have an example of code that's influenced badly by this decision I would love to see it.