Sending a message to a bpatcher from within JS..

    Dec 31 2017 | 12:11 am
    I have no trouble finding boxes from inside my JS patch, or sending messages to those boxes - unless the box is a bpatcher.
    If it's a bpatcher, if I try to e.g. send the message goodbye, I always get an error "patcher: doesn't understand the message goodbye". I attach sample code (unfortunately, I don't see how to save the JS with it, but I have the JS in a comment in the code). You can see that the JS code does locate both the message box and the bpatcher, and successfully sends hello to the message box, but gets an error trying to send goodbye to the bpatcher.
    I feel I have solved this before in the past but I cannot remember how. Suggestions most welcome!

    • Dec 31 2017 | 2:17 pm
      I'm going to work around it for the moment, but while I am here, let me ask the other question that's been on my mind - from Javascript, how do I send a message to an inlet of a box that is not the leftmost one? To summarize - in Javascript, right now I know how to send messages directly (without a patch cord) to the leftmost inlet only of any box which isn't a bpatcher or patcher, by using the message() method. I cannot send to any inlet other than the leftmost one, and I cannot send to batchers or patchers at all.
    • Dec 31 2017 | 3:44 pm
      For the second issue - i'm pretty sure there is no way to send to any inlet other the first. In this case i put a receive object before the object in question and use route or unpack to route to the correct inlet.
    • Dec 31 2017 | 3:55 pm
      Yeah, that's what I'm doing, but the point of the exercise was to avoid having all those patch cords everywhere. It's a shame that I have the very message I want to send and the very object I want to send it to, but there's no way to actually send it without creating a bunch of wires for this single purpose...
      I'm still hopeful I can directly send to bpatchers from my .js script. I can't be the only person who wanted to do that...
    • Dec 31 2017 | 3:57 pm
      For the first - not sure how to send to the inlet itself, but you could send to an object inside?
    • Dec 31 2017 | 4:36 pm
      Only if that object has a uniquely named receive somewhere in it. I could do it with the usual receive #1-foo trick but such solutions are fragile. More, it means I have to rewrite these boxes that I'm already using elsewhere.
      This issue comes up for me all the time - I have a large number of otherwise identical boxes that I am controlling from a Javascript script that has all my actual logic in it.
      All I want to do is to send it a message in its inlet - just like I could to any other Max object. Why is bpatcher different?
    • Dec 31 2017 | 4:40 pm
      I agree - its a pita for me too.
    • Jan 02 2018 | 1:03 pm
      So I'm believing that I'm not going to get any more answers here, and that my results are unfortunately correct. To summarize - it seems as if the JS message method only allows you to send to the left-most inlet, and only to boxes that aren't bpatchers or patchers. It's unfortunate - without these critical limitations, particularly the second one!, message would be an amazing general-purpose tool for building Max patches almost entirely in JS, instead of just a curiosity.
    • Jan 03 2018 | 12:01 pm
      same problem found with bpatchers. I'm using a named 'trigger l" connected just after the inlet inside the bpatcher. my outer JS can send to this bpatcher/trigger. With a named trigger object, no needs to acces the global send/receive in JS, and to give a unique name to the receive. the uniqueness is given by the bpatcher script name.
    • Jan 03 2018 | 12:08 pm
      The code to get the named trig inside the bpatcher:
      i'm using an array of bpatcher, with a trig inside each one named "trig"
      objs_array[i].replace(obj_maxpat); // load the bpatcher maxpat
      trigs_array[i] = objs_array[i].subpatcher().getnamed("trig"); // get the trig inside it that is just after the inlet
      trigs_array[i].message("blablabla"); // send a message outputed by the trigger
    • Jan 03 2018 | 12:12 pm
      This is a neat idea, but it doesn't really hit the spot. The trouble with it is that you have to rewrite each box you use this way to have the named trigger in it. If I were going to do that, I could just add a named receive in each box, and use #1 to make sure it's a unique name.
      What I want to do is simply talk to any box in my patch without having to rewrite that box specifically for that purpose.
    • Jan 03 2018 | 12:27 pm
      yes, i know. but thats the only workaround i found. I just put a "trigger l" after my inlet in all my bpatcher so i can access them through javascript. I don't know if someone is 'still' in charge of JS for maxpat in cycling cos all those questions about criptic messages to Bpatcher has been asked many times and no official answers.
    • Jan 03 2018 | 12:42 pm
      Oh, not at all carping about your solution, which is I think as good as it's going to get.
      I still have resentments from spending a year on a JS project that I could never get to stop crashing in Max 6, and then later discovering that JS in Max 6 was not thread-safe so you couldn't reliably use it for more than one input, so it makes me grumpy when I have to spend a few hours more of my life working around long-term issues that are well-known, and I'm therefore sorry if I come off as a grouch!
      Considering that Cycling 74 has been taken over by Ableton, a company with an extremely poor history in fixing bugs (there are numerous serious bugs in Live reported by me and others that are over five years old and have never been addressed), my theory is that this will never get fixed.
    • Jan 03 2018 | 11:41 pm
      By the way, did you get any answer from cycling, respect to the relative path for require being not compliant with commonJS? As I stated in others posts, i think cycling should set up a wiki dedicated to all those issue and cryptic messages in JS with max. Happily, rob is answering regularly for the jitter/GL part of JS...
    • Jan 04 2018 | 10:23 am
      Ah, interesting question! I'm flattered to be recognized.
      But no. To be honest, I'm pretty sure that I convinced them that I was some eccentric, because the response was basically, "Why would you want that?"
      The idea that you might want to use some of seemingly-infinitely many node.js packages was perhaps a little science-fictional at the time, but these days it seems much more desirable. <rant>
      To be frank, the level of support for music and audio programs in general in the industry is just terrible. Pretty well every program I use, there are critical bugs that have first been reported many years and then re-reported by numerous people, without ever being followed up on. I've whined ;-) on this forum about Ableton quite a bit - how M4L only allows you one MIDI input and output so at a certain point everyone ends up using an unsupported, orphaned freeware box that lets you speak directly to MIDI devices, how it won't let you use System Exclusives or Program Changes. (And that's only one of dozens of serious issues I have documented with Ableton.)
      But Native Instruments, for example, is even worse. Almost none of their packages have even one level of undo. Worse, their interfaces are tiny, unresizeable windows, and typically there is a "mutate" button that changes all your parameters squashed right up against a button you use frequently, so it's very hard not to occasionally click it - and unrecoverably destroy all your work in that session. (I get into the habit of obsessively using Save-As with index numbers to partly mitigate this issue, but that has its own drawbacks.)
      I moved recently to Reaper and it seems to be much better that way, but we'll see how it goes in the future. </rant>
    • Jan 04 2018 | 5:43 pm
      You do know none of those things mentioned in your above post are bugs right? And the seriousness of those issues is totally dependent on what you are doing and your particular workflow?
      I don't mean to invalidate those requests about how Live handles MIDI, because I agree, but to call them critical bugs is a bit extreme.
    • Jan 04 2018 | 6:33 pm
      A MIDI programming tool that only works on channel 1 for input and output and throws away a majority of the MIDI message types - including program changes! - is broken. The MIDI standard has been around since 1983 - it's tiny, a few pages. If you can't support that standard, at least as far as not throwing information away, you have no business calling yourself a MIDI programming system.
      From my notes, here's a list of the MIDI messages that M4L silently discards: * program change * system exclusive * MIDI time code * song position pointer * song select * tune request * end of exclusive * timing clock * start * stop * active sensing * reset
      This is a majority of the MIDI message types. And I'm not asking for the program to do anything fancy with them, other than not throwing them away.
      Some of these are obscure, but some of these are extremely important, like program changes and system exclusives. Indeed, I have a dozen or so hardware synths in this room with me and all of them use both program changes and system exclusives. You could argue that this isn't a bug - it's simply surprising and undesirable behavior that isn't documented and doesn't match the MIDI standard. I'd certainly accept "Shoddy work and no pride in their own craft" as another description of this. Don't get me wrong - it's not Max's fault.
      Max handles all MIDI messages perfectly well, handles all MIDI channels fine, handles multiple interfaces if you have them. But Max For Live simply drops a bunch of messages on the floor, throws all data onto channel 1, and then gives Max the pathetic remains.
      I paid good money for M4L when it came out, even though I already owned Live and Max, and it was basically useless for my needs because of this. At the time, we were told that SysEx was coming soon, but it's been nine years and I no longer believe this.
      There are numerous outright bugs with Ableton that they are never going to address, but aren't related to Max so I didn't mention them. For example, if you stretch time on a MIDI track, it stretches only note-on and offs - it leaves all the pitch bend and continuous controller information right where it was. Ableton's response on this that that was exactly how it was supposed to work - but this means that if you play a MIDI performance which uses pitch bend, modulation wheel or aftertouch, and wish to stretch or edit it in such a way as your notes and your controllers stay together - well, there's just no way to do this. I reported that almost a decade ago and I periodically see other people finding this out online - usually after they trashed some performance they recorded on MIDI. Ableton will never fix that. I personally have a commercial digital audio application I wrote entirely myself, and I've been writing computer music programs since the late 70s, so it's not like I'm speaking out of ignorance.
    • Jan 04 2018 | 6:40 pm
      You could argue that this isn't a bug - it's simply surprising and undesirable behavior that isn't documented and doesn't match the MIDI standard.
      That's all I'm doing. File all this stuff under feature requests, not critical bugs.
    • Jan 04 2018 | 6:51 pm
      Saying, "Sorry, we only support one MIDI channel, something we don't mention anywhere in the heavy PR campaign, and we're never going to change this" - that is a critical bug in a MIDI programming system.
      I, personally, would be ashamed to do such shoddy work.
      I'm curious - can you point to other MIDI programming system that only supports a single MIDI channel? For that matter, can you point to another DAW where stretching a MIDI track puts the controller information out of sync with the notes?
    • Jan 04 2018 | 7:29 pm
      I use multiple MIDI channels all the time in Live. I don't think Live has ever branded itself as a MIDI programming system, although it does support (in a somewhat limited fashion apparently) MIDI. I suppose its good you don't work at Ableton, then. I don't use any other DAW for MIDI work, so no I can't.
      My point is - I don't see the point in making such a huge stink about these 'critical bugs'. File them as feature requests, and move on creating things.
    • Jan 05 2018 | 11:39 am
      No, in that one feature I'm talking about Max For Live, as I was very clear - I mention M4L four times.
      Max For Live does bill itself as a music programming system. It only works on one channel in, and one channel out. Go ahead, try it yourself now. I bought Max For Live for a specific project where I needed to use multiple MIDI channels. It was useless for that but of course, try to get your money back, and they won't do it. I was unable to "move on creating things" as there was no way to accomplish what I needed with just one MIDI channel. I eventually came up with a complex workaround, after wasting a few days of my life.
      Ableton has no place to file feature requests. For a short while, a third party ran a website where you could file bugs against Live, but then Ableton's lawyers got it taken down. You can contact tech support, but there's no way to track your requests, and so far not one issue I've raised has been dealt with - years later.
      I have of course contacted them about these issues. I am generally very polite in these matters, though you have probably detected my patience is pretty well shot after a decade. Their response has almost always been to claim that this is how it's supposed to work - yes, even the matter of "any edit to a MIDI track with both notes and controllers breaks the track". Often they ask, "Why would you want to do that?" - even about things like wanting to record a MIDI track without playing to a metronome (part of my discussion about "editing MIDI tracks")
      I should not have to explain to a music company why I don't always want to play to a metronome!
      This idea, that I should just accept software that I have paid for that does not actually do what it claims - because I'm sorry, but a MIDI programming tool that doesn't actually support more than one channel and throws away a majority of the MIDI message types is broken - is a poor one. Other companies do far better than that. Reaper costs a fraction of what Ableton Live does and they're incredibly responsive and polite.
    • Jan 18 2018 | 2:56 am
      Regarding access to box inlets: this is a huge gripe of mine. My experiences are the same as those already cited, and I really wish there weren't the need for workarounds (I code extensively in JS within Max, and most of my connections are scripted using obj.message() methods). As far as sysex goes: it's part of the upcoming Live 10 release. Better late than never ;)
      Multichannel MIDI: complete agreement with Tom on this, but I don't see it as a bug, instead I think it's just a low-level design flaw. I'm sure if it was easy to fix, Abes would have done it by now. I hope to see a future solution that parallels what they have done with multichannel audio for m4l in Live10, but I'm not holding my breath. In the meantime, there ARE solutions for using multichannel MIDI via various third party externals. I quietly published one in my own m4m7 repository for OS X, or you could use either of these:
      One thing to note, though, is that Windows's handling of MIDI ports is horrid, and that greatly limits what can be done using these solutions on that platform. I suspect that may even have some bearing on the reasoning behind why we haven't seen an official solution for this problem yet. @Tom: maybe join the Live 10 public beta? I believe they DO want to hear what their users have to say, and that provides a forum to make suggestions. Being in the minority when it comes to use-case scenarios isn't pleasant (believe me, I understand), but the more voices heard, the better. On the other hand, if it hasn't happened because of some technical limitation buried in decades old base code, I guess we're beating a dead horse ;)
    • Jan 18 2018 | 11:05 am
      Ah, no, I've left Ableton forever, and joined the ranks of the Reaper people. Reaper is absolutely everything I ever wanted in a sequencer or a DAW!
      I had a chance a few years ago to chat to an engineer who had seen the Live codebase, and most of these problems are probably unfixable - for example you'll never be able to open two Live projects at the same time as "the current sequence" is a singleton; you can't stretch both MIDI notes and CCs or pitch bends at the same time because the notes are stored as part of the clip whereas CCs and pitch bends are attached to the track; and you can't really do anything clever with program changes because they're a completely special case, also attached to the track.
      In particular, the one thing that I want - to simply be able to play my MIDI instrument into a track without a metronome and then stretch it so it fits into an even number of bars - will always be impossible. I did this with Performer (before it was Digital Performer), I can do it with Reaper and any other sequencer I used, but the underlying data structures in Live make this essentially impossible. Indeed, a lot of the source of my frustration is that Live support actually accused me of being "difficult" for not wanting to play to a metronome. :-(
      This question was regarding a little hobby project of mine, to control a bunch of DMX lasers I have lying around, so it's a pure Max problem when it comes down to it. The rest was wrangling with a random . :-)
      Thanks for your civilized and very enlightening comment.