[feature request] Codebox for max
Hello! You may know my threads complaining about max not giving you the possibility to move away from the mouse and towards the keyboard while getting better with max.(As in many other software it would be the case, thus you can get really fast).
Anyway, I feel like still not many people are demanding this. So here is a new idea:
We have the gen~ codebox. What about the max codebox?
What about a codebox that so one can change smoothly from graphic to text oriented programming, back and forth. Whatever is better for the job. The vocabular should be the same as in max, it really should be max, I don’t mean simply writing Java in a nice box.
Also we all got used to things like the max schedulder and know how max behaves. So writing max would be great I think.
(Maybe I missed something here. And also I still like my original idea more, that we should be able to do more with the keyboard less with the mouse(or ipads ;) ) And please don’t tell me about the toolbox. I love it, but there should be a lot more possibilities.)
I’d appreciate any thoughts!
[accidental phone post…]
js is pretty close to that already, FWIW. It has low requirements and accommodates a lot of extra stuff.
The gen~ code box is simpler because it operates on a synchronous scheduler. (The input from inlets gets updated once per sample for signals) this isn’t the case in Max, and some constructs don’t map as easily. (What does metro mean inside a code box? What does it execute? (And which code paths, etc.)
Yes I guess you’re right. The gen~ comparison is kind of odd I know.
"What does metro mean inside a code box? What does it execute?"
Maybe that’s my point, that’s what would make it different, that the metro should do exactly what it does normally and is not a js function that, in essence, works a little different(I’v heard often that one should avoid js for timing accuracy for example)
But my whole point is that it should be an interface thing only. I hope I’m not already annoying people with these regular requests, but this simply is also an idea that would give more perspective for going more text/keyboard.
I just feel everyday that the graphical approach and the text approach both have their strengths and weaknesses and that a combination(without changing the actual language) would be really interesting and helpful.
Java, for instance, has gotten pretty fast (it’s even getting pretty close to C/C++ in some tests, though there are always going to be some areas where it will be slower and it’s nobody’s ideal language…) I use JMSL in Java and found that its clock was quite accurate in terms of recording events. (was generating note-events from Max, sending to JMSL, recording to MySQL database, and found practically no jitter) The problem with Java inside of Max has historically been the lag at inlets/outlets, not the user code.
Best thing is probably just to hammer on it and see, because if it does work sufficiently for what you need, hey, you’re done. It’s never going to be C, but the scheduler in Max has also been known to drift. (Not that there’s no need for precision, I just think it’s always a good idea to ask yourself what kind of precision you need, and why you need it–can lead to fruitful paths)
I totally concur re: the affordances of patching vs codebox. PM.Ladder~ was written at a point where I was having a lot of trouble with assignments in codebox, so it’s all done via patching instead. (which is also why it looks UTTERLY insane inside, btw; it was just the way I could get it to work)
I’m learning python at the moment and just don’t want to confuse myself with starting off in js, although arduino and raspi have forced me to learn a lot of stuff that goes in that direction. Anyways, I didn’t really want to start a discussion about pros and cons of max vs. other languages.
Just about the interface, isn’t it valid to see this separately?
I mean if I where crazy I could code max in json right?
Let me state it in a more condensed way:
If you start a program with an experimental aim, not (exactly) knowing where it will lead, graphic programming is the way to go.(there are other reasons for graphic programming too of course)
If you know the language very well and know your objective and the way to achieve it, text programming is the way to go, since it’s fast.(if you know language, objective and way to solve the problem, the process of achieving it is totally uninteresting and just needs to get done, fast.)
that’s just an assumption, that caused this thread. Please tell me if you think that’s wrong.
Definitely, I tend to agree. I think one of Max’s greatest strengths is experimentation and prototyping.
I think the intersection of Max with other languages is interesting in a have-it-both-ways manner. I’m really glad not to be writing C DSP code if I don’t have to. (particularly because debugging was such a PITA)
I agree with the original poster on this thread – having a CodeBox for Max would be useful. I am
trying an experiment this Fall with teaching Computer Scientists (and Artists) how to think about
systems and simulation. Max is used as motivation since it has a strong multimedia focus. Most
students are already familiar with imperative text-based languages and so to broaden them beyond
this thinking and toward visual flow, making flow charts in Max would be useful. With a CodeBox in Max,
what is going on. It would be a bit of a hybrid between text and visual, so that the students begin
to think visually but allowing them to put their toes into the water first prior to patching.
and tabs used for line indentation. The 3 output boxes look similar except that while [textedit] and
[message] preserve spaces inside of strings, [comment] removes these.
If the goal is to allow people to enter code segments rather than pull them from files, [textedit] is
fine, and one can have leading indentation when entering text. I have not yet created the proper interface
so that the only visible artifact is the text box, but that shouldn’t be too hard. So far, one sees only
the raw patch providing the code box.
Another possibility is something other than [text] that does not removing leading spaces and tabs.
In summary: it can be done, perhaps with an external or a replacement for [text]. Here is the experiment so
far, in case this is of interest:
----------begin_max5_patcher---------- 1178.3oc6Y01biZCD9yN+JT4S4lwGmdCApc7G5uilNYv1x93FrfAjSSal7eu qj.+1YiwIbjal1jIIlkEztOr6yyJxK2MIXdwyp5.zuh9CzjIub2jINSVCSZN dRvlzmWjmV6bKXiptNcsJXp+bF0yFm8Zko01pBsoN6eTV6DZHtwrd6lLctx3 tOz8FK1ZZsRZr5MY96RkOzBBP+YyoJSMK9Zld8iUpEF+YEwrPhTxEroHVhHT fYzXB7YZXzTDIIDu6pyV5B1h4e6yL7gwqNciasB98prz7.6Id8t6r+ZZOAFs 5ufa62gKUnE4pzpaAav+nvlH.aRhjD3ybNr1HJ97XCUNrXykJZtYnYHKaXwx vHoLlQNorI1BMWprgl7egxlivldW1PFGro91wFxYwFbG8MXgMSAXfFw3b.F3 hNSc93zw7kuf7YEJUuD0jKnGzsVmgn+1CUvwsmZFh3M7TZE7S9TvyxsFusUa 0KLYEZzl50OloM2CN7I6c6E+sDbDtAfQu6uhN7ZlmpWe+AduBceyU.qoydsI 0n1GRp7Z0glIGFo2Cfq6DeZ+Z0l84YZ0hhsZGDPDuA9h4qWTjWT4e1hCSDvW wSsehB87L6mDDAvB.M9G7.dHZkhI7cLvbZbnjIoXITIwc7LTh77UT7QoWprR UpfJozR6ed+sTuMLhGwbXAiDFgkjHP1Vlzo.EYTPmLSQ5sfIraCSxrUzcAKX eIBFfEIIVFeMVHJcTfEChfQ4u+hEZW.yz9UyPhEgDN7cRqx8EAG1vBNV3PsL y7+bzWlitVUlVkZ7LuA+xaojYU054Nw5ctcBYtLgFEm3Hts73wIXIW1EON+h bTS2W5csxOVhif5HFcXZAKSuDX5ozjPFVFKkmsTrKx8cqYEX2npdToSmm67. OfCXBYuBMH6Zi1Ed1qdXXrRlTDSAPLpydXxHswjka2T9QsuDNid5nmjt1QBQ LNXRkJcIpNcSIjKfsUY4pPyyeX65mGyNAlHzN24FYf4+mu0XJ1w+8dlMxxR2 m9DdhqMgI7MHczlfGR0d0s8P97IOqKRBG.LsGCD0vWPfw0SDzHw0FHZfoKVT rYiReNEee5C58Mo7CZukYftptw1LPLUCR7VE9FAdcqR8gh6Onewd4fCybx55 W26mWP26wJuV9rYDvfSW1sZVI71iI6VcP6tU51d+d+aspm5yMpxxXLg41mEG mvintcbcA8Yb+1Lk.JFNuzK4Buwu9UL3tTGvbxKF0EOV6GWgTWrsZQa0b6aV DsOBVppMY5T6SuCc5He9Z1xkJ8gI+lrkkEPEQSLHRngh1DmKcLeT1wl1uhY0 1IFVd4QFFzTgekTY3BG66k75HKd7hmjdDOzwCeH8JdRFu3oOkOjwCe5S4CQN dkOr973hNtwC4ZwCY7hGZevmQLdHC.a3ID6bg6+REmvOkS2Y5G.mduxB16IK XI9wUO5Hgf8cpVVSeTY3XRK2GdGJa7hGQOhmwiFjv94Jb5knk3mr34sV83m1 Msr7IUUcy8zEJvNe9leHd2tBfNds+P2f+AUpmxZ826PZELstAFUeakex5mSD vb0v575c+KD+OhhF -----------end_max5_patcher-----------
Forums > MaxMSP