[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.)
YMMV, though, just my two cents. There's times it would be useful, but I don't know that it'd be that more useful than a JavaScript implementation. (And a library replicating max functions could e written in Js)
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.
Javascript performance has gotten a lot better, AFAIK. I'm not doing highly time sensitive stuff with it, however, so I'm not the best person to ask on that. It's also important to know how the timing accuracy is affected. Is it lag or jitter?
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)
Also, you have all sorts of languages starting to target Javascript as a platform, so that's an extra bonus for JS. (for example, ClojureScript gives you Clojure in JS...)
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)
Thanks peter,
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,
one could tie together boxes with Javascript and use control flow (e.g., bang) to simulate visually
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.
I created a patch that outputs a Javascript file to 1) textedit, 2) comment, and 3) message objects.
I used [text] to read the javascript file. Unfortunately, [text] discards useful leading spaces
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:
I'm new to Max, I have experience with CSound and general programming languages, I would like to add my vote for this, my motivation is exactly the same as WOYTEG, I moved to Max from CSound because I missed the unguided stuffing around with digidesigns TurboSynth, but when I know what I want to do, the graphical stuff gets in the way, its would also be nice to be able to do the big brush strokes graphically connect modules written in text code. I will look into the Javascript stuff though, but it would be nice to take stuff I have worked on graphical and switch over to text code.