lfxyz

and it comes with 'Vizzie' but uh, what is it?

max-5-1-6-is-released

https://cycling74.com/articles/introducing-vizzie/

Oops! On the main page now: https://cycling74.com/articles/introducing-vizzie/


Vizzie is a set of abstractions designed to help people get started with Max and Jitter, and help people just quickly throw things together.

Now, although Vizzie is absolutely not for me I do see some potential here with regards to new Max users or situations where you want some "quick" result.

So I'm wondering; are there any plans to extend on these "ready made" extensions, for example within MSP as well ?

We have all sorts of plans, and we really want to hear from people starting out and people helping other people start out, teachers in other words, how this stuff goes.

@Andrew: I think that's a very smart move and I have to compliment you guys on the way you implemented this... As said; this is totally not for me. So what is the one feature I really respect the most? That although Vizzie is here it doesn't get "in my way" so to speak.

Either way I really think Max can benefit from these "higher level" objects since its bound to make the learning curve a bit less steep for some people and provide them with "on hand tools" to get something going right away out of the box.

Don't get me wrong here: Max is perfectly capable to provide for that as well; but having these high level objects available should be bound to appeal to more people who can now use Max (to some extend anyway) without much prior knowledge yet use that as a basis to expand on it.

Just my 2 cents here, but I really think this is a good way to take Max.

Say, maybe I'm going a bit ahead of myself but would you guys also be interested in user suggestions for other "Vizzie" (-like) objects ?

If we follow your GUI style I'm pretty sure many people should be capable to come up with bpatchers of their own. And I'm also pretty confident that there will be plenty of people who'd be willing to help you guys out with suggestion patches which might help your MSP 'extension' going...

@Andrew: I think that's a very smart move and I have to compliment you guys on the way you implemented this...  As said; this is totally not for me. So what is the one feature I really respect the most? That although Vizzie is here it doesn't get "in my way" so to speak.

We're very interested in any and all reactions, patches, ideas, you name it.

Email us in support, or post here anything you like.

"We're very interested in any and all reactions, patches, ideas, you name it."

....I'll take that as an invitation to share some thoughts, based on six years of teaching Max.

Here are the situations that I have found are most likely to cause problems for beginners:

-- Objects do not display their current state. It may make sense to long term users, but newcomers are horrified when I try to explain why the argument used to initialize a parameter stays visible for the life of the object...while new values set for the parameter are never visible. This limitation does not fit with most people's concept of how software should work in 2010.

-- Similarly, when an argument or attribute is re-typed on an object, the object is re-created, with all parameters initialized to default values. Again, newcomers are horrified by this: "What, I have to load the video file in again?" Why can't re-typing modify just that single parameter, without causing a re-initialization of all other parameters?

-- There is little consistency in naming conventions across Max. We "read" a video into jit.qt.movie, but "open" an audio file into sfplay~...which is not the same as "opening" a camera connection with jit.qt.grab. And, is it really polite to require users to use Serbo-Croatian terms like "dstdimend", when 'bottom_right" would be more intuitive, descriptive, and easier to recall?

-- It's unfortunate that the Max interface does not let patch cords convey more information about their role and state. Students look visibly relieved when I say "See those yellow-and-black patch cords? They always carry 44.1k floats per second." Elsewhere in Max and Jitter, students are confused by which patch cords convey data constantly and which intermittently. Surely it would not be impossible for patch cords to appear differently based on the rate they pass data, or to make it simpler to check what type of data a cord is passing?

Dreaming of a world in which Max does not inspire fear.

Best regards,
Kurt
...
Visiting Faculty and Artist-in-Residence
MFA Digital Media
Rhode Island School of Design
http://retnull.com


Thank you for your feedback. These are all valid points, and many of them are things we've discussed internally multiple times. Unfortunately, few of the things you mention are easy things to rectify, and highlight some of the problems of what it is to program a computer (which ultimately Max does not shield the user from). Many of these cases really comes down to programming language vs. end user software, and how these are largely two disjoint areas that Max attempts to span. On the one hand I wish these problems had clear solutions that I felt would be appropriate for Max users. On the other hand, I feel like some of these things highlight a beautiful ambiguity that is the exact reason that Max has had as much usefulness to people as it has.

I don't want you to think of the following as a defense of Max (which I believe can and should continue to be improved along many different axes), but I thought I'd offer my thoughts on some of what you bring up. Note that my fellow developers might have different opinions on these matters, but in the spirit of good conversation:

1. One of the troubles with Max (and also one of its strengths) is the conflation of program specification and program UI. I think that we have some things that we could really do better in the object box, with regards to different sorts of display in different modes (i.e. not only in locked vs. unlocked mode, but other possibilities), however, what and when is the right way to display object state in the object box? How does anyone even know what it is that these values represent even if they were to change (i.e. ideally they would be in a labelled state with updates similar to what is visible in the inspector rather than the object box)? How do they re-write their code, or even know what their code is, if it is changing underneath their cursor? These are the sorts of things which make current state in object box difficult. When one is writing code in a text based language, we don't see what the current value is within the code itself. The object box is actually a text based programming language inside of a visual shell. Here this convolution becomes a true problem as you point out, especially to newcomers. Luckily after about a day of indoctrination into the cult of Max this isn't typically a big obstacle. However we think about this issue more than it might appear. Maybe someday a good answer will reveal itself (or we'll compromise some longstanding principles in the name of "progress").

2. Retyping the object, same thing as #1. IMHO, the ambiguity of code creation vs. software usage is the same issue again. These two issues almost suggest a mini inspector as part of the object itself, rather than the issue of retyping the text. Certainly some fun things to imagine in such a case. How to expose without making the interface too bloated for the advanced user is a hard problem.

3. In Max 5, there was a push to make at least read/open consistent (it's still backward compatible so the open message is still present, but all objects which take files should also support "read" [edit...no, this is not the case for sfplay~...sorry for mis-speaking on this, it is a lower level issue which we focused on]). However, I agree the fact that Max spans many domains and has been developed by many people without an iron fist of control around the message interface yields some inconsistency. However, I thing if you look at any programming interface, whether Java, or Microsoft or Apple, you'll see similar inconsistencies. It's ultimately a human problem and/or a language problem. Even for any given software (most of which has features which use buttons or sliders or dialog boxes, etc.), there's often the same amount of discrepancies when one reads any text documentation for said software. I really see it as a language thing which is tricky to enforce completely, while still remaining open and creative and productive in further developing the software.

This said, working on consistency is an important thing for us to focus on, and I agree that there are many simple improvements for us to make in this area. However, the real task, IMHO, is making whatever language an object supports more discoverable is more important than agreeing on a standard language (which is more important in the absence of discoverability). This point of discoverability I think is the single most important thing we have to work on, both for new and experienced users, especially in the realm of diminishing FEAR!!!

As for things like "dstdimend", yeah, there's no N-dimensional way to specify "bottom_right", which would actually need to be "destination_bottom_right_deep_hyperdeep_etc". Jitter simply isn't 2D, despite it being used as such 75% or more of the time. Sometimes I feel good about that. Sometimes I regret that decision. A typical dilemma between "openness" and "specificity". Swiss Army knife or Hammer. They're both useful. Sigh.

4. Patch cord probing, and tracing are two steps in this direction. We actually had some fun animated prototypes of messages passing through patchcords internally. Definitely some things to think about in this area about making program execution (vs. program specification) more transparent. Again it makes me think about things in points #1 and #2. This conflation of program and interface. Maybe we just need more "view modes", like "edit mode" "locked mode" and "presentation mode".

Anyway thanks a bunch for taking the time to share with us. We appreciate it, and are working hard trying to make Max easier to learn for beginners, more useful and manageable for experts, and improve quality and performance for all users.

As for things like "dstdimend", yeah, there's no N-dimensional way to specify "bottom_right", which would actually need to be "destination_bottom_right_deep_hyperdeep_etc". Jitter simply isn't 2D, despite it being used as such 75% or more of the time. Sometimes I feel good about that. Sometimes I regret that decision. A typical dilemma between "openness" and "specificity". Swiss Army knife or Hammer. They're both useful. Sigh. 

4. Patch cord probing, and tracing are two steps in this direction. We actually had some fun animated prototypes of messages passing through patchcords internally. Definitely some things to think about in this area about making program execution (vs. program specification) more transparent. Again it makes me think about things in points #1 and #2. This conflation of program and interface. Maybe we just need more "view modes", like "edit mode" "locked mode" and "presentation mode". 

Anyway thanks a bunch for taking the time to share with us. We appreciate it, and are working hard trying to make Max easier to learn for beginners, more useful and manageable for experts, and improve quality and performance for all users. 

Having taught Jitter myself I have to agree that some of issues Kurt is raising can indeed be obstacles to learning Max. On the other hand Joshua's point about similar inconsistencies in other programming environments is well taken. You probably can't have a toolset as mature as Max without lingering inconsistencies, and of course there's a huge codebase that is already built accounting for them. I'd much rather have the broad and deep feature set of Max, warts and all, than work in a constantly "evolving" API.

That being said, I really would love to see a few things changed in Max - my list is probably tilted a bit towards power users, but I think everyone would benefit in the end.

1. Building off of Kurt's desire to be able to observe state within an object box, I agree with Joshua that this is not practical given the confluence of form and function in the patcher window. At the same time, I really do like the idea of a "state view" in which the user could select parameters to observe during patch execution. Whether it's via a mini-inspector or a roll-over window, the developer should be able to view the range of variables the object contains and specify a subset to track. This could help greatly in debugging and teaching as well.

2. Related to this idea: it would be immensely positive if the entire Max API conformed to the attribute model. The fact that Jitter and many other more recent objects do use attributes can really undermine a beginner's enthusiasm when they are inevitably told that the other objects do not. I'm sure there are technical reasons why it would be challenging to do this, but this would be a big step forward.

3. A customizable "bookmark" menu of some kind would be very useful -- I find myself looking at certain ref pages or help files so often that I'd love to have a separate menu to quickly access them. Would be great to have some way that power users can contribute bookmark sets that others can benefit from as well - i.e. a GL "cheat sheet" that includes jitter ref pages and also links to OpenGL documentation on the web.

4. I love the presentation layer, but I think it could be improved greatly by two things: allowing UI elements that are only used in a presentation to be excluded from the patcher view, and making presentation font attributes independent of the those in the patcher. Both would make switching between patch and presentation a lot more intuitive.

5. A thorough audit of the help files and ref pages to make them more complete and accurate. I can live with the help files being behind the curve, but the ref pages really should be up to the minute. There are many small inconsistencies that can lead one to expect certain behavior, and waste time troubleshooting when it does not happen. It would also be very helpful to have documentation of some of the more advanced GL attributes that appear in recent multi-render examples posted to the forum: i.e. @capture.

Having taught Jitter myself I have to agree that some of issues Kurt is raising can indeed be obstacles to learning Max.  On the other hand Joshua's point about similar inconsistencies in other programming environments is well taken.  You probably can't have a toolset as mature as Max without lingering inconsistencies, and of course there's a huge codebase that is already built accounting for them.  I'd much rather have the broad and deep feature set of Max, warts and all, than work in a constantly "evolving" API.

That being said, I really would love to see a few things changed in Max -  my list is probably tilted a bit towards power users, but I think everyone would benefit in the end.

1.  Building off of Kurt's desire to be able to observe state within an object box, I agree with Joshua that this is not practical given the confluence of form and function in the patcher window.  At the same time, I really do like the idea of a "state view" in which the user could select parameters to observe during patch execution.  Whether it's via a mini-inspector or a roll-over window, the developer should be able to view the range of variables the object contains and specify a subset to track.  This could help greatly in debugging and teaching as well.

2.  Related to this idea: it would be immensely positive if the entire Max API conformed to the attribute model.  The fact that Jitter and many other more recent objects do use attributes can really undermine a beginner's enthusiasm when they are inevitably told that the other objects do not.  I'm sure there are technical reasons why it would be challenging to do this, but this would be a big step forward.

3.  A customizable "bookmark" menu of some kind would be very useful --  I find myself looking at certain ref pages or help files so often that I'd love to have a separate menu to quickly access them.  Would be great to have some way that power users can contribute bookmark sets that others can benefit from as well - i.e. a GL "cheat sheet" that includes jitter ref pages and also links to OpenGL documentation on the web.

4.  I love the presentation layer, but I think it could be improved greatly by two things:  allowing UI elements that are only used in a presentation to be excluded from the patcher view, and making presentation font attributes independent of the those in the patcher.  Both would make switching between patch and presentation a lot more intuitive.

5.  A thorough audit of the help files and ref pages to make them more complete and accurate. I can live with the help files being behind the curve, but the ref pages really should be up to the minute.  There are many small inconsistencies that can lead one to expect certain behavior, and waste time troubleshooting when it does not happen.  It would also be very helpful to have documentation of some of the more advanced GL attributes that appear in recent multi-render examples posted to the forum:  i.e. @capture.

5. A thorough audit of the help files and ref pages to make them more complete and accurate. I can live with the help files being behind the curve, but the ref pages really should be up to the minute.

Of course the community could be of great help here, if reporting mistakes and typos were made easy. For instance by making a link (or even a button) on every page of the ref for reporting them. I realize that not always when I see an error I take the trouble to go to this forum and report about it. I apologize.

 5. A thorough audit of the help files and ref pages to make them more complete and accurate. I can live with the help files being behind the curve, but the ref pages really should be up to the minute. 

Been messing with the VISSIE objects all night. Very cool how quick it is to play with video now. Odd that I never thought to just make a bunch of these simple bpatchers before. Only request I have have for them is that there are sync options for rates to global transport.

"clilppings" seems to be analogous to "macros" in reaktor. I've always wondered when we'd get something like that to make building with common components quick as it is in reaktor. Looking forward to other, MSP related ones like "LFO"and "Envelope". Also the ability to "save as clipping" to add your own bpatchers to the right-click menu would be cool.

Been messing with the VISSIE objects all night. Very cool how quick it is to play with video now. Odd that I never thought to just make a bunch of these simple bpatchers before. Only request I have have for them is that there are sync options for rates to global transport. 

"clilppings" seems to be analogous to "macros" in reaktor. I've always wondered when we'd get something like that to make building with common components quick as it is in reaktor. Looking forward to other, MSP related ones like "LFO"and "Envelope". Also the ability to "save as clipping" to add your own bpatchers to the right-click menu would be cool.


I was just starting to prepare modules that I was about to add to ppooll (I already had some done), when I saw this (Max, MSP, Jitter, Maxforlive and FTM).. kinda abstractions to encapsulate with bpatchers.. the very same thing you guys do with vissie.. so, I think that this is some sort of noob question, but how do I add my abstractions and bpatchers stuff, to paste from section in the max menu.. this would save me lot of time and enhance my maxmsp programming to create stuff much faster.. and by doing this I could fill a gap, between making my own programming in maxmsp at more low level stuff, and more high level stuff programming

the ability to "save as clipping" to add your own bpatchers to the right-click menu would be cool.

Just save your bpatcher as a .maxpat and put it in /patches/clippings !

> 5.1.6 release notes: "multislider now has a setlist message to set all slider values at once without causing the output."

We actually had some fun animated prototypes of messages passing through patchcords internally.

> Second VISSIE video : "Another way we can play with VISSIE modules is to turn their control input on and off"

Feature request in max: I often dream about 'Breaking'/'Unbreaking' a patchcord, using an modifier key, without the need of deleting then recreating it. This could be more elegant and a lot faster than using [gate].

And by combining this possibility with 'enlightened' patch cord when message go through them - with 'enlightenment' remanence and 'enlightenment' brightness adjustments for the user - this could get to something really great...

 the ability to "save as clipping" to add your own bpatchers to the right-click menu would be cool.

> 5.1.6 release notes: "multislider now has a setlist message to set all slider values at once without causing the output."
Nice one !

 We actually had some fun animated prototypes of messages passing through patchcords internally.

Feature request in max: I often dream about 'Breaking'/'Unbreaking' a patchcord, using an modifier key, without the need of deleting then recreating it. This could be more elegant and a lot faster than using [gate]. 

And by combining this possibility with 'enlightened' patch cord when message go through them - with 'enlightenment' remanence and 'enlightenment' brightness adjustments for the user - this could get to something really great...


It's nice to have included the "nodes" object in this update but couldn't it be extended to more than nine nodes (something like 20 or 30 nodes would be great) ? Also, has the code been modified in any way from the external version (efficiency or whatever) ?

This one was there since Max 4.6 at least. Twilight Zone anyone ?

> It's nice to have included the "nodes" object in this update but couldn't it

> be extended to more than nine nodes (something like 20 or 30 nodes would be

> great) ? Also, has the code been modified in any way from the external

The old external was still in Max's search path. I see now the current version with a variable number of nodes way beyond nine and with colors ! G.R.E.A.T !

> It's nice to have included the "nodes" object in this update but couldn't it
> be extended to more than nine nodes (something like 20 or 30 nodes would be
> great) ? Also, has the code been modified in any way from the external
> version (efficiency or whatever) ? 

please pick up the ppooll/lloop environment, and port it to vissie.. you also have the rui dias building blocks (although it is much smaller than ppooll/lloopp).. which uses the same programming paradigm, so, why not asking him to port building blocks to vissie.. then I have some modules, which I have been lately programming to boost my programming speed.. I would like to port some of them to vissie.. also, definetely "the ability to "save as clipping" to add your own bpatchers to the right-click menu would be cool.".. kinda you have auto encapsulate.. this would be cool if you could create a encapsulate mode, that puts a selected content in a bpatcher and adds it to vissie menu it would be great.. that would require a lot of programming hardwork but would definetely boost the programming speed of most of users, and as I said, fill the gap between low level maxmsp programming, and hi level stuff..

Nodes doesn't appear in the 'Max objects by function' in the documentation.

https://cycling74.com/docs/max5/vignettes/core/max_alphabetical.html

Possible bug:
Nodes doesn't appear in the 'Max objects by function' in the documentation.

https://cycling74.com/docs/max5/vignettes/core/max_alphabetical.html


>"clilppings" seems to be analogous to "macros" in reaktor. I've always wondered when we'd get something like >that to make building with common components quick as it is in reaktor.

Clippings have been around since at least Max 4.

Max 5.1.6 is released...