Embedding other languages in Max is frustrating!


    Mar 04 2008 | 7:13 am
    There's lots of choices for embedding other languages in Max: LISP, Groovy, Python, and Ruby, to name some of the recent ones.
    This is such a powerful capability, but after using Ruby in Max for a while now I am frustrated. Max messages have special characters: double quotes, commas, semicolons, $, #. Unfortunately these characters are very common in other languages, so you end up with scripts like aFunction(1,2,3,4,5);anotherFunc() when you just want to type aFunction(1,2,3,4,5);anotherFunc() and be done with it.
    For bigger scripts, using an external editor is the way to go. No question. But sometimes you really just want to drop a script into a clickable message box.
    The best compromise I found so far is to use a textedit in "output as one symbol" mode (set via the inspector). But even that has a major annoyance. Try this patch:
    Enter text with some commas and newlines, something like this:
    line, one two three,3
    Save the patch, close it, reopen it. Now the text edit looks like this:
    "line, one two three,3"
    This might not seem like a big deal, but for more complicated scripts it can kill the readability. I want it to look like what I originally typed in. It's not cool that Max changes it! I believe these two textedit values are identical when the textedit is in "output as one symbol" mode. So in this situation, can the textedit automatically unescape those special characters?
    For message boxes, can anything be done to prevent Max from interpreting its special characters, or otherwise automatically escape things? I asked about this before and regexp was suggested. That doesn't work because as soon as you click on the message box and the message goes out, the damage has been done (for example a comma will split it into separate messages). I suppose we need a message box-like external that doesn't interpret any special characters.
    One of Max's greatest strengths is it's extensibility. But Max could be doing more to ease extensibility in the embedded language arena. I remember jkc saying they wanted to make it easier for people to add more languages to Max (somewhere in the js vs. lua thread). He was probably talking about low level API hooks. I humbly ask some thought be put into making it easier on the frontend side too.

    • Mar 04 2008 | 11:44 am
      > This is such a powerful capability, but after using Ruby in Max for > a while now I am frustrated. Max messages have special characters: > double quotes, commas, semicolons, $, #.
      You think *you've* got problems? In Python I have syntactic line breaks and tab indentation...!
      But yes, the problem is that the Max world is very hostile to arbitrary syntax. And the usual lexical rules don't apply, so
      "print(1, 2, 3)"
      with the quotes gets lexed as
      "print(1 2 3)"
      Not good.
      I'm now used to typing , and friends everywhere, but it would be nice to have support for truly arbitrary program text (with formatting) embedded within patchers; otherwise, scripting languages are always going to be second-class citizens.
      -- N.
      Nick Rothwell / Cassiel.com Limited www.cassiel.com www.myspace.com/cassieldotcom www.last.fm/music/cassiel www.reverbnation.com/cassiel www.linkedin.com/in/cassiel www.loadbang.net
    • Mar 04 2008 | 1:47 pm
      This is indeed really annoying. I remember horrornights(inevitably it's late, I'm tired) with conversion of long filepaths & other comma- ridden stuff from/to Max (with all the spaces and forward & backslashes that need/don't need escaping)
      Zip
      Op 4-mrt-2008, om 12:44 heeft Nick Rothwell het volgende geschreven:
      >> This is such a powerful capability, but after using Ruby in Max >> for a while now I am frustrated. Max messages have special >> characters: double quotes, commas, semicolons, $, #. > > You think *you've* got problems? In Python I have syntactic line > breaks and tab indentation...! > > But yes, the problem is that the Max world is very hostile to > arbitrary syntax. And the usual lexical rules don't apply, so > > "print(1, 2, 3)" > > with the quotes gets lexed as > > "print(1 > 2 > 3)" > > Not good. > > I'm now used to typing , and friends everywhere, but it would be > nice to have support for truly arbitrary program text (with > formatting) embedded within patchers; otherwise, scripting > languages are always going to be second-class citizens. > > -- N. > > > Nick Rothwell / Cassiel.com Limited > www.cassiel.com > www.myspace.com/cassieldotcom > www.last.fm/music/cassiel > www.reverbnation.com/cassiel > www.linkedin.com/in/cassiel > www.loadbang.net > > >
    • Mar 04 2008 | 2:38 pm
      This is one of the reasons I put 'internal' buffers in my language objects (rtcmix~, chuck~, maxlispj). They can have whatever random characters are needed, they retain formatting, and the buffers can be loaded or triggered from max/msp. It's not too hard to do (almost trivial in java), but setting them up for saving as part of the patch (binbufs) is a little tricky (but again, not too difficult).
      And I completely agree -- the tokenizing of the data stream between objects in max/msp is one of the major headaches of the environment. Oh well, such is life...
      On Mar 4, 2008, at 8:47 AM, Zip Boterbloem wrote:
      > This is indeed really annoying. I remember horrornights(inevitably > it's late, I'm tired) with conversion of long filepaths & other > comma-ridden stuff from/to Max (with all the spaces and forward & > backslashes that need/don't need escaping) > > Zip > > Op 4-mrt-2008, om 12:44 heeft Nick Rothwell het volgende geschreven: > >>> This is such a powerful capability, but after using Ruby in Max >>> for a while now I am frustrated. Max messages have special >>> characters: double quotes, commas, semicolons, $, #. >> >> You think *you've* got problems? In Python I have syntactic line >> breaks and tab indentation...! >> >> But yes, the problem is that the Max world is very hostile to >> arbitrary syntax. And the usual lexical rules don't apply, so >> >> "print(1, 2, 3)" >> >> with the quotes gets lexed as >> >> "print(1 >> 2 >> 3)" >> >> Not good. >> >> I'm now used to typing , and friends everywhere, but it would be >> nice to have support for truly arbitrary program text (with >> formatting) embedded within patchers; otherwise, scripting >> languages are always going to be second-class citizens. >> >> -- N. >> >> >> Nick Rothwell / Cassiel.com Limited >> www.cassiel.com >> www.myspace.com/cassieldotcom >> www.last.fm/music/cassiel >> www.reverbnation.com/cassiel >> www.linkedin.com/in/cassiel >> www.loadbang.net >> >> >> >
    • Mar 04 2008 | 3:53 pm
      On 4 Mar 2008, at 13:47, Zip Boterbloem wrote:
      > with conversion of long filepaths & other comma-ridden stuff from/to > Max (with all the spaces and forward & backslashes that need/don't > need escaping)
      This is part of the reason I've done all the 'place-holder' stuff in the Groovy and Python packages: keep the lexical language in the Max world as simple as possible, and do the heavy-lifting string manipulation in a real language.
      -- N.
      Nick Rothwell / Cassiel.com Limited www.cassiel.com www.myspace.com/cassieldotcom www.last.fm/music/cassiel www.reverbnation.com/cassiel www.linkedin.com/in/cassiel www.loadbang.net
    • Mar 04 2008 | 4:36 pm
      While they're at it:
      prepend 1 3. 2 message $1 $3 $2 unpack s 0. 3 sprintf %s %f %ld expr $i1 + $f1 regexp ([\w])([\w])([\d]*)
      would be easier to learn if they're more similar. Also, the message gives you functionality that is hard to duplicate using other objects (e.g. message $5 $2 $4 $3 #1) while it's a GUI object, meaning you don't really want to use it that way.
    • Mar 04 2008 | 8:03 pm
    • Mar 04 2008 | 8:09 pm
      Quote: Bradford Garton wrote on Tue, 04 March 2008 06:38 ---------------------------------------------------- > This is one of the reasons I put 'internal' buffers in my language > objects (rtcmix~, chuck~, maxlispj). They can have whatever random > characters are needed, they retain formatting, and the buffers can be > loaded or triggered from max/msp. It's not too hard to do (almost > trivial in java), but setting them up for saving as part of the patch > (binbufs) is a little tricky (but again, not too difficult).
      Yeah, I'm realizing this is probably the best solution right now. I need to add something like this to my ruby object.
    • Apr 10 2008 | 10:13 pm
      Hey Guys,
      Can anyone tell me how to concatenate a new line escape sequence (n) to the end of a symbol? Not hard to do with pack, but I don't want the space between elements - can't seem to get it done with sprintf. I just need to format a text file on the fly, to be used later in another environment - seems so simple! Anyways, I may be overlooking something very basic...
      Thanks.
      Zachary
    • Apr 11 2008 | 3:17 am
      On Apr 10, 2008, at 3:13 PM, Zachary Seldess wrote: > Can anyone tell me how to concatenate a new line escape sequence ( > ) to the end of a symbol? Not hard to do with pack, but I don't want > the space between elements - can't seem to get it done with sprintf. > I just need to format a text file on the fly, to be used later in > another environment - seems so simple! Anyways, I may be overlooking > something very basic...
      I'm a little surprised sprintf can't do this. I would of thought a format string of %sn would have worked.
      At any rate, the text object will let you do this:
      Chris Muir cbm@well.com http://www.xfade.com
    • Apr 11 2008 | 3:50 am
      Thanks Chris, unfortunately that's not quite what I'm after.
      I actually want the new line escape sequence concatenated to the end of a line of script. So, the line of text in the text object, for example, should look like this - with the n actually included - and WITHOUT a space after the last symbol (hence my unsuccesful attempt to use sprintf):
      blahdy blah blahn
      What a pain that something so simple is so difficult in Max.
      > I'm a little surprised sprintf can't do this. I would of thought > a format string of %sn would have worked.
      Me too!
      Zachary
    • Apr 11 2008 | 4:24 am
      Quote: Zachary Seldess wrote on Thu, 10 April 2008 20:50 ---------------------------------------------------- > What a pain that something so simple is so difficult in Max. >
      Yup. Hence my original post.
      I keep thinking all these issues would vanish if there were *plaintext* versions of message box, textedit, etc. No special characters, in other words WYSIWYG. But maybe the special max message format is ingrained in the actual message passing between objects so it's currently not possible? If not, and we are patient, perhaps Cycling '74 will humor us one day...
      Currently, the best bet when you run into these sorts of problems is to either form your strings in javascript or an external, and/or use js/externals to read the text in from a file.
    • Apr 11 2008 | 5:14 am
      Yes, you're right. It's quite easy in js.
    • Apr 11 2008 | 5:56 am
      Hi Zachary,
      Is this what you are looking for?
      all the best, -Ben
    • Apr 11 2008 | 6:06 am
      sprintf super escape mode:
      -b
    • Apr 11 2008 | 6:57 am
      Should this solution work in Max 5?
      What is the function of the "pack s" here?
      -C
      On Apr 10, 2008, at 10:56 PM, Ben Bracken wrote: > > Hi Zachary, > > Is this what you are looking for? > > #P window setfont "Sans Serif" 9.; > #P window linecount 1; > #P newex 177 203 40 196617 text; > #P newex 256 203 32 196617 print; > #P newex 177 140 58 196617 pack s \ > ; > #P newex 177 164 84 196617 sprintf %s\\%s; > #P message 177 115 139 196617 "this is a sweet line of text"; > #P connect 1 0 4 0; > #P connect 1 0 3 0; > #P connect 2 0 1 0; > #P connect 0 0 2 0; > #P window clipboard copycount 5; > > all the best, > -Ben >
      Chris Muir cbm@well.com http://www.xfade.com
    • Apr 11 2008 | 9:42 am
      Hi Chris, if you have a look at forum posts, the "backslash n" isn't interpreted as line escape while it does via the mailing list. It took me a while to realize that.
      Ciao
    • Apr 11 2008 | 1:04 pm
      Yes! Damn, I can't believe I didn't come across both of those methods.
      So in the first patch, I get the pack, but why are the DOUBLE backslashes needed, rather than the typical single backslash in the sprintf? Is this some "C" convention, in this case?
      And the same goes for the 4 backslashes in your second patch - can you explain the logic for me?
      Let's say I didn't want to concatenate "n" to the end of a line, but "," or ";" instead. Now these two solutions don't work anymore. Any quick Max methods like the above for these? (Again, I'm sure I'm missing something simple).
      Thanks for the help, as usual!
      Zachary
    • Apr 11 2008 | 2:07 pm
      Backslash is used to tell to Max to treat special characters as normal ones but backslash is also a special character ;) Have a look at the following example. Here you have 3 backslashes. 1st "" tells Max to treat the 2nd "" as a normal char., 3rd "" tells Max to write "," or ";" as a normal char.
      Ciao
    • Apr 11 2008 | 2:37 pm
      Thanks for explanation - yes I was missing something simple. I know the special status of "" in Max, of course. Here's a patch that I hope will pose the unanswered question more clearly:
    • Apr 11 2008 | 3:02 pm
      ok, now I also want to understand !
    • Apr 13 2008 | 12:28 am
      Quote: Zachary Seldess wrote on Fri, 11 April 2008 07:37 ---------------------------------------------------- > Here's a patch that I hope will pose the unanswered question more clearly >
      Nice example. It doesn't make sense...
      Semi-related: I often run into problems with quoted messages because they behave differently depending on whether there is a space or not. All these counterintuitive behaviors make it very difficult to work with text inside of Max.
    • Apr 13 2008 | 5:32 am
      havn't really followed this thread, but the last patch can be fixed by adding the symout argument to the sprintf by "Huh?"
    • Apr 13 2008 | 5:40 am
      Quote: robtherich wrote on Sun, 13 April 2008 01:32 ---------------------------------------------------- > havn't really followed this thread, but the last patch can be fixed by adding the symout argument to the sprintf by "Huh?" ----------------------------------------------------
      You're right. I forgot about the symout argument (in the docs).
      Any ideas on the patch in my last post?
      Zachary