[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)