I don't feel any freedom when while working in max

Feb 11, 2013 at 3:33am

I don't feel any freedom when while working in max

I bought Max aproximately year ago and I feel more and more disappointed by it.
All except the most basic (arithmetics etc) objects seems as if they were not made to offer you as much freedom as possible when patching. They seem to be made with some specific purpose which was in head of some c74 developer. I usually know EXACTLY what I want to do, but Max rarely allow me to do it. It only allows me to do it “their” way, or try like 23 workarounds (in some cases took me literally MONTHS to do that) just to find one that is least distant from what I originally wanted,… or sometimes I did not even find a single solution I could use (except using java or making my own objects in C…but then there would be no point of using max just to interconnect my own pieces of code …)

#66444
Feb 11, 2013 at 3:54am

What’s an example of something that you’ve wanted to do? I’m not picking; I’m actually curious.

[ddg]

#239184
Feb 11, 2013 at 5:01am

IMO Max/MSP/Jitter/gen~ has a deceptively steep learning curve. Just saying…
And yeah.. what is something you want to do?

#239185
Feb 11, 2013 at 5:33am

This is interesting to hear/read. I always thought that Max was quite open to different ideas and methods of accomplishing a goal. I can quite recall once where I felt boxed in by limitations. Interesting also to read that each object seems as though it were tailored to a process that a C74 developer had in mind, I had never thought of that!

To echo the others, indeed, what is something that you have in mind that you feel you cannot do?

#239186
Feb 11, 2013 at 10:10am

or sometimes I did not even find a single solution I could use (except using java or making my own objects in C…but then there would be no point of using max just to interconnect my own pieces of code …)

Why not? Actually, I do that a lot. I consider myself far better in ‘plain text’ than ‘visual’ coding, but I just can’t ‘glue together’ the stuff that easily with, let’s say, C++, than with patching. The key is: choose the tool that is most appropriate for you. If you don’t find your way with the built in objects, but you are a good coder, then maybe that’s the more appropriate way for you as well.

My 2¢.
Ádám

#239187
Feb 11, 2013 at 2:55pm

Somewhere I’ve read, that when Miller Puckette started programming Max he had exactly that in mind.
He wanted to have a framework that would enable him to glue together modules written in C.
But after a while he had so many modules written, so that Max could be used to create something without writing new code.
But that wasn’t his intention in the first place!

#239188
Feb 11, 2013 at 3:35pm

@dnk777, I am curious about this as well. I feel very comfortable in Max, but then again I have been using it for a long time. I don’t feel limited at all. The fact that Max has an SDK, means I am in fact UNLIMITED. There is no idea that I can not implement. I think what I am hearing in your message is your frustration with your unfamiliarity with the language. When you are learning a new language, one can expect that it will take time to learn how to express ones thoughts in that language.

I too would like to know what it is you are trying to do. Maybe we can help with patching strategy. Ultimately, if you want total freedom, you should write your own applications in C++. Just get ready to do a whole lot of work…

#239189
Feb 11, 2013 at 4:19pm

A great measure of success of a product is its use beyond the original design or intention.

#239190
Feb 11, 2013 at 5:55pm

freedom is relative. what are you comparing max against?

#239191
Feb 11, 2013 at 6:34pm

Funny because I often feel the contrary. I want to do something and find convoluted ways to do it. Then I discover there’s one object that allows me to do it much more simply.

#239192
Feb 11, 2013 at 10:07pm

+1 for Stephane Morisse’s mentality and +1 for dhjdhjdhj’s sentiment.

Max is what it is, and I enjoy the challenge of realising ‘non-typical’ projects with it. Max meetups and conferences rarely show users using it for anything more than audio performance/control sequencing, but on the occasions that they aren’t doing those things, I can almost guarantee they’re creating some of the most interesting and unique work out there.

#239193
Feb 11, 2013 at 11:04pm

There are plenty of simple objects and plenty of more complex ones. Some of the more complex ones are more “limited” in that they really are designed to do one thing or a small set of things, at least if you use them the way they were intended. This is “sort of” true for the simple ones too, but you usually patch together several of them to accomplish your larger goal, so the number of possibilities starts to explode…

I agree that I’ve spent hours struggling with some convoluted ways to do something, then later realize it was dead simple, whether there was another object that did it already, or I was just patching badly. Lots of order-of-execution issues too, until I found [trigger], probably the single most important object out there, at least in many ways.

I’m an OK coder and have utilized this with some javascripts, and in some cases, this is a great way to go. But I do 99% in the patch world, preferring how it “reads” and that there’s no intermediary file–your changes are immediate. Also, visually, you can make code relatively pretty…but with some effort, a patch can look truly stunning!

#239194
Feb 11, 2013 at 11:35pm

The only time I’ve ever had to drop into Java/C++ was eventually made moot by Gen (though it took me a long time to wrap my head around how to do what I needed).

I think one of the things I love most about Max is those ‘eureka!’ moments that happen quite often, even once you’re very experienced with it (I think I’m nearing 8+ years with it).

I’ve often gotten something working the way I plan it to function, and then recognizing that it’s horribly clunky – but putting it together once, and thinking about the problem in such minute detail has made it that much clearer to me – building it again it suddenly becomes about 75% less complex, and much more elegant.

I’d heard the term ‘elegant’ in relation to coding on these forums first at some point, and Max lets you be as elegant or as clunky as you like. Sometimes the most elegant solution is in fact to just code a new object, but Max makes that astonishingly simple (especially being able to code Java directly within the patch!)

That said, there are some objects that I would love to have more options for – mainly UI objects (I haven’t figured out how to code my own UI objects yet…) Numeric input box parameters (and the ‘tab/select’ function) feel pretty clunky and obviously have a lot of backwards-compatibility to keep in check. Max 5 changed the game in term of max UI coding, and it feels like some of the UI objects haven’t really kept pace with some of the other UI features.

This rant has made me decide to seriously look in to rolling my own UI objects, though – Max always keeps me on my toes!

#239195
Feb 12, 2013 at 10:11am

If there’s one thing I don’t feel when using Max it’s “limited”. I can’t imagine the wealth of ideas one must be working with in order to feel limited by such an open-ended application…

#239196
Feb 12, 2013 at 12:16pm

Each language have a paradigm ; you must know it. Unless you want to experiment frustration. MaxMSP is a glue for C code (at least it was at the beginning). A good job is done by the c74 team to make it friendly for all kind of users ; but it remains things you should learn … I don’t feel any freedom when while working with… a computer !

My 2 cent ;-)

#239197
Feb 16, 2013 at 3:01am

first of all, i worked with reaktor and puredata the last fourteen years…i can still sure learn a lot, but i do understand the paradigms of visual programming.

Mushoo: I hate Java. And you are right, it’s the UI objects that are most clumsy. Seems that not a lot of people realize, that musical instruments are from a BIG part the interface. You could have the best audio engine, but if you are unable to control and using it is not comfortable, then that instrument just sucks…

Roman Thilenius: I compare MAX, to what it could be if the developers would spent like 15 minutes more thinking about features of some totally fundamental objects and another 30 minutes more writing them. It would for sure save me months of my time/life..

but ok, here’s one example which i try to do and i’m partly unable to, and partly i’m able to but the cost of workarounds is just CRAZY
I talk about the pattrstorage and pattr objects.

1) the pattrstorage hierarchy is not defined by programmer, but by the object hierarchy. that’s just totally absurd and it makes my patch such a huge mess that i puke everytime i open it. i’ll explain why – i have two groups of UI objects on one level, and i want to recall them separately (instrument number and solo/mute buttons shouldn’t be changed when just another pattern is recalled for example).
so yes, there is this useless subscribtionmode, which is useless because then you would have two pattrstorages and you could not save all the preset info into one file – ugly (i would live with that if THIS would be the only compromise, but there are hundreds everywhere I look, and i’m trying to make myself an instrument which i’m going to use for hours and hours, so i want to make it user friendly)
so the only solution to my problem was to make two superhuge subpatches, and put the pattrs objects for objects from one group into one subpatch and pattrs objects for the other group into the other subpatch, so you can recall them separately using the “recall instance1::group1″ or “recall instance1::group2″ messages. So now I have an object with 140 inlets and outlets and wires from it going all around the patch. That’s quite an INsANE price for me to pay for just a simple working preset managemnt!!

2) read/write dialogs – the ones opened by pattrstorage are just useless, because i cannot manually set the load/save path. so i found these opendialog and savedialog objects. useless the same way!! i can’t see how anybody writing a opendialog/savedialog objects could NOT think about allowing the programmer to set the path manually. i just can’t imagine such thing happening. i’m sorry. as a result, if i make myself an instrument in max, which i use every day, it also means that I waste my time browsing my harddrive everyday for minutes, because I can’t tell those stupid objects that i don’t have any of my files in some stupid DOCUMENTS directory. Totally stupid. Using my MAX instruments i’m going to waste HOURS every year because of this and I would really prefer to spend those hours making musick and not browsing my harddrive.

3) pattr’s binding thing – that thing is just total nonsense, killing the whole “data flowing from outlets to inlets” concept + totally useless anyway, because look at the 1) !!! i already have my pattr objects hidden in subpatch, so i have to connect pattr objects to UI elements throught inlets/outlets of the subpatch, so can’t use the pattr’s binding outlet anyway (it works only directly)

4) so you can’t use the binding. you use the first inlet and outlet of pattr. cool. unlike the binding thing, here you need to take care of the feedbacks somehow. using the THRU arguments seemes like a solution, but please, are you serious telling me, that i when i disable data going thru, the data doesn’t go out of pattr object even when recalled by pattrstorage?? Why? What does recalling have to do with data flowing THRU? I think I have around 180 of pattr objects in patch i work on at the moment. Trying to do things my way as much as I can, my patch is already a pure mess (because of the “1)” point) and now because of these stupid “features” and rules, like “switching off THRU makes you need to bang everytime you recall” (why why why???) I should be adding special “receive recall_BANG” object to each and every pattr object in my whole patch, just so i can bang it after each recall. WHY DO I NEED TO GO THROUGH ALL THIS JUST TO MAKE ORDINARY PRESET MANAGEMENT + PROJECT FILE SAVE/LOAD ??? It seems that ignoring the pattrstorage and pattr objects from the beginning and doing it all by myself would be probably more effective, because using these objects that are supposed to make my life easier (that’s why i bought max) it seems that the “WORKAROUND TUMORS” in my patch grew larger than the meaningful part of the patch + I bought max, because I wanted to transform my ideas into working piece of visual code MORE EASILY, but instead I waste more than 50% of my time by taking care of disabilities of these objects…

Like if I already wouldn’t have enough TUMORS around other objects, like all the numboxes (float live numboxes displaying int, going into [round], going into [change], just to have some reasonable sensitivity of the numboxes and not 1px = 1 of the numbox value, which is just crazy for setting anything accurately), .. . .etc etc… I mean, the stuff above are issues with just two objects, but there are so much more of these CRIPPLED objects in MAX.

#239198
Feb 18, 2013 at 2:08am

another example I encountered right now:
I use some numberboxes (int or live.numbox. whatever) in literally all of my patches.
At the same time I wish to use keyboard shortcuts in my patches. I wish to use number keys (1 2 3 4 5 6 7 8 9 0) as shortcut keys to.
Seems impossible in max, while you are unable to have numbox/int deselect itself after you write value in it and hit enter key (which would be in my opinion 100% reasonable behavior. why would i want the numberbox to stay selected??). so it stays selected all the time (until you select something else with your mouse), so when you try to use the keyboard shortcuts that are numbers, it doesn’t do what it should, but rewrites the last numberbox you used.

sure I can just set the shortcuts to other keys, but i don’t want to, while they fit very to number keys nicely / are ergonomic there, etc etc. and the point is, that having the number keys as shortcuts is just what i would like to do and MAX doesn’t let me do it – that’s the lack of freedom i was talking about. It’s just such an awful amount of compromises everywhere I look in max, that It makes me feel like i picked a wrong tool. Max is not good for creating anything serious, it’s only good for creating toys or stuff when you don’t have to care about details / stuff where you don’t mind compromises (loads of them)…

#239199
Feb 18, 2013 at 4:27am

I agree that there are things to be improved, and sometimes you have to do those “tumor” workarounds. However, that’s the case with any language which has higher-level functions that do most of the work for you—they can’t be infinitely flexible. For true flexibility you’d need to code your own things, which is of course a big trade-off with time and the learning curve.

I find most things in Max highly flexible and customizable (especially the UI elements with so many appearance and function attributes), but yes, I often find myself doing various workarounds for things. I think it just comes with the territory. That said, often the workaround comes first and a better solution comes later.

About pattr—wouldn’t autopattr clean things up? I never use pattr objects at all. I just exclude things from autopattr if needed and/or name things manually first, eliminating the vast majority of wires. Maybe your setup requires pattr objects for some reason, but I don’t know what that would be.

I definitely understand the frustration when working with two sets of objects which you want to store/recall separately, yet save in the same file. I just have two pattrstorages and use two separate files for saving presets. Everything can be automated with loading and writing the files anyway, so it’s no difference to the user, and it makes things much simpler to program.

And to your numberbox issue, it’s one that used to come up a lot—I like using number keys to control things too. There’s a “select” message to [thispatcher] which will deselect any key-focus area like numberbox, textarea, jit.cellblock, etc. So you just need to use TAB to enter the number and you can auto-deselect the box:

– Pasted Max Patch, click to expand. –
#239200
Feb 18, 2013 at 5:24am

Here’s some more thoughts on pattrstorage, with an easy way to subscribe and unsubscribe entire banks of controls. In this case I use incrementing scripting names, so it can be done programatically with [uzi], but if you had unique names for all your controls, you could still just have a big message box with commas to subscribe/unsubscribe all the names with one click or bang.

So, just store some presets with various configurations (both banks, each bank separately), and then recalling will only work for the current;y-subscribed ones. I like the color-coding in the storagewindow which alerts you to a stored slot that doesn’t have values for all the objects.

Anyway, just some ideas. Tt doesn’t fully solve the “one pattrstorage/multiple sets recall separately” issue, but it could be made to work automatically, so that’s something…

– Pasted Max Patch, click to expand. –
#239201
Feb 18, 2013 at 6:44am

seejayjames: first of all, thanks for the number-deselect-tumor idea. i’m probably going to implement something like that to the 150 numberboxes in the abstraction (which has 5 instances in the main patch, so 750 numboxes really. quite a waste of resources, but what can i do).

regarding the autopattr – i’m not sure. i thought about it, but i couldn’t find a way how to use it in my situation. Beware that we are talking about the pattr objects that are hidden in the subpatcher (so that i can control it separately), so I believe that even the autopattr would have to be hidden in a subpatcher and i believe that autopattr don’t look for UI elements in his parents.
(another, much less important fact is that it’s more efficient for me to use pattr than autopattr, because of the tumors i use for adding sensitivity feature to each and every live.numbox. I use FLOAT live.numboxes set to only display INT, so i’m able to set 0.125 increment per 1px of mouse move, while it’s internally float, but also gives out float, so i have [round]->[change] tumor after each live.numberbox and it’s (not necessary at all, but still) better to take the value to pattr only after the [change], while going from pattr directly to live.numbox)

#239202
Feb 18, 2013 at 9:21am

I’m sorry, I don’t have time to read everything here, but I have been surprised by the subject of this topic and I just want to say I feel totally as the opposite of this.

Max6 is for me the total infinite freedom I looked for for years.

#239203
Feb 18, 2013 at 10:26am

are you aware that you can paste-replace things ? that and the encapsulate/de-encapsulate shortcuts, as well as the Nathanael Decaude’s Max Toolbox, do save me a lot of time when i need to redo thigns because workarounds. That said you indeed need compromises with Max GUI, but you better bear with it and learn its inner beauties than fight against windmills. There is the dialog object too, that and savedialog and other things could probably approach your needs. Sure it’s not as streamlined as a linux-style save dialog, but it’s still something.

#239204
Feb 18, 2013 at 10:42am

Concerning the user interface part, the UI objects might be clumsy, but to my understanding that is because the computer itself is clumsy. The number objects are from a decade in which GUI was invented, sort of. Instead of adjusting the numberboxes for the new era, throughout the development of max a diversity of approaches have been introduced for building smarter UI’s. For instance, lcd, pictslider, matrixctrl and jsui.

When you want to build an interface where 750 values need to be provided by the user, I think you have to come up with a good strategy to deal with that vast amount of required data, or the user will not start using it at all. Anyhow, I am sure that such an interface is not coded in a few lines of C++. The amount of work you need to do reflects the effort that is required to build up a good interaction model, regardless the platform (maybe iOS is an exception, if you’re willing to give in to uniformity). To my opinion max makes the job relatively easy when compared to other platforms.

Allow me to provide an example which uses the matrixctrl object. The advantage of this example is that behaviour and looks are maintained in one place only, therefor it can easily be adjusted and extended. Moreover, regardless how many values it holds, it represent only one entry in a preset.

– Pasted Max Patch, click to expand. –
#239205
Feb 18, 2013 at 4:16pm

Wow—hats off to that one, jvkr. A ton of clever ideas in there, and lots of possibilities with the matrixctrl/lcd combo. Thanks for that!

#239206
Feb 18, 2013 at 5:41pm

well… Max seems so “free” to me that I’m positively agoraphobic every time I open it ;-)

#239207
Feb 19, 2013 at 12:24am

mradentz: I don’t care how many useless options I have. I don’t start max to look around and thing about what I could do. I run max to turn my (very clear) vision in reality. And if I’m not able to, the huge amount of useless posibilities doesn’t help me at all… (as clueless as during elections…)

jvkr: i ended up using LCD for most of the UI, but not for the numberboxes. that would be too complex thing to do.
Regarding the 750 values – my patch consist of 5 blocks, so the sum is ~750, but in practice it’s more 64 x 10 + some small things.
and for the 64×10 things there is a small toolbox using which you can edit it in a more comfortable way (than typing each value).
Using keyboard to navigate is a great idea too. Would implement it, but at this moment i don’t feel like changing anything in the patch. i’ll just finish it as it is, beta test it, release it and start working on a next version in some other language, where I won’t have to waste so much time with workarounds and testing 5 different compromises for each thing impossible in max.

btw beware, that when i’ve reported a bug of LCD, cycling told me that LCD object is not supported anymore! (and thus the minor bug won’t be fixed.)

#239208
Jun 11, 2013 at 12:04pm

I don’t care how many useless options I have. I don’t start max to look around and thing about what I could do. I run max to turn my (very clear) vision in reality. And if I’m not able to, the huge amount of useless posibilities doesn’t help me at all…

Then why not just use C++ or whatever and get on with it? Max seems to be a pretty open-ended high level programming tool to be using for your “very clear” visions that don’t seem to come to fruition. I certainly understand frustration but… wow…

I look at Max as being “fun to use” rather than a professional programming toolkit. There are obviously way lower level and more flexible programming languages for what it sounds like you are trying to accomplish.

#252434
Jun 11, 2013 at 1:58pm

I must admit, it would be nice if more objects had their source code available to the public, especially the objects which aren’t supported anymore. That way, you could make those small tweaks to functionality without having to recode all the behavior yourself. There are some examples in the SDK, but more would be nice.

So here’s a question for Cycling: Would it be possible to release source code for objects which are no longer supported? Or just more objects in general?

#252451
Jun 11, 2013 at 3:19pm

pd

#252457
Jun 11, 2013 at 11:16pm

Interesting.. I’m new to Max and I must say – I have never felt such freedom with a piece of software – ever. In only a short time it has had a massive impact on my life. Maybe I just don’t know better.

That said, to keep with the spirit of the thread, there have been a few things that I have found irritating and confining. At the top of my list:

1. The lack of detailed documentation.

2. The lack of a scrolling zoom (which zooms to the mouse pointer) is a huge disappointment. For some reason the powers that be don’t consider it very relevant.. yet I can’t think of a single significant piece of software that is graphical in nature that doesn’t have the feature. It significantly impacts workflow.

3. The limitations for outputting finished work into a greater variety of platforms – particularly web and mobile devices.

But like I said – even with those criticisms, I can’t speak highly enough of Max. It has changed my life.

#252472
Jun 12, 2013 at 2:29am

Maybe I just don’t know better.

it’s not “better”, it’s a choice, freedom is not always a good thing, i mean restrictions can create freedom, and it’s the case with Max, there are many available awesome ui things, and that’s his strength, and that’s more closed than textual programming where you have to do all the ui yourself, but it’s all available without you having to do it, and i daresay it’s way better than what i would do if i had to do it myself, and i think it’s the same for many people… Then you can less think about the ui and gain some time, if you don’t concentrate on what you *can’t* do, but rather on waht you *can*.

And about

1. The lack of detailed documentation.

er, i have to say i have hardly ever seen a piece of software so deeply and smoothly documented !… have you an exemple ?
zoom : scrolling zoom would be cool. though usually each element is the same size, one rather use encapsulation to gain place than smaller objects. there was a navigate zoom thingy you accessed with a button in the tools bar, but it seems the button disappeared ?
(3rd point, well yes. though export code with gen is possible.)

#252480
Jun 12, 2013 at 3:13am

Hello DNK777, hello all

I think, if the tool does not correspond to your expectations (and purposes), but you see other tools, better fit your field of interest you should use those better tools – that’s all. In this case – and most of cases – “text programming” will be more flexible to the patching, but with cost of time and work.

Actually the sense of freedom in programming is highly individualized. For example I feel free and comfortable, when I can concentrate on the core part of my projects and do not bother with details (UI, handling files and configs, etc.) – this is what I like in Max (if I want to do something new I can simple develop my own objects – or gen code, or something – and join it together with ready made components – this is fastest method I can imagine). From another point of view I see some restrictions in visual paradigm itself (and in the implementation of this paradigm in Max, of course), and for this reason I was never dropped “traditional” programming (but, to say the true, if you are working with Xcode you’re doing a lot of visual programming too – is it “traditional” or not?).

And back to technical issues:

- the problem with managing and storing patterns may be partly solved by using .maxproj format – when using .maxproj you can better manage additional files within your project (stored patterns too), especially put them all into selected folder (someone advised me to this solution in another thread on the forum just a few days ago – and it’s really good good in my personal opinion) – so, thanks of that, you can keep clean main folder of your project

- I think, if the project is containing hundreds of UI object it will be always hard to manage – doesn’t matter what language or environment we are using to create this project…

cheers

#252491
Jun 13, 2013 at 11:42am

i have to say i have hardly ever seen a piece of software so deeply and smoothly documented !… have you an exemple ?

There are quite a few examples actually. One that comes to mind is the custom pics for UI objects (matrixctrl, etc.). I eventually got it working with great results but it took me a lot of trial and error to wrap my head around it. I also find that many of the objects lack detailed references about available arguments.. and even when they do mention them, it all seems like a draft or first iteration of a manual.. like the essentials have been covered, but not in enough detail. As a relative beginner in the world of programming, certain references are quite obscure. There is a gap between seeing a terse reference table and knowing how it is applied. That’s my experience anyway.

scrolling zoom would be cool. though usually each element is the same size, one rather use encapsulation to gain place than smaller objects.

Well, zooming is very different than encapsulation. The ability to zoom into a specific part of a patch is useful for many reasons.. the least of which is reduced fatigue and eye strain, less incidence of unwanted appearance of the object wheel when configuring objects and greater overall mobility within the patch. Seeing the patch as a whole is very important, as is working on parts of the patch. Transitioning between these two fundamental perspectives should be as seamless as possible. I enjoy that freedom in all kinds of software.. from graphics, CAD, publishing, web design, mind mapping, whatever. Most software that deals with the creation of large interconnected graphical compositions allow the user to zoom in and out of the active workpoint with a simple scroll gesture. I’m just sayin’…

#252663
Jun 13, 2013 at 2:11pm

i agree on both those points, though not entirely – about the doc, you have to compare to some other things to realise how much it is accessible ; even if sometimes there is a point of obscurity in the ref pages. And the zoom you’re aware you can zoom in/out with cmd + and – right ? though the mousescroll would be better, i agree once again.

#252687
Jun 14, 2013 at 12:11am

I’m aware of the +/- scroll.. but it’s not just keystroke vs. mouse. The zoom function doesn’t zoom to the cursor/pointer.. so it’s multiple steps just to zoom to where I’m working.

#252715
Jun 15, 2013 at 7:18am

@METAMAX
if you select an object, the zoomfunction via cmd (mac)/ctrl(pc) and + zooms on that selected object, holding it centered as well as its area.

May this helps
Best,
Helmuth

#252847
Jun 15, 2013 at 11:18am

if you select an object, the zoomfunction via cmd (mac)/ctrl(pc) and + zooms on that selected object, holding it centered as well as its area.

Helmuth thank you.. I don’t how I miss that. I guess I’m just used to other software that simply zooms to the pointer location. I can live with this though.. It will save me a lot of time in my workflow.

#252858
Jun 15, 2013 at 11:01pm

Interesting thread. But why bother?

Max is just one of many environs out there, each one built for a different ‘kind’ of people. Some folks have a very visual brain, others have an object-oriented brain, still others have a procedural brain, and most of us have the ability to use both sides of our brain in some weird mix which gives us a bunch of trouble AND joy in any environ :D

Just go find another environ.

I just moved to SuperCollider recently. Not because I hate Max, but because I love SuperCollider. It seems more straightforward to me, the very first thing i notice: i don’t have to worry about setting “Overdrive” and “In Audio Interrupt” on with small vector sizes chosen to get tight sync, SC defaults to making it easy for you to do everything within one thread, and only break apart from there if you want to(this is great from an audio standpoint).
Another thing, it’s easy to manipulate large sets of data:
in Max, if you want 512 buffers(for some reason), you either have to copy and paste buffer~s til you’re blue in the face, or you can create an abstraction(perhaps with some ‘thispatcher’ scripting to arrange them in graphical space if you care about the visual arrangements within this graphical environ), then save it, then instantiate it in your patch.
But in SuperCollider, it’s as easy as something like this line:
crazybufferarray = 512.collect({|i|
Buffer.new(s, numchannels: 2, bufnum: i);
});
(In fact, it gets even easier than that, because Buffer has a special method called “.allocConsecutive” which has been around for years longer than the polybuffer~ of Max/MSP…)
But i bring this up because after seeing this in SC, i realize, it’s not a bad thing that Max is this way, installation artists and other folks who rely on polling for human interaction, which cannot be clocked ideally using a samplerate, benefit from this open-ended approach.
Other folks who like to brainstorm their designs visually, will benefit from having to visually place their buffers, or else think visually about designing an abstraction to help them instantiate many of them.
Everything is still possible, you just need to have more of a left-brain instead of a right-brain(or i may have that backwards but you know what i mean).

These complaints become subjective the more you gain familiarity with a diverse set of tools, instead of just focusing on the idiosyncracies of just one.
An example: DNK777 makes a weird complaint about defocusing number boxes.
To me, this is nonsense. Because to enter a number into the number box, you have to click on it with your mouse anyways, so obviously, it’s ridiculously easy to click on the background of your patch to defocus it immediately after(that works and is exactly as expected). If it did NOT defocus when clicking on the background, but it did when you clicked TAB automatically, some other person who’s new to Max would be in here complaining that it should defocus when you click on the background.
But then to top it off! There IS a way to get the other not-so-obvious functionality that DNK777 describes using ‘thispatcher’.
Another example: I’ve also heard many folks complain about wanting to create 2 sets of presets from a bunch of UI objects on the same level.
I do this simply by using the “getstoredvalue” message to pattrstorage, and simply group those messages. It’s actually quite easy. It can be a bit explicit and tedious, but it’s there. And you could also use ‘thispatcher’ to make it even easier(script it so that it parses everything out using the “getsubscriptionlist”…).

It’s All There! We just need to get to know how to work the overall language of Max in combination with itself rather than getting wrapped up in the functionality of one object as it stands by itself.

And this, my uninterested readers >:D, is the reason why such complaints hold no water: you can’t complain about a ‘language’ if you don’t understand how the overall vocabulary of a language can form a ‘gestalt’ of ever-changing and open-ended functionalities.

This statement: “They seem to be made with some specific purpose which was in head of some c74 developer.”
Is just plain stupidly presumptuous. REALLY?!
You think some C74 developer gizzed all over himself when he came up with phasor~?! FUK NO! He probably thought to himself, “oh good, i reinvented a wheel which every other environment or audio language in the past has had so that some new recombinations of these old ideas can be formed more easily within this new environment of Max, time to move on to the next thing!”… or something like that, and then went about trying to create more of this general-use functionality that has already been proven by the entire history of media and its artistic/creative manipulation.
When you presume these ideas are simply specific to one developer, you are underestimating the importance of history, and shortchanging yourself from learning why these specific functions come into being first and foremost. Furthermore, even if some developer believed selfishly that they themselves DID have a specific idea individual to themselves, they would be kidding themselves. The very early Max was determined by David Zicarelli’s port of MillerPuckette’s work at IRCAM, who created initial functions based on what he had seen of Max Matthew’s and other’s work. When you arrive at today, it’s no longer up to an individual developer: whatever gets added is greatly determined by everything that came before and how functional/useful it will be in that larger context.

Try to get to know the whole picture more comprehensively, before you criticize any of its parts.

#252890
Jun 15, 2013 at 11:07pm

+1 to what TokyoRose said!
even though he/she always acts like a whiny little bitch
(…and.. uh… we happen to be the same person >:D).

#252891
Jun 16, 2013 at 2:52am

you will be pleased to hear that i disagree, a numberbox should always defocus when entering something and pressing return.
in opposite to text fields, where return should lead into something else.

in an all-picture or all-lcd interface it is pretty confusing that numbox doesnt.

or imagine you have a GUI which only consists of number boxes. where do you click to defocus?

#252899
Jun 16, 2013 at 2:52am

I moved from SuperCollider to Max mainly to take advantage of the integration with Ableton Live and the convenient control features of Max since it has UI objects embedded in the code. However, I find the execution model of Max rather tricky compared to SuperCollider. Programming in Max appears to be easy at first sight but sooner or later you need to know some low level details about event priorities and threads which unfortunately are not well explained in the documentation.

#252900
Jun 16, 2013 at 4:08pm

+1 2 wut Broc said.

even though, Ableton is too advanced for me, so i’m sticking with SuperCollider.

@TokyoRose
“All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy.
All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy.
All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy.
All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy. All SuperCollider and no Max/MSP makes Jack a dull boy.”

(No really: i actually typed all that out.)

#252954
Jun 16, 2013 at 4:22pm

@RomanThilenius
you wrote: “you will be pleased to hear that i disagree”

indeed! you help to prove my main point correct that these matters of user-disagreement are subjective and therefore a bit trivial(only trivial in the sense that if C74 doesn’t make a change in 10 years or more and still succeed so well, the disagreement between users can be determined trivial ;D).

i could argue til i’m blue in the face that in a graphical programming environment where mousing is ubiquitous to development, clicking on the background is a perfectly rational instinct to fall upon and has proven effective enough all throughout this environment’s existence to remain as is. and our egos will clash insisting that, no!, the other’s instinct is not instinctive enough, never understanding how 2 people’s nature can be so different, eventually being locked in a quandary over a moot point that leads us away from the real truth that:
“people are people so why should it be that you and i should get along so awfully?”

no wait… whut? where’d that come from?! i must admit, i’ve been playing devil’s advocate here for so long that i’ve started playing it with myself and now cannot figure out what i’m really trying to say, which is actually a pleasant sunday surprise so i will go back to my porto-potty to rest awhile and drift into lazy reveries of lollygags from times past :)

#252956
Jun 16, 2013 at 8:58pm

Interesting thread for sure.

What about a boolean attribute in numberboxes: Return defocuses? Possible? If so, everyone’s happy.

Languages differ in so many ways. I for one feel tons of freedom in Max. The debugging and UI capabilities trump pretty much any other environment I’ve seen…where else do you have such detailed control in real-time? Or such ability to monitor what’s happening via message boxes, the Max window, or text files? And of course, you can go to js for things that work better in code…

That doesn’t mean it’s perfect, or that all the help files and documentation are fleshed-out as they could be…these things take a ton of time to write. I for one would like more details in the help files as well, covering more of the messages, or showing more fun tips and tricks, which often lead to great new ideas. But overall I think the docs are really solid.

Anyway, glad to see the progress through Max 5 and into 6…looking forward to continued development. +1 on mouse scroll-wheel zoom…should be doable via an abstraction, but having it built-in would be great.

#252958
Jun 17, 2013 at 5:16am

@DNK777 wow, a lot of replies to a post which was in the first place one of a troll (sorry…) who turned out not to be one really, but was mainly frustrated, as I am often when I try out a new tool (happend 100% every time I opened supercollider…;-)
I will focus on your posts from February which finally after 5 days! explained what you think is impossible in Max.
All that what you think is impossible, is possible of course.
And much easier than you might envision, but you need to know some tricks.
Those do not develop within a few weeks.
First think about your user interface in general. 150 numberboxes times 5 is most likely overkill for any other user than yourself. There are a lot of UI objects to simplify things like matrixctrl, multislider, jit.cellblock and a ton more. Certainly much more than Pd can deliver…
Your points:
“1) the pattrstorage hierarchy is not defined by programmer.”
It is not true, it just takes the burden from you to be forced to define it. You can define priorities if you need to. Its documented… I almost never need them.

“so yes, there is this useless subscribtionmode, which is useless because then you would have two pattrstorages and you could not save all the preset info into one file – ugly”

I might agree to a perspective to call this ugly, but it isn’t at all useless. It is quite useful to have separate preset files for different levels of abstraction. Within the main preset you would still be able to recall everything at once. Sometimes it is necessary to get rid of old habits to be free…

“So now I have an object with 140 inlets and outlets and wires from it going all around the patch. That’s quite an INsANE price for me to pay for just a simple working preset managemnt!!”

At this point I can only say “try harder to find a simple solution…” What you did was insane, absolutely, instead of patching for hours hundreds of cords, just sit down and think about structure, information flow and alike. I bet the whole world against it that there are much simpler solutions…

“2) read/write dialogs – the ones opened by pattrstorage are just useless, because i cannot manually set the load/save path.”

completely wrong. its easy to set absolute paths, and with the aid of the path message to thispatcher you can even create relative paths to your patcher. I never need to browse while making music ever.

“3) pattr’s binding thing – that thing is just total nonsense”

Its one of the most powerful features of the pattr system. If you don’t stop maxin’ you’ll find out for sure…

“4) so you can’t use the binding.”
I use it happily all the time… Not more to say about that.

And really use autopattr. Its dead simple, a complete nobrainer…

Next time you are frustrated and do not find a solution easily, post politely a question and we will help you to avoid time consuming “workarounds”…

You did trigger the emotions of those who love and work very efficiently with Max. You seem to have some experience with other tools which as well did not give you easy solutions to your preset management. Beginners usually do not start out with the most complex monster patch. I still do not know what kind of application you want to build, but it is possible including an easy preset management with Max for sure…

Stefan

#252985
Jun 17, 2013 at 10:46am

For simple patches an “all Max” style is ok, but when your patch becomes more ambitious there comes a time you have to ask to yourself: Is Max the right language for me?

For example I understand the OP frustration when dealing with pattr objects, preset management etc. To me it’s just clumsy, I couldn’t figured it out too although other people here with more experience then me probably disagree with me. It all comes down to whether you are willing to spent time to do it the Max way or not. I decided to not, life is too short.

So I’ve chosen a hybrid approach. I use Max for it’s UI, timing and midi-io objects, but everything in between is handled in Java. In many ways a high level language like C or Java is just far easier for certain programming situations. I was quicker learning Java (at least the parts I needed) then figuring out all kinds of “workarounds” when using Max.

#253008

You must be logged in to reply to this topic.