max 5 new feature videos


    Oct 05 2007 | 11:10 pm
    amazing job, max 5 looks very nice and neat file browser window, i think it would be great if one could embed it in a bpatcher (most probably not possible)..this one because when using jitter opening a dialog window will stop movie playback and thats not good best michele

    • Oct 06 2007 | 12:20 am
      I agree! The features looked really incredible. However, I wasn't too into the way the objects looked in the gui itself. Just a bit too rounded and, er, "friendly". I'm curious to see how one could pull off the very 'tight' gui's that I've seen in a lot of good and free patches such as Forester.
      On 10/5/07, mic wrote: > > > amazing job, max 5 looks very nice and neat > file browser window, i think it would be great if one could embed it in a > bpatcher (most probably not possible)..this one because when using jitter > opening a dialog window will stop movie playback and thats not good > best > michele > >
    • Oct 06 2007 | 1:56 am
      These basic "show and tell" teasers are great! Presentation mode is just a wonderfully simple solution!! Well done! Excited to get my hands on it.
      !!! john
      On Oct 5, 2007, at 4:10 PM, mic wrote:
      > > amazing job, max 5 looks very nice and neat > file browser window, i think it would be great if one could embed > it in a bpatcher (most probably not possible)..this one because > when using jitter opening a dialog window will stop movie playback > and thats not good > best > michele >
    • Oct 06 2007 | 2:00 am
      At 5:20 PM -0700 10/5/07, Nic Zwart wrote: >I agree! The features looked really incredible. However, I wasn't too into the way the objects looked in the gui itself. Just a bit too rounded and, er, "friendly". I'm curious to see how one could pull off the very 'tight' gui's that I've seen in a lot of good and free patches such as Forester.
      Well, several of the UI objects have a checkbox in their inspector that enables "classic appearance", which uses the old bitmaps. These aren't as pretty when zoomed in, but they still work. Imported Max4 patches use the classic appearance, by default.
      In general things take a similar amount of screen real estate, although the new objects look better with a little breathing room around them.
      I think that you will be able to accomplish an equally crammed UI in Max 5, as you can do in Max 4, if you want to.
      Keep in mind that several types of object can be more freely resized now, that were a fixed size in Max 4 (e.g. keyslider).
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 06 2007 | 2:32 am
    • Oct 06 2007 | 3:17 am
      Though I think that Max 5 will definitely allow for more polished interfaces, I second the concerns with readability. The audio patch cords in the demo patch are hard to read (for me). If anything is hard to read when at the computer, it's doubly problematic to students when seen on a projector.
      I'd be very much in favor of keeping non-ui objects square and doing the round thing with the ui objects, though this is probably off the table...
      Peter McCulloch
    • Oct 06 2007 | 3:34 am
      kind of looks a little like jMax too, I think, but I'm very excited, still. Just an observation. The drag and drop options look amazing. Can't wait.
      Keith
      On 10/5/07, Peter McCulloch wrote: > Though I think that Max 5 will definitely allow for more polished > interfaces, I second the concerns with readability. The audio patch > cords in the demo patch are hard to read (for me). If anything is hard > to read when at the computer, it's doubly problematic to students when > seen on a projector. > > I'd be very much in favor of keeping non-ui objects square and doing > the round thing with the ui objects, though this is probably off the > table... > > Peter McCulloch > > >
      -- Keith Manlove (512) 825-9176 keithmanlove@gmail.com
    • Oct 06 2007 | 3:37 am
      I love the new rounded look. when I watched the videos earlier today I knew that a lot of people would not be in love with new look because it is very rounded, friendly and playful. but i couldn't be happier. there has not been a software update that i have looked forward to more.
    • Oct 06 2007 | 5:15 am
      At 11:17 PM -0400 10/5/07, Peter McCulloch wrote: >Though I think that Max 5 will definitely allow for more polished interfaces, I second the concerns with readability. The audio patch cords in the demo patch are hard to read (for me). If anything is hard to read when at the computer, it's doubly problematic to students when seen on a projector.
      My experience is that after an hour or three of "OMG, it's different!", Max 5 seemed pretty natural. Now when I go back to Max 4, it seems relatively crude. If you're a Mac user, visually, it's sort of like the transition from OS9 to OS X.
      FWIW, I don't find the audio patchcords harder to use, particularly, than the bumblebee patchcords in Max 4. In fact, I find both styles of patchcords easier on the eyes in Max 5, because they're anti-aliased.
      Also, for projector use, remember that you can zoom in Max 5.
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 06 2007 | 7:49 am
      I almost cried. It's so so ugly i could kill myself. Do C74 is really allowed to bring that roundish outfit to our software ? Is there, at least an option to get rid of this ? Our patches will look like a bunch of scattered pills or suppositories...
      f.e chanfrault | aka | personal computer music >>>>>>> http://www.personal-computer-music.com >>>>>>> |sublime music for a desperate people|
    • Oct 06 2007 | 8:08 am
      On 6 oct. 07, at 05:34, keith manlove wrote:
      > kind of looks a little like jMax too, I think
      I agree... ;-)
    • Oct 06 2007 | 9:21 am
      Well, while it is great to see that one can , hopefully, have a multislider displaying values properly, I feel like arriving in aquaworld when I look at the new gui. It simply doesnt look like programming, damm its uninspiring. I dont know how much of the gui can one adjust, but from the comparison of old style ring modulator vs. the new look interface on the presentation, this is what i dont like:
      -audio cables are not sometimes readable ner the objects corners, -round objects look very silly, the old ones really worked -popup messages are gonna be hiding neighboring objects and should be replaced by a proper info bar at the bottom of the screen. the info bar in max 4 was someties useless, since it was limited to certain amount of characters
      Also, I am ot sure why one needs to zoom in and out. i mean, encapsulate, name patcher accordingly and of to the next one,.. one screen, one thought! And thats the reason for the look of the objects. It is to allow for quicker redraws...one step forward, to steps back i think
      Other than that, I consider the changes as improvements, i mean the drag and drop, playbar, the databasing.
    • Oct 06 2007 | 9:42 am
      The padded edges.. just in case we might get hurt. What is this, Max the mental asylum?
    • Oct 06 2007 | 10:51 am
      I believe this presentation mode and the file browser are the real kick in. From what I understand it will be much simpler to organize a working flow, to collect without "collecting" hehehe.
      Indeed I will miss the squarey
    • Oct 06 2007 | 11:34 am
      Square corners, much more easier to the eye, if you hate old style max, look at plogue bidule! These round corners in v5 are just gimmicks which please you in the beginning and after a while you become really tired of it.
      Curves are attractive, but if they show off too much , they are also very dumm and not for more than one week.
    • Oct 06 2007 | 11:46 am
      i agree with itchy
      maybe we can suggest to add an old style look feature?
      On Oct 6, 2007, at 1:34 PM, itchy wrote:
      > > Square corners, much more easier to the eye, if you hate old style > max, look at plogue bidule! These round corners in v5 are just > gimmicks which please you in the beginning and after a while you > become really tired of it. > > Curves are attractive, but if they show off too much , they are > also very dumm and not for more than one week. > > >
    • Oct 06 2007 | 11:50 am
      Quote: Jabbo wrote on Sat, 06 October 2007 12:51 ---------------------------------------------------- > I believe this presentation mode and the file browser are the real kick in. > From what I understand it will be much simpler to organize a working flow, to collect without "collecting" hehehe. > > Indeed I will miss the squarey
    • Oct 06 2007 | 12:02 pm
      I would welcome this option of old look (or at least something very close), and it is essentialy what iam trying to say here.
    • Oct 06 2007 | 12:20 pm
      i think the new look is very 'slick', and hopefully doesnt have a graphic performance tradeoff(in the demo vids, i think the objects 'float' to their new position in presentation mode, the objects appear sluggish while doing this, although it could just be the video capture/compression)
      from people have said you can select a 'classic' view for each object, im assuming they will couple that with a 'global classic' view option in preferences(ala windows xp/vista vs classic view)
      like others mentioned im mainly concerned with the performance side of it, especially with them saying its going to be coded to be platformless, with then the platform specific stuff added later
      i hope that doesnt compromise performance
      if it does, even if by a little, thatd be a huge shame, as im sure it must be horrible to keep coding platform specific changes every update, but thats what the software business is about
      one thing i was really hoping for in the update to max5 is more 'prebuilt' type objects, like built in effect objects, although externals do this, it would be nice to have an 'intermediate' step for people coming from a plugin/reaktoresque background
      so until ive read all the research on how to make a reverb, and decide to tackle it on my own, i can use the builtin reverb~ object etc...
      rodrigo
      On 10/6/07, itchy wrote: > > I would welcome this option of old look (or at least something very close), and it is essentialy what iam trying to say here. >
    • Oct 06 2007 | 3:31 pm
      Change = life, max is living, let it grow. Will probably inspire us all to think about new ideas for patches.
      Doesn't seem to be dumbed down to me, maybe perhaps adapting to its competitors more (kind of like the animal kingdom).
      -chuck
      Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
    • Oct 06 2007 | 3:51 pm
      I think it looks great, a little to pony, but i don't mind much.... I absolutely love the presentation view, and i'm guessing that there will be more graphic options in the inspectors,- letting us abandon the curved edges (at least i hope so)....
      The filebrowser is brilliant and intelligent !! A feature I have been crying for in a long time !!
      I don't think it is harder to read in any way, we just have to get use to it, and the objects in the background can be shown in classic view anyway, if that is our wish...
      I like the new look of the ui objects,- and being able the resize everything is fantastic ! I cannot wait to see more gui objects,- waveform, filtergraph, etc.
      We should also remember that this is a new start ! I think it looks like a great platform for further development !
      Great work cycling !
    • Oct 06 2007 | 4:18 pm
      The old style look can be selected for all objects? not just gui objects?
      yes, it seemed rather slugish the response of switching between modes. the mouse moves rather more smoothly on the videos. it ought to be slugish, if you have a lot of objects, i dont think it matters much since you cdont need to switch between modes during performance,
    • Oct 06 2007 | 4:24 pm
      YES YES YES!!!!!! I can remember posting a while back asking for a nice pretty new UI and getting all negative response. I still don't know why people would prefer ugly ass 1980 graphics to gorgeous new looking IPHONE/LIVE/OSX prettiness. I patch for days on end sometimes and shit man it hurts my eyes to look at all that hard edged aliased crap. This rounded and smooth patch cables MMmmmmmmMMMMM!
      Im happy, so happy
      Whats up with externals though, is everything going to have to be updated again!? It just took 2 years to get all the universal updates and now what, do we have to wait another couple years?!
      I hope they make some sound quality improvements on the filters, I was never a fan of the built in filter algorithms.
    • Oct 06 2007 | 4:44 pm
      At 9:00 AM -0700 10/6/07, David Morneau wrote: >also, typing "n" to insert a new object at the cursor will be very useful...
      This is all subject to change, but -
      Single key shortcuts: b bang button c comment f floating point number box i integer number box m new message box n new object p pop up new object palette r pop up new object palette with recent tab selected t toggle box
      New object boxes have auto-complete for typing names.
      The new object palette allows for tabbing between object category tabs, using arrow keys to select objects, typing the name to select objects.
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 06 2007 | 4:48 pm
    • Oct 06 2007 | 4:54 pm
      i think that that's the last thing the program needs, actually. there are legions of people posting collections of patches and shortcuts and externals. i'd rather see cycling in the business of providing frameworks, instead of fully made solutions.
      On Oct 6, 2007, at 8:20 AM, Rodrigo Constanzo wrote:
      > one thing i was really hoping for in the update to max5 is more > 'prebuilt' type objects, like built in effect objects, although > externals do this, it would be nice to have an 'intermediate' step for > people coming from a plugin/reaktoresque background
    • Oct 06 2007 | 5:02 pm
      Quote: joshua goldberg wrote on Sat, 06 October 2007 12:54 ---------------------------------------------------- > i think that that's the last thing the program needs, actually. > there are legions of people posting collections of patches and > shortcuts and externals. i'd rather see cycling in the business of > providing frameworks, instead of fully made solutions.
      I agree !!
    • Oct 06 2007 | 5:20 pm
      At 10:18 AM -0600 10/6/07, itchy wrote: >The old style look can be selected for all objects? not just gui objects?
      Selected GUI objects only.
      >yes, it seemed rather slugish the response of switching between modes. the mouse moves rather more smoothly on the videos. it ought to be slugish, if you have a lot of objects, i dont think it matters much since you cdont need to switch between modes during performance,
      Speed-wise, switching in and out of presentation mode in Max 5 doesn't feel much different than switching in and out of editing mode in Max 4.
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 06 2007 | 5:36 pm
      On 10/6/07, Nicholas C. Raftis III wrote: > YES YES YES!!!!!! > I can remember posting a while back asking for a nice pretty new UI and getting all negative response. I still don't know why people would prefer ugly ass 1980 graphics to gorgeous new looking IPHONE/LIVE/OSX prettiness. I patch for days on end sometimes and shit man it hurts my eyes to look at all that hard edged aliased crap. This rounded and smooth patch cables MMmmmmmmMMMMM!
      Word...
      > Im happy, so happy
      That at least makes two of us... I think Cycling should know. It's a bold, NECESSARY move.
      > Whats up with externals though, is everything going to have to be updated again!? It just took 2 years to get all the universal updates and now what, do we have to wait another couple years?!
      Maybe since the UB thing was such a rush, this time it will different; release sdk early or something.
      > I hope they make some sound quality improvements on the filters, I was never a fan of the built in filter algorithms.
      Not to get into this argument again, but I am wondering what kind of MSP improvements will be going down.
      -- Keith
    • Oct 06 2007 | 5:41 pm
      Hear hear. ++ etc etc. I fully agree.
      On Oct 6, 2007, at 12:54 PM, joshua goldberg wrote:
      > i think that that's the last thing the program needs, actually. > there are legions of people posting collections of patches and > shortcuts and externals. i'd rather see cycling in the business of > providing frameworks, instead of fully made solutions. > > On Oct 6, 2007, at 8:20 AM, Rodrigo Constanzo wrote: > >> one thing i was really hoping for in the update to max5 is more >> 'prebuilt' type objects, like built in effect objects, although >> externals do this, it would be nice to have an 'intermediate' step >> for >> people coming from a plugin/reaktoresque background >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Oct 06 2007 | 6:29 pm
      i didnt mean that max5 should be a reaktor type thing, but having more objects/examples of real world applications built in would help with the steep learning curve
      even if only as a buffer before you can start building your own versions of them, but something like reverb, i have no interest in learning how to build a good sounding reverb, if its only one small aspect of a patch(which has nothing to do with spacial design)
      as david mentioned in his what it is and isnt post, there arent going to be many new objects, so what i hoped for isnt happening he does mention better help files/examples, so perhaps that will be 'solution' im(and im sure many other newbies) are looking for
      i think what makes max attractive is the object oriented nature of the program, things are encapsulated, and done for you already, so it makes it easier to build an end result without having to code, or do needless building
      sure there are tons of externals/abstractions, but those can come with their own set of problems(and sometimes pricetag)
      from the look/support overhaul of the program, it looks like c74 is trying to make the program easier to learn and use, having more non-base level objects would be a step in that direction
      just my newbie 2cents
      On 10/6/07, vade wrote: > > Hear hear. ++ etc etc. I fully agree. > On Oct 6, 2007, at 12:54 PM, joshua goldberg wrote: > > i think that that's the last thing the program needs, actually. there are > legions of people posting collections of patches and shortcuts and > externals. i'd rather see cycling in the business of providing > frameworks, instead of fully made solutions. > > On Oct 6, 2007, at 8:20 AM, Rodrigo Constanzo wrote: > > one thing i was really hoping for in the update to max5 is more > 'prebuilt' type objects, like built in effect objects, although > externals do this, it would be nice to have an 'intermediate' step for > people coming from a plugin/reaktoresque background > > > > > *v a d e //* > > *www.vade.info* > *abstrakt.vade.info* > > > > > >
    • Oct 06 2007 | 6:45 pm
      ask yourself this:
      if this was really max's virtue, how would it stack up against reaktor? or jitter against isidora?
      not well. because those programs are specifically designed to do what you are asking for. max is something more.
      On Oct 6, 2007, at 2:29 PM, Rodrigo Constanzo wrote:
      > i think what makes max attractive is the object oriented nature of > the program, things are encapsulated, and done for you already, so > it makes it easier to build an end result without having to code, > or do needless building
    • Oct 06 2007 | 7:02 pm
      I don't agree. Pre-built very good quality effects such as reverbs, Eqs, compressors, delays, and ordinary things like that could be a good way to learn faster Max Msp. Access to Max would be possible even to people who don't know anything about dsp programming. Moreover, as someone else has already said, Max Msp filters objects are not very good, and some externals made by other people are better than those included with max. Many people don't use Max because they don't know nothing about all these free third party externals made by people who really use max to work on their music. ------- In conclusion, although I like the new UI (the Presentation Mode is really a great thing), I would like to see Cycling74 working more on improving and enhancing their externals and GUI objects (like putting reference grids and numbers on the Filtergraph, with an active cursor also; spline curves for the envelope editor, etc..), making Max Msp a more versatile and powerful tool, instead of concentrating on making the UI prettier. Best,
      Carlo Laurenzi
      ----- Original Message ----- From: "joshua goldberg" To: Sent: Saturday, October 06, 2007 6:54 PM Subject: Re: [maxmsp] Re: Re: max 5 new feature videos
      >i think that that's the last thing the program needs, actually. there are >legions of people posting collections of patches and shortcuts and >externals. i'd rather see cycling in the business of providing >frameworks, instead of fully made solutions. > > On Oct 6, 2007, at 8:20 AM, Rodrigo Constanzo wrote: > >> one thing i was really hoping for in the update to max5 is more >> 'prebuilt' type objects, like built in effect objects, although >> externals do this, it would be nice to have an 'intermediate' step for >> people coming from a plugin/reaktoresque background >
    • Oct 06 2007 | 7:05 pm
      I completely Agree!
      Carlo Laurenzi I'd like to see more varieties of filters, a vector delay unit for building things like spectral delays, as well as a few more options for delay-line interpolation. A really nice convolution reverb in Max would also be nice, but this might be a bit much...
      I think that there are some things like multi-band compressor/limiters that are complex enough to be beyond the range of a lot of people's expertise (or even simply interests). Furthermore, it's nice to have things like gizmo~ and the omx library included in the distribution as it means that the object is supported by Cycling '74, and that it will most likely be compatible with future versions and will be documented in a standardized, centralized way. This is no knock against third-party developers, who have really made a lot of exceptionally cool objects, but just a reflection of how the system is. Objects like fiddle~, pitch~, bonk~, etc. are incredibly useful, and it would be very nice to have more of them included with Max.
      One thing that I would really love to see is a solution to the old phasor~ and sah~ loop problem. (changing the speed of phasor once per cycle with sample accuracy) I know there are externals that do this, but it'd be nice to have one that's in the standard distribution.
      my two cents.
      Peter McCulloch
    • Oct 06 2007 | 7:22 pm
      its the opposite, i dont want a glorified effect box, for that id just use plugs/reaktor
      but i dont want to get into a hugely complex thing, like making a nice reverb, when thats only an aspect of a patch(that has nothing to do with normal 'effect processing)
      i think the question is how does maxmsp compare to csound, or supercollider, or c++ or whatever, max is built around having objects to do specific things for you, without needing to code
      if people didnt want the prebuilt objects to handle tasks that they would otherwise have to program themselves, maxmsp wouldnt exsist
      granted, if i was a seasoned maxmsp veteran, id want more features that appealed to that, but im not, im still learning, so id look for features that appealed to me
      and given teh amount of examples of those type of objects/externals out there, its not like c74 would waste tons of man hours on this,
      On 10/6/07, joshua goldberg wrote: > ask yourself this: > > if this was really max's virtue, how would it stack up against > reaktor? or jitter against isidora? > > not well. because those programs are specifically designed to do > what you are asking for. max is something more. > > On Oct 6, 2007, at 2:29 PM, Rodrigo Constanzo wrote: > > > i think what makes max attractive is the object oriented nature of > > the program, things are encapsulated, and done for you already, so > > it makes it easier to build an end result without having to code, > > or do needless building > >
    • Oct 06 2007 | 7:23 pm
      At 7:29 PM +0100 10/6/07, Rodrigo Constanzo wrote: >i didnt mean that max5 should be a reaktor type thing, but having more objects/examples of real world applications built in would help with the steep learning curve
      Well, my opinion is that for most of the very complex stuff like reverb, the use VST~ with an appropriate plugin is a pretty good solution..
      Different programming languages are at different points on the atomic scale, low level high level. Low level languages make you roll your own everything (e.g. the original C language.) High level languages have more complete support for a particular worldview (e.g. Smalltalk.) One is not necessarily better than the other; each language will have benefits for some tasks, and drawbacks for some tasks.
      Low level languages allow you to do anything, but you have to do everything yourself.
      Higher level languages may allow you to code things faster, as long as the language supports what you're trying to do.
      I would put Max somewhere in the middle of this continuum, with the ability to go lower and higher (writing externals in C, or using VSTs, respectively.)
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 06 2007 | 7:43 pm
      At 10:24 AM -0600 10/6/07, Nicholas C. Raftis III wrote: >Whats up with externals though, is everything going to have to be updated again!? It just took 2 years to get all the universal updates and now what, do we have to wait another couple years?!
      Non-GUI externals should just work as they worked in Max 4.
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 06 2007 | 9:55 pm
      I like the new look.
      The main difference is that soon, my patches won't look as scary as they do now. Old school, rectangular boxes and messy patchcords always frighten non-max people. I think most of the users will get used to it very quickly. OS9 to OSX is good comparison. It took me ages to switch, but after I did it I didn't look back.
      I must say that new hint/help pop-up windows look to messy to me, mainly because they appear at different place on the screen every time. I'd like to have a possibility to switch to something more conservative, like pop-ups always at the bottom/top.
      I hope scheduler/timing issues will get solved or at least improved.
      Klif
    • Oct 06 2007 | 11:11 pm
      There was a thread about this recently on the [dev] list. Max 4.6 and Max 5 externals are binary compatible, although there are some API changes. Most externs will work fine, although some (and all UI objects) will need to be rewritten for the changes to the underlying API. I'm going to ballpark that 85-90% of existing 4.6.x objects will continue to work without any changes whatsoever.
      jb
      Am 06.10.2007 um 19:36 schrieb keith manlove:
      > Maybe since the UB thing was such a rush, this time it will different; > release sdk early or something.
    • Oct 07 2007 | 12:06 am
    • Oct 07 2007 | 12:41 am
      So, I went to AES today and played very quickly with Max 5. I am not an audio guy (more jitter nerd), but here are my initial thoughts, and perhaps some "facts" from cycling who were kind enough to answer some questions I posed. Im sure this is subject to change and is no way official, and was just about 30 minutes of Q/A with Cycling.
      The UI is really really really nice in person (I was a bit skeptical myself), and Cycling has paid quite a bit of attention to detail, and it shows. Every aspect is tweaked, seems easy to use and is well thought out. I very much appreciate the changes. It does strike me as much more approachable.
      I asked about poly~ and its multithreading support, which *only* applies to MSP~ audio objects. It does not run anything else in other threads. So no, Jitter users, this is not an easy multithreading workaround (yeah I thought there was hope).
      BPatcher - issues with nested bpatchers and re-drawing glitches ought to be gone. Bpatchers can apparently also have an alpha with background color and be tinted, so that they can be overlayed over other objects and tint background layers and their UI objects. This sounds useful for UI cues based on color, etc.
      Inspectors are totally updated and look quite nice.
      The new browser looks quite nice, and I asked that It be an option to embed in a patcher as an object. Apparently it is built in Max itself (im not sure if that is correct however), and uses an SQLLite backend for storing filepaths / objects it finds in the paths you set, so you can apparently query this DB yourself.
      it seemed quite nice and useful.
      Now, the sad news seems to be:
      The UI requires more horsepower due to the new compositing engine.
      Regular objects that used to be skinnable with bitmaps, at least, at this time are not customizable.
      The scheduler remains the same, and no tweaks have been made to the core engine. This seems like a UI/Facelift, but the internals are the same.
      This is nice for backwards compatibilty and ease of updating, but, for some reason, it feels like bad news to me.
      Anyway, Considering how huge of an update this is, I plan on reserving any opinion on the shipped Max 5, but I thought some people would be interested in this.
      Thanks,
    • Oct 07 2007 | 1:12 am
      random question, is max 5 going to do away with the 1000 dollar license fee to sell an applet on windows?
    • Oct 07 2007 | 1:48 am
      yet another reason to ditch windows.... :P
      On Oct 6, 2007, at 9:12 PM, Nicholas C. Raftis III wrote:
      > > random question, is max 5 going to do away with the 1000 dollar > license fee to sell an applet? > -- > -=ili!ili=- www.Axiom-Crux.net -=ili!ili=- >
    • Oct 07 2007 | 2:43 am
      Quote: vade wrote on Sat, 06 October 2007 17:41 ---------------------------------------------------- > > The UI is really really really nice in person (I was a bit skeptical > myself), and Cycling has paid quite a bit of attention to detail, and > it shows. Every aspect is tweaked, seems easy to use and is well > thought out. I very much appreciate the changes. It does strike me as > much more approachable.
      I've also seen it in action and think it's a great improvement. I sort of understand the complaints some people have made about ditching the older look, but I really think this is a necessary step for C74 to stay competitive. Looks *do* matter. But more importantly, the new graphics engine will provide new features and fix existing bugs, such as:
      > BPatcher - issues with nested bpatchers and re-drawing glitches > ought to be gone. Bpatchers can apparently also have an alpha with > background color and be tinted, so that they can be overlayed over > other objects and tint background layers and their UI objects. This > sounds useful for UI cues based on color, etc.
      This is great new for me! I have a few projects I started that involved scriptable GUIs in bpatchers and I put them on hold because of redrawing glitches. I can't wait to follow through on these ideas once things actually work properly.
      As for the true transparency support, I really think this will make it possible to do some amazing GUIs in Max. It may be the feature I am most excited about. In the demo I saw, a semi-transparent object was put in front of another object and setup such that mouse clicks passed through the semi-transparent object to the one beneath. Very cool!
      > The UI requires more horsepower due to the new compositing engine.
      An unfortunate but necessary and expected trade off. I will gladly take a performance hit for transparency support, zooming, and the nicer graphics as long as it is a reasonably small hit. I also wonder since performance mode will typically display only a few objects if it may somewhat compensate for the performance hit? I guess well-designed Max 4 GUIs hide any unnecessary objects, but Max 5 may help avoid drawing unnecessary objects when patching on-the-fly.
      -Adam
    • Oct 07 2007 | 2:56 am
      At 8:41 PM -0400 10/6/07, vade wrote: >The UI requires more horsepower due to the new compositing engine.
      The ship hasn't sailed on this one. There are still optimizations still being done. I've seen dramatic improvements in the last few builds.
      >The scheduler remains the same, and no tweaks have been made to the core engine. This seems like a UI/Facelift, but the internals are the same.
      I've been characterizing this release by using a Devo album title: "Duty Now for the Future." IMO, this release is all about creating a new stable platform for future development. As I understand it, keeping the old code base up to date with OS and hardware changes was so time consuming that there wasn't much development time left over to do fundamental engine/architecture changes. The new Max5 platform should be flexible enough to allow for more time spent doing fun development, and less time being spent doing mandatory development.
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 07 2007 | 2:59 am
      At 7:12 PM -0600 10/6/07, Nicholas C. Raftis III wrote: >random question, is max 5 going to do away with the 1000 dollar license fee to sell an applet?
      IIRC, this was a Windows-only fee imposed by the old cross-platform solution that was being used. If that is correct, then I imagine that this fee would go away, but I have no knowledge of this one way or another.
      -C
      -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 07 2007 | 3:29 am
      Yes - the $1000 fee for windows apps will be gone.
      -A
    • Oct 07 2007 | 8:47 am
      On 7 Oct 2007, at 01:41, vade wrote:
      > Regular objects that used to be skinnable with bitmaps, at least, > at this time are not customizable.
      Aw ... Death of the Image Burger?
      -- N.
      nick rothwell -- composition, systems, performance -- http:// www.cassiel.com
    • Oct 07 2007 | 9:51 am
      > Now, the sad news seems to be: > > The UI requires more horsepower due to the new compositing engine. > > Regular objects that used to be skinnable with bitmaps, at least, at > this time are not customizable. > > The scheduler remains the same, and no tweaks have been made to the > core engine. This seems like a UI/Facelift, but the internals are the > same. > > This is nice for backwards compatibilty and ease of updating, but, > for some reason, it feels like bad news to me. > > Anyway, Considering how huge of an update this is, I plan on > reserving any opinion on the shipped Max 5, but I thought some people > would be interested in this. > > Thanks, >
      these are bad bad news to me,i was hoping behind pretty face there was some core tweaks :(
    • Oct 07 2007 | 11:49 am
      Am 07.10.2007 um 04:56 schrieb Chris Muir:
      >> The UI requires more horsepower due to the new compositing engine. > > The ship hasn't sailed on this one. There are still optimizations > still being done. I've seen dramatic improvements in the last few > builds.
      This was the only thing worrying me when I saw the nice new features videos. Glad to hear this is being worked on - please please with sugar on top make Max 5 a pleasant enviroment even on lower end machines. Maybe add an option to disable FSAA? :p
      g, g.
    • Oct 07 2007 | 5:00 pm
      On Oct 7, 2007, at 2:51 AM, mic wrote:
      > these are bad bad news to me,i was hoping behind pretty face there > was some core tweaks :(
      I suppose it all depends on what one considers to be "Core". Here's a few of the features I personally feel to be "Core" (and even when they relate to UI, are much more than a "facelift", as they require significant infrastructural change):
      - multiple undo - drag + drop - unicode text support - long filename support - JSON human readable/editable patcher format - configurable keyboard shortcuts - integrated, in application, searchable object reference - in application SQLite DB (yes, you can create and manage your own databases) - robust html rendering engine in patchers (with patcher interaction via html JS) - object sensitive error reporting in max window (with reveal object in patcher) - improved debugging window + infrastructure (with message stack view, reveal object in patcher, "watchpoints" with message history)
      For externals developers: - improvements to the object infrastructure to make things like attribute exposure, defaults, JSON file saving, inspectors, generation of object reference templates, etc. happen "automatically" - XML + JSON file import/export - crossplatform, antialiased, compositing 2D vector graphics API (also accessible via JS)
      It is also important to note that much of these "Core" improvements pave the way for additional features + improvements in the future. As has been mentioned several times, this is very similar to Apple's change from OS 9 to OS X or Microsoft's changes from Windows 95 to XP/ Vista, and with it, we realize that there will be parts of this transition that are not universally popular (as was the case with Apple + Microsoft's changes at the time). C'est la vie.
      In the meanwhile, there's still lots of work for us to do to make this release as good as possible...stay tuned.
      -Joshua
    • Oct 07 2007 | 6:11 pm
      Thats very true. I suppose for some reason in my head I segregated the UI from the engine. Thinking about it I guess my only gripe was the UI in the "main thread" issue plus the statement the UI requires a bit more CPU usage to run. But I really should reserve any judgement for the final release. Sorry for seemingly being a downer, was not my intention, because I actually am quite excited about the UI stuff, as quality of life is quite important.
      I also appreciate the fact that the codebase is more modern and easier to use, which will let Cycling be more agile, which is something everyone gains from.
      Thanks for the insight.
      On Oct 7, 2007, at 1:00 PM, Joshua Kit Clayton wrote:
      > I suppose it all depends on what one considers to be "Core". Here's > a few of the features I personally feel to be "Core" (and even when > they relate to UI, are much more than a "facelift", as they require > significant infrastructural change):
      v a d e //
      www.vade.info abstrakt.vade.info
    • Oct 07 2007 | 7:17 pm
      Then again, rumors have it that Damian Hirst is looking into Max now...
      ;-)
      Trond
      f.e wrote: > I almost cried. It's so so ugly i could kill myself. Do C74 is really > allowed to bring that roundish outfit to our software ? Is there, at > least an option to get rid of this ? Our patches will look like a bunch > of scattered pills or suppositories...
    • Oct 07 2007 | 7:20 pm
      Quote: jkc wrote on Sun, 07 October 2007 10:00 ---------------------------------------------------- > > - in application SQLite DB (yes, you can create and manage your own > databases)
      Cool! I had only heard of the SQLite DB in the context of the new file browser widget. It will be great to use it for arbitrary data too. Coll gets the job done most of the time, but it is a pretty limited data structure.
      > - robust html rendering engine in patchers (with patcher interaction > via html JS) ... > - XML + JSON file import/export > - crossplatform, antialiased, compositing 2D vector graphics API > (also accessible via JS)
      So will you be supporting SVG (as in the standard W3C XML language)? That would be very nice, especially since it sounds completely scriptable.
      Anyway, lots of really great changes under the hood. Really exciting stuff IMO. Sounds like almost everyone should be able to find something to be happy about even if there are a few disappointments (which is unavoidable in any software release IMO).
      But damn, this is still half a year away? Ok, gotta stop thinking about it ;)
      -Adam
    • Oct 07 2007 | 9:29 pm
      On Oct 7, 2007, at 12:20 PM, Adam Murray wrote:
      > > So will you be supporting SVG (as in the standard W3C XML > language)? That would be very nice, especially since it sounds > completely scriptable.
      Some SVG support will be present, though I'm not certain if it supports the complete SVG standard. For example, fpic allows the use of SVG files, and we may expose the use of SVG from JS/C.
      -Joshua
    • Oct 07 2007 | 9:55 pm
      that sucks, because now my $10,000,000 diamond studded jitter patch is going to be worth a lot less. damn you to hell, established art world!
      On Oct 7, 2007, at 3:17 PM, Trond Lossius wrote:
      > Then again, rumors have it that Damian Hirst is looking into Max > now... > > ;-) > > Trond > > > f.e wrote: >> I almost cried. It's so so ugly i could kill myself. Do C74 is >> really allowed to bring that roundish outfit to our software ? Is >> there, at least an option to get rid of this ? Our patches will >> look like a bunch of scattered pills or suppositories... > >
    • Oct 07 2007 | 10:38 pm
      On Oct 7, 2007, at 1:48 AM, Nick Rothwell wrote:
      >> Regular objects that used to be skinnable with bitmaps, at least, >> at this time are not customizable. > > Aw ... Death of the Image Burger?
      Or is this about objects like [matrixctrl], [pictctrl] and [pictslider]?
      When I watched the new feature videos, I did wonder what the zoomable interface would do with animation strips rendered at a specific resolution. Imageburgers are fun, and I use them sometimes in patches for my own use or that I share with friends, but custom graphics in the objects above are something I use all the time in just about everything... I have a hard time imagining Max without them. Are they coming back?
      I *love* the new interface, though. It's gorgeously modern while still looking like Max. And all the core improvements and the capabilities they give to Cycling for future development make the transition bumps entirely worth it.
      Vlad
      Vlad Spears Urbi et orbi
    • Oct 07 2007 | 11:18 pm
      On 10/7/07, Trond Lossius wrote: > Then again, rumors have it that Damian Hirst is looking into Max now... > > ;-) > > Trond
      I really hope that means there will be a "The Physical Impossibility of Death in the Mind of Someone Living II" that comes with a max controlled shark. Assuming there isn't already a project with max controlled shark.
      Keith
    • Oct 08 2007 | 12:00 am
      Quote: Andrew Pask wrote on Sun, 07 October 2007 16:29 ---------------------------------------------------- > Yes - the $1000 fee for windows apps will be gone.
      Argh. Now I have no excuse ;-)
    • Oct 08 2007 | 6:27 am
      ..yeah that's right..can't wait to try it ;)
    • Oct 09 2007 | 7:11 am
      Quote: vade wrote on Sun, 07 October 2007 02:41 ----------------------------------------------------
      > I asked about poly~ and its multithreading support, which *only* > applies to MSP~ audio objects. It does not run anything else in other > threads. So no, Jitter users, this is not an easy multithreading > workaround (yeah I thought there was hope). >
      Noooooo!
      I really thought.. maybe this time... *sniff*
    • Oct 09 2007 | 7:28 am
      Jitter already has multithreading for many matrix operations.
      wes
      On 10/9/07, Mattijs Kneppers wrote: > > Quote: vade wrote on Sun, 07 October 2007 02:41 > ---------------------------------------------------- > > > I asked about poly~ and its multithreading support, which *only* > > applies to MSP~ audio objects. It does not run anything else in other > > threads. So no, Jitter users, this is not an easy multithreading > > workaround (yeah I thought there was hope). > > > > Noooooo! > > I really thought.. maybe this time... *sniff* > > > -- > SmadSteck - http://www.smadsteck.nl > Hard- and software for interactive audiovisual sampling >
    • Oct 09 2007 | 9:05 am
      Quote: wesley.hoke@gmail.com wrote on Tue, 09 October 2007 09:28 ---------------------------------------------------- > Jitter already has multithreading for many matrix operations. > > wes
      That's right wes but, as you have seen, the stuff we do is mostly about flinging around lots of data. Since event handling, gui updates and jitter rendering are all in one thread, to improve our framerates we need a way to separate data management and user interfaces in different threads. The only way to do this currently is to open multiple instances of max and communicate via a network protocol, and it would be so nice not to have to do that.
      To put it very simple: right now, while I'm typing this, I have 4 2.66 GHz cores all running at 30% with a framerate of 20 out of 50. And the bottleneck is not on the graphics card.
      I know that it would be really difficult to create a system that separates event handling in different parts of patches into different threads. I just envisioned (wishful thinking, I know ;) that the upgrade to poly~ would be just that.
      Mattijs
    • Oct 09 2007 | 9:28 am
      Ah, ok. I was thinking you were refering to polyphony multithreading for jitter operations not messaging.
      wes
      On 10/9/07, Mattijs Kneppers wrote: > > Quote: wesley.hoke@gmail.com wrote on Tue, 09 October 2007 09:28 > ---------------------------------------------------- > > Jitter already has multithreading for many matrix operations. > > > > wes > > That's right wes but, as you have seen, the stuff we do is mostly about flinging around lots of data. Since event handling, gui updates and jitter rendering are all in one thread, to improve our framerates we need a way to separate data management and user interfaces in different threads. The only way to do this currently is to open multiple instances of max and communicate via a network protocol, and it would be so nice not to have to do that. > > To put it very simple: right now, while I'm typing this, I have 4 2.66 GHz cores all running at 30% with a framerate of 20 out of 50. And the bottleneck is not on the graphics card. > > I know that it would be really difficult to create a system that separates event handling in different parts of patches into different threads. I just envisioned (wishful thinking, I know ;) that the upgrade to poly~ would be just that. > > Mattijs > -- > SmadSteck - http://www.smadsteck.nl > Hard- and software for interactive audiovisual sampling >
    • Oct 09 2007 | 11:48 am
      There are definitely lots of things to get excited about in the new release, and I can't wait to get my hands on it.
      I don't mind the new look on the whole, but I've got to chip in on the rounded corners thing. For me this is a real problem in terms of, for want of a better word, 'tiling':
      Maybe this is a matter of individual patching style, but I'm often lining up a whole bunch of objects in a row, column or grid - toggles, bangs, number boxes, faders, even messages. With the rounded corners this will look TERRIBLE.
      Just to be clear - I'm not objecting to the new look on general aesthetic grounds, just the round corners for this very specific reason. Does anyone else see this as a problem, or is it just me?
    • Oct 09 2007 | 12:18 pm
      Are you on Mac? If so, try this: select several files in a folder in the Finder and give them a color label (cmd + I). Now deselect the files and look at that: a stack of rounded corners. Doesn't look so bad, does it? It's a matter of personal taste, I suppose. If you really need a more unified look for a bank of controls, you can probably achieve it with other GUI objects.
      On Oct 9, 2007, at 7:48 AM, Joseph Hyde wrote:
      > > Maybe this is a matter of individual patching style, but I'm often > lining up a whole bunch of objects in a row, column or grid - > toggles, bangs, number boxes, faders, even messages. With the > rounded corners this will look TERRIBLE. > > Just to be clear - I'm not objecting to the new look on general > aesthetic grounds, just the round corners for this very specific > reason. Does anyone else see this as a problem, or is it just me?
    • Oct 09 2007 | 12:23 pm
      jb
      Am 09.10.2007 um 13:48 schrieb Joseph Hyde:
      > Maybe this is a matter of individual patching style, but I'm often > lining up a whole bunch of objects in a row, column or grid - > toggles, bangs, number boxes, faders, even messages. With the > rounded corners this will look TERRIBLE.
    • Oct 09 2007 | 12:27 pm
      Hi everyone
      I was wondering if the new Max 5 could have the option "save project" in order to save a patch with all sub-patches, sounds and extraobjects. I think this little detail makes us save a big amount of time. Thanks for thinking of it Cheers Sebastian Rivas, Ircam 1 place Igor-Stravinsky F-75004 Paris Tel +33 (0)1 44 78 48 43 Fax +33 (0)1 44 78 15 60 GSM +33(0)6 63 70 19 36 Sebastian.Rivas@ircam.fr
    • Oct 09 2007 | 2:08 pm
      I have a major problem with the new look. I despise the rounded edges. I will never become accustomed to this.
      Max is a programming language, I use it like a language. I use it something like how I'd use notepad++. Obviously Max is a different way of thinking, but the hard edges are very important for programming style. They allow for a WAY of programming. Don't take away the way. One thing I love to do is have one pixel of space in between two objects. Max4 looks freakin' awesome! I love my alignments of little things in Max4. I love pixels, and single-pixel-wide wires. I align up boxes as if they were characters of code in a text editor. I know it's not actually like that, but that's the only way I can think to describe this idea with something you might be able to relate to. The hard edges are part of Max's SYNTACTICAL STYLE. The edges themselves create an instantaneous ruler you can follow across with your eyes without thinking about it. My brain is actually physically wired internally to match the way that max wires and object boxes flow and align. You are going to break my brain. When edges are rounded, you will constantly second-guess yourself about whether something is aligned or not. A crosshair doesn't help. Maybe it is perfectly aligned, but the round edges play tricks on you. They're bad for programming.
      It's something like this: You've been coding in a language for years and you love to do:
      f(x) { ....r->n(x); }
      style syntax.
      All of a sudden somebody comes along and tells you all future versions of the language will only support:
      ..f(x) ....{ r->n(x); ....}
      style syntax.
      And now you are real pissed off. I got a message in the middle of the night from a buddy angry about the new edges.
      I've read how you'll support "old max" rendering. I don't want that! That's terrible. That's a hack. I want the new Max, but with hard edges. Allow the new Max to use the killer new 2d vector api but put to use with a Max-style configuration -- at default zoomlevel: possible to have single pixel wide yet antialiased wires, single pixel wide borders on objects, and allow us to space objects apart by one pixel.
      It looks like everything is getting fat. And you are breaking syntax.
      Yours, - Invect
    • Oct 09 2007 | 2:36 pm
      Sorry, but that's simply absurd. If you don't like the new look, that's fine. But to insist that round edges affect your expressive abilities? Sorry, no.
      In addition to new round edges, Max 5 will offer a number of feature which will improve your productivity and expressivity.
      We welcome the criticism from pro- and contra- new look factions, though they will not likely influence the design at this stage in the game. I don't mean that to sound harsh -- it's simply the truth of the matter.
      jb
      Am 09.10.2007 um 16:08 schrieb Zola:
      > I have a major problem with the new look. > I despise the rounded edges. > I will never become accustomed to this. > > Max is a programming language, > I use it like a language. > I use it something like how I'd use notepad++. > Obviously Max is a different way of thinking, but the hard edges > are very important for programming style.
    • Oct 09 2007 | 2:38 pm
    • Oct 09 2007 | 2:41 pm
      Quote: Jeremy Bernstein wrote on Tue, 09 October 2007 08:36 ---------------------------------------------------- > Sorry, but that's simply absurd. If you don't like the new look, > that's fine. But to insist that round edges affect your expressive > abilities? Sorry, no.
      Absolutely! That is precisely what I am saying. Load up a cursive font in your text editor, and get some work done for a few days.
    • Oct 09 2007 | 3:12 pm
      ; max setcornerradius 0.5
      Yes, that's what's wonderful about vector graphics. Cycling could easily allow us to set just exactly how edgey or soft we want it; it's vector! We could set the radius, or a radius of 0.0 to have hard edges.
      I actually really like the new look for many reasons. Aesthetically it's well integrated. It was neat watching the little bang button blink. (It was saying hello.)
      As long as 1 pixel borders and wires are not lost.
    • Oct 09 2007 | 3:35 pm
      I agree with Zola that the new interface will make a difference, comparable with a change of syntax, perhaps even comparable with a switch from javascript to lua. ;)
      But I do not agree per se that this change is a negative one. I too have always felt most comfortable when there is 1 pixel in between my objects and they are all strictly aligned. But for some time now I have been thinking that I should change my 'way' and start to put more space in between my objects and use less objects in one subpatch. Just to make my patch more readable.
      Naturally, this means that I'll need much more subpatchers. With the direct consequence that to avoid connecting much more patch cords, I'll have to use much more receives. Using much more receives means I'll have a much bigger problem not letting the global names get in each others way. Ergo...ooOO (fill in the gaps).
      Btw Zola, are you aware that the people of a more artistic background (which probably vastly outnumber the 1-pixel-between-aligned-objects-maxers on this list) will all think we're nutcases? Not that I care of course, I'll continue making bad jokes about atari computers and drinking black coffee as if nothing happened .. ;)
      Hey and please be polite to mr Bernstein. I think he's ok.
      Mattijs
    • Oct 09 2007 | 3:55 pm
      yes, but not for jit.qt.movie :) Sorry i should have been more specific.
      On Oct 9, 2007, at 3:28 AM, Wesley Smith wrote:
      > Jitter already has multithreading for many matrix operations. > > wes > > On 10/9/07, Mattijs Kneppers wrote: >> >> Quote: vade wrote on Sun, 07 October 2007 02:41 >> ---------------------------------------------------- >> >>> I asked about poly~ and its multithreading support, which *only* >>> applies to MSP~ audio objects. It does not run anything else in >>> other >>> threads. So no, Jitter users, this is not an easy multithreading >>> workaround (yeah I thought there was hope). >>> >> >> Noooooo! >> >> I really thought.. maybe this time... *sniff* >> >> >> -- >> SmadSteck - http://www.smadsteck.nl >> Hard- and software for interactive audiovisual sampling >>
      v a d e //
      www.vade.info abstrakt.vade.info
    • Oct 09 2007 | 3:59 pm
      I swear we must be mind twins. MIND TWINS I SAY!
      On Oct 9, 2007, at 11:35 AM, Mattijs Kneppers wrote:
      > (which probably vastly outnumber the 1-pixel-between-aligned- > objects-maxers on this list)
      v a d e //
      www.vade.info abstrakt.vade.info
    • Oct 09 2007 | 4:09 pm
      >>I got a message in the middle of the night from a buddy angry about the new edges.
      I hate it when that happens.
      I never realized how much people love their little islands of OS9, floating around in the big bad ocean of contemporary OS.
      >>It looks like everything is getting fat.
      That's because the display industry is over-producing pixels; if we don't find some way to consume them all, there will be a pixel glut, and that would be tragic.
      Re this thread: Is it possible to beat a dead horse before it's even been born?
    • Oct 09 2007 | 4:21 pm
      something i am hoping for too...
      the whole project management needs an upgrade (or rather an implementation, since there is none today) but i can't think that c74 (with ableton) have not taken this on... so i am hoping and expecting something.
      t.
      Am 09.10.2007 um 09:27 schrieb Sebastian.Rivas:
      > > Hi everyone > > I was wondering if the new Max 5 could have the option "save > project" in order to save a patch with all sub-patches, sounds and > extraobjects. I think this little detail makes us save a big amount > of time. > Thanks for thinking of it > Cheers > Sebastian Rivas, > Ircam > 1 place Igor-Stravinsky F-75004 Paris > Tel +33 (0)1 44 78 48 43 > Fax +33 (0)1 44 78 15 60 > GSM +33(0)6 63 70 19 36 > Sebastian.Rivas@ircam.fr > > http://www.myspace.com/sebastienrivas > > >
    • Oct 09 2007 | 4:39 pm
      Quote: Mattijs wrote on Tue, 09 October 2007 08:35 ---------------------------------------------------- > Naturally, this means that I'll need much more subpatchers. With the direct consequence that to avoid connecting much more patch cords, I'll have to use much more receives.
      Welcome to my world of nested subpatchers (4, 5, 6 deep)...
      As I've mentioned before, I rarely use send/receive. Instead, I put values/lists/messages into value objects and colls, and retreive them when needed.
      So I'm hoping that Max 5 offers the added functionality to coll that value offers, of finding all instances of that coll throughout the patch.
    • Oct 09 2007 | 4:45 pm
    • Oct 09 2007 | 5:33 pm
      Quote: Zola wrote on Tue, 09 October 2007 09:12 ---------------------------------------------------- > ; > max setcornerradius 0.5 >
    • Oct 09 2007 | 5:48 pm
      >Sorry, but that's simply absurd. If you don't like the new look, >that's fine. But to insist that round edges affect your expressive >abilities? Sorry, no. > >In addition to new round edges, Max 5 will offer a number of feature >which will improve your productivity and expressivity. > >We welcome the criticism from pro- and contra- new look factions, >though they will not likely influence the design at this stage in >the game. I don't mean that to sound harsh -- it's simply the truth >of the matter.
      I understand - and of course whatever will be i'll use it.
      but this reminds me when (ircam's) Patchwork became OpenMusic, with a fancy rounded look, which did nothing good to the software, which is not "nice" (even if it pretends to be) just impractical.
      coding the same thing is way faster in patchWork than in OpenMusic - because of the practical look (or the "no-look" of the objects)
      now, of course there are things you can not do in PW..
      actually PWGL kept the PW look
      ____anyhow
      best
      kasper
    • Oct 09 2007 | 6:13 pm
      Quote: arne wrote on Tue, 09 October 2007 09:39 ---------------------------------------------------- > Quote: Mattijs wrote on Tue, 09 October 2007 08:35 > ---------------------------------------------------- > > Naturally, this means that I'll need much more subpatchers. With the direct consequence that to avoid connecting much more patch cords, I'll have to use much more receives. > > Welcome to my world of nested subpatchers (4, 5, 6 deep)... > > As I've mentioned before, I rarely use send/receive. Instead, I put values/lists/messages into value objects and colls, and retreive them when needed. >
      More subpatches != more sends/receives. This probably means you could be doing things a better way. I now view send/receive as the quick fix that introduces too many problems later.
      Personally, I like to design my subpatchers like a function call with a well-defined interface of messages (parameters) it can accept. I try to only use one inlet which immediately goes to a route object. So an oscillator subpatch might expect messages like "freq " "amp " "env ", etc and those values are easily routed where they need to go.
      For nested subpatches I just prepend a routing address onto the message, so to introduce polyphony in my example I might use the messages "voice1 freq ", and "voice2 amp ". For more complicated situations I use the CNMAT external OSC-route - it adds wildcards and pseudo-regex style routing possibilities, very useful!
      This approach has let me scale small patch experiments into full-fledged applications, as well as making it easy to interconnect patches that were not designed to work together. And I can now open multiple copies of my patches without major malfunction. I couldn't do that with send/receive. The tradeoff is some extra overhead imposed by lots of routing, but without profiling tools it is hard to know how much this matters.
      For passing really large data sets a coll or jit.matrix is better of course, but you still could use the approach I just described to send an "update" message after changing the coll.
      Adam
    • Oct 09 2007 | 6:21 pm
      "no-look" ...please
    • Oct 09 2007 | 6:52 pm
      I would also like to see this feature.
      Chris
      Quote: tatama suomo wrote on Tue, 09 October 2007 10:21 ---------------------------------------------------- > something i am hoping for too... > > the whole project management needs an upgrade (or rather an > implementation, since there is none today) but i can't think that c74 > (with ableton) have not taken this on... so i am hoping and expecting > something. > > t. > > > Am 09.10.2007 um 09:27 schrieb Sebastian.Rivas: > > > > > Hi everyone > > > > I was wondering if the new Max 5 could have the option "save > > project" in order to save a patch with all sub-patches, sounds and > > extraobjects. I think this little detail makes us save a big amount > > of time. > > Thanks for thinking of it > > Cheers > > Sebastian Rivas, > > Ircam > > 1 place Igor-Stravinsky F-75004 Paris > > Tel +33 (0)1 44 78 48 43 > > Fax +33 (0)1 44 78 15 60 > > GSM +33(0)6 63 70 19 36 > > Sebastian.Rivas@ircam.fr > > > > http://www.myspace.com/sebastienrivas > > > > > > > > ----------------------------------------------------
    • Oct 09 2007 | 7:17 pm
      My only fear from this sort of a feature is that you may end up with many different versions of externals floating around your search path.
      Im sure something can be worked out so that if more than one version of an external is found, only the one in the project path is loaded?
      Im sure there are some hidden landmines with this sort of a feature though, that would result in hours of lost time debugging only to realize, doh, thats the object version from two YEARS ago!
      (or maybe not, im already speculating on bugs on imaginary feature requests, christ, I am a cynic).
      On Oct 9, 2007, at 2:52 PM, Chris Hipgrave wrote:
      > > I would also like to see this feature. > > Chris > > Quote: tatama suomo wrote on Tue, 09 October 2007 10:21 > ---------------------------------------------------- >> something i am hoping for too... >> >> the whole project management needs an upgrade (or rather an >> implementation, since there is none today) but i can't think that c74 >> (with ableton) have not taken this on... so i am hoping and expecting >> something. >> >> t. >> >> >> Am 09.10.2007 um 09:27 schrieb Sebastian.Rivas: >> >>> >>> Hi everyone >>> >>> I was wondering if the new Max 5 could have the option "save >>> project" in order to save a patch with all sub-patches, sounds and >>> extraobjects. I think this little detail makes us save a big amount >>> of time. >>> Thanks for thinking of it >>> Cheers >>> Sebastian Rivas, >>> Ircam >>> 1 place Igor-Stravinsky F-75004 Paris >>> Tel +33 (0)1 44 78 48 43 >>> Fax +33 (0)1 44 78 15 60 >>> GSM +33(0)6 63 70 19 36 >>> Sebastian.Rivas@ircam.fr >>> >>> http://www.myspace.com/sebastienrivas >>> >>> >>> >> >> > ---------------------------------------------------- > >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Oct 09 2007 | 9:44 pm
      Hi,
      I also would like the possibility to have square edges (a global parameter?). Sometimes when you need access to many parameters it is handy to be able to have GUI objects touching each other in order to save screen space. And I agree with the comment that it would look ugly with round edges.
      Also there was a very clear distinction between messages boxes (a single line) and objects boxes (a double line). This seems to have unfortunately disappeared in MAX 5. To me this is less readable, and it reminds me of the confusion that I always disliked in PD.
      The other concern is that the round edges induce shift in the position and spacing of the inlets and outlets. The ring modulator example shows how the neat parts of the original patch become a mess in the new version. Being someone who has been working for many years with Max/MSP, and having a big library of abstractions I reuse, I don't like the fact that all those painstakingly aligned and resized objects will suddenly look like a total mess. Could there please be a global parameter that would allow to keep, if not exactly the old look, at least the same sizes and spacing between inlets and outlets so that old patch remain clear and readable? It would take a considerable amount of energy to have to rearrange all the older abstractions...
      Best, Todor
      _________________________________________ Web: http://www.compositeurs.be/Todoroff.html
      > Maybe this is a matter of individual patching style, but I'm often lining up a > whole bunch of objects in a row, column or grid - toggles, bangs, number > boxes, faders, even messages. With the rounded corners this will look > TERRIBLE. > > Just to be clear - I'm not objecting to the new look on general aesthetic > grounds, just the round corners for this very specific reason. Does anyone > else see this as a problem, or is it just me?
    • Oct 09 2007 | 10:51 pm
      I'm busy working on a stand-alone for a (non-techie) client right now, and have a very short deadline. Just last week, I was thinking "I wish the Max object gui wasn't so freaking dated looking" - as I don't have much time to come up with an interface. This new Max 5 interface (plus presentation mode) would really, really do the trick!
      Ps: I think it's lovely, too. I loved the Mac OS 7,8,9 gui back when they were contemporary, but never looked back after using OS X's Aqua, and that's what this debate reminds me of...
      On 10/10/07, Todor Todoroff wrote: > > Hi, > > I also would like the possibility to have square edges (a global > parameter?). Sometimes when you need access to many parameters it is handy > to be able to have GUI objects touching each other in order to save screen > space. And I agree with the comment that it would look ugly with round > edges. > > Also there was a very clear distinction between messages boxes (a single > line) and objects boxes (a double line). This seems to have unfortunately > disappeared in MAX 5. To me this is less readable, and it reminds me of > the > confusion that I always disliked in PD. > > The other concern is that the round edges induce shift in the position and > spacing of the inlets and outlets. > The ring modulator example shows how the neat parts of the original patch > become a mess in the new version. > Being someone who has been working for many years with Max/MSP, and having > a > big library of abstractions I reuse, I don't like the fact that all those > painstakingly aligned and resized objects will suddenly look like a total > mess. > Could there please be a global parameter that would allow to keep, if not > exactly the old look, at least the same sizes and spacing between inlets > and > outlets so that old patch remain clear and readable? > It would take a considerable amount of energy to have to rearrange all the > older abstractions... > > Best, > Todor > > _________________________________________ > Web: http://www.compositeurs.be/Todoroff.html > > > > > Maybe this is a matter of individual patching style, but I'm often > lining up a > > whole bunch of objects in a row, column or grid - toggles, bangs, number > > boxes, faders, even messages. With the rounded corners this will look > > TERRIBLE. > > > > Just to be clear - I'm not objecting to the new look on general > aesthetic > > grounds, just the round corners for this very specific reason. Does > anyone > > else see this as a problem, or is it just me? > >
    • Oct 10 2007 | 1:29 am
    • Oct 10 2007 | 2:52 am
      At 3:53 AM +0200 10/10/07, jln wrote: >Maybe I misread something, but I think Chris Muir mentioned that GUI objects could be selected to keep their original Max 4 look. Assuming it'll work for all GUI objects (which is the part of my answer I have a doubt about), it won't work with non-Gui objects, for sure. Check Chris' message earlier in this thread to be sure about it.
      There are a _few_ object that have a classic appearance option
      -C . -- Chris Muir | "There are many futures and only one status quo. cbm@well.com | This is why conservatives mostly agree, http://www.xfade.com | and radicals always argue." - Brian Eno
    • Oct 10 2007 | 2:55 am
    • Oct 10 2007 | 7:17 am
      Well, one of the guys here has spotted an incompatibility issue with the new look(inlets are offset by on pixel). Anyway, it must be good for them to know what current max users think of the changes, or rather that one change, all other updates could not be disappointing.
    • Oct 10 2007 | 8:38 am
      Quote: adamj wrote on Tue, 09 October 2007 20:13 ---------------------------------------------------- > Quote: arne wrote on Tue, 09 October 2007 09:39 > ---------------------------------------------------- > > Quote: Mattijs wrote on Tue, 09 October 2007 08:35 > > ---------------------------------------------------- > > > Naturally, this means that I'll need much more subpatchers. With the direct consequence that to avoid connecting much more patch cords, I'll have to use much more receives. > > > > Welcome to my world of nested subpatchers (4, 5, 6 deep)... > > > > As I've mentioned before, I rarely use send/receive. Instead, I put values/lists/messages into value objects and colls, and retreive them when needed. > > > > More subpatches != more sends/receives. This probably means you could be doing things a better way. I now view send/receive as the quick fix that introduces too many problems later. > > Personally, I like to design my subpatchers like a function call with a well-defined interface of messages (parameters) it can accept. I try to only use one inlet which immediately goes to a route object. So an oscillator subpatch might expect messages like "freq " "amp " "env ", etc and those values are easily routed where they need to go. > > For nested subpatches I just prepend a routing address onto the message, so to introduce polyphony in my example I might use the messages "voice1 freq ", and "voice2 amp ". For more complicated situations I use the CNMAT external OSC-route - it adds wildcards and pseudo-regex style routing possibilities, very useful! > > This approach has let me scale small patch experiments into full-fledged applications, as well as making it easy to interconnect patches that were not designed to work together. And I can now open multiple copies of my patches without major malfunction. I couldn't do that with send/receive. The tradeoff is some extra overhead imposed by lots of routing, but without profiling tools it is hard to know how much this matters. > > For passing really large data sets a coll or jit.matrix is better of course, but you still could use the approach I just described to send an "update" message after changing the coll. > > Adam ----------------------------------------------------
      Hi Adam and Arne, these would be interesting contributions to the 'how to apply oo within max' thread https://cycling74.com/forums/index.php?t=msg&th=25272&prevloaded=1&rid=3579&S=787f11fb3e4965c3ef2df570184d85e5&start=0 which is all about data management in larger patches, the problems with global sends/receives, the alternatives, etc.
      Let's not go into this too much here, but I would be interested in larger patches (not necessarily working ones) that demonstrate the way you work. It would be great if you'd have the possibility of mailing me some stuff.
      Cheers, Mattijs
    • Oct 10 2007 | 9:00 am
      Patcher windows are still square, as is the bpatcher object. It's not like someone went through the program indisciminately with the "round corners" wand and zapped everything. We've thought about a lot of this stuff already and I can assure you (based on the experience we had updating the help and example files) that your old patches will (probably with a few minor exceptions) look the same, just different.
      Change is always scary, but I think this will be good one. Getting all worked up about the new look months before the software is there for you to try out won't help anyone, though. So, please, give us the benefit of the doubt that we're a) concerned about the same issues as you and b) committed to making Max 5 look and perform well. Really.
      jb
      Am 10.10.2007 um 03:29 schrieb Todor Todoroff:
      > bpatcher
    • Oct 10 2007 | 9:39 am
      Quote: f.e wrote on Sat, 06 October 2007 01:49 ---------------------------------------------------- > I almost cried. It's so so ugly i could kill myself. Do C74 is really > allowed to bring that roundish outfit to our software ? Is there, at > least an option to get rid of this ? Our patches will look like a bunch > of scattered pills or suppositories... > >
      i dont like the rounded corners either, as well as the gradients of the messageboxes. it makes max look like bidule. (read: less "professional" :))
      but everything else is really nice. many things which are no suprise, but also some new ideas.
      hopefully presentation mode will not make people design their interfaces exclusively this way?
      the filebrowser looks impressive though i dont see its relevance yet. i can do most of these things in the finder faster. it is mostly for people which are not able to organize their project files on their own i suppose.
      drag onto objectboxes - superb! drag text files into colls, and paths of pictures into GUI objects. but i wonder how this will work with GUI objects which use more than 1 pic ..? the need to add a path or file to an object is (my) number one reason why i need to open inspectors all the time. good if we can get rid of this asap. that dragging will work with patchers too seems only logical and i have asked myself often why it does not already work in v4.
      -state of 110 (ableton-design free zone)
    • Oct 10 2007 | 9:48 am
      > Regular objects that used to be skinnable with bitmaps, at least, > at this time are not customizable. Much as I'm not sure I like the new look yet (very /Ableton/, don't you think?), I'm sure it will grow on me - but, it's the above statement that has me worried. Chris Muir said that: >There are a _few_ object that have a classic appearance option - can someone from Cycling verify that this will include the above skinable objects (pictslider ? pictbutton ?! matrixctrl??! -please!) I remember what a great step forward it seemed from Max 3 to 4, when you realised that you could actually start to make Max apps that didn't have to /look/ like they were made with Max; it would be a real bummer to lose this - especially if you're not mad about Max's new look anyway (though I'm sure we all will grow to love it one day ;-) cheers Roger
    • Oct 10 2007 | 11:12 am
      I assume that it wil be possible to run max 4 and 5 on the same computer and the runtime will be available for a looooooong time? oh and release the source of max 4 ; )
      isjtar
    • Oct 10 2007 | 11:29 am
      On 10 oct. 07, at 18:48, roger.carruthers wrote:
      > - can someone from Cycling verify that this will include the above > skinable objects (pictslider ? pictbutton ?! matrixctrl??! -please!)
      pictslider, pictctrl, matrixctrl are still part of Max 5, of course.
      ej
    • Oct 10 2007 | 1:11 pm
      > i dont like the rounded corners either, as well as the gradients of the messageboxes. it makes max look like bidule. (read: less "professional" :))
      I quite agree. I don't want to be a snob but I think the new look is a classic example of good design being subordinate to marketing. It seems to me to be less about enhancing the Max development experience and more about getting Max ready for some kind of future integration with Live, an idea which I'm sure will make some people very happy but which personally fills me with dread as I think that damn software is the death of music...
      sb
    • Oct 10 2007 | 1:17 pm
      I think a parameter to set the 'cornerradius' of ALL rounded objects is a perfect solution and I strongly desire such a parameter. Jeremy, there's no need to get defensive. No one's saying anything to the effect that what the team is doing is indiscriminate. We're just reacting to the bite-sized pieces of information we're being given.
    • Oct 10 2007 | 2:36 pm
      if i were an MSP person, i'd be very worried about the effect of those rounded corners and antialiasing on the audio. :P
      On Oct 10, 2007, at 9:17 AM, matt wrote:
      > > I think a parameter to set the 'cornerradius' of ALL rounded > objects is a perfect solution and I strongly desire such a > parameter. Jeremy, there's no need to get defensive. No one's > saying anything to the effect that what the team is doing is > indiscriminate. We're just reacting to the bite-sized pieces of > information we're being given. >