[feature request] Codebox for max

Oct 23, 2013 at 9:48am

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

#268909
Oct 23, 2013 at 12:58pm

[accidental phone post...]

#268933
Oct 23, 2013 at 1:07pm

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)

#268934
Oct 23, 2013 at 8:07pm

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.

#268958
Oct 23, 2013 at 8:37pm

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)

#268961
Oct 23, 2013 at 8:50pm

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?

#268962
Oct 23, 2013 at 8:59pm

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.

#268963
Oct 23, 2013 at 9:20pm

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)

#268965

You must be logged in to reply to this topic.