bpatchers with js files inside an amxd?
Aug 06 2014 | 2:06 am
Has anyone had any luck with this?
I'm working on a project which contains 24 identical bpatchers inside a Max MIDI Device. Each of these bpatchers contains a js file which changes the appearance of the UI elements within it. As I'm building my 6x4 matrix of them, each one will individually compile and change their appearance independently of each other. But, when I close my Live Session and re-open it and re-edit the amxd, only the first bpatcher instance is able to successfully compile and respond. Everything else returns null references to the varnames because it can't compile.
I thought maybe I could freeze the js into the bpatcher, but you can't embed amxd files into bpatchers! For kinda logical reasons, I guess.
Anyone have a similar experience?
- Aug 06 2014 | 9:03 amHi, I use bpatchers that use js files in M4L all the time and haven't seen this issue - maybe you could post example?
- Aug 11 2014 | 6:27 pmIt's kind of a difficult example to encapsulate inside of an example. There's something about the way I have structured my JS code that's closing off new unique references from being identified beyond the first bpatcher.Each bpatcher with the identical .maxpat has two inlets, one banging a "compile" message to my js on live.thisdevice loadbang and another taking in an int which scrolls through a umenu that passes it through a function call reading "selection(v);" where v is that int.The bpatcher identifies itself as "p" which is declared at this.patcher, and then there's an object literal based off of each of the UI elements in p. There's a panel for the title, a panel for the module body, eight live.dials, eight comments above the dials for their changeable labels, and eight comments below for their values. These are each added as a member of the object literal by saying for example "titleLabel: p.getnamed("titleLabel")" which is referring to a panel with varname titleLabel.I figure these names are safe from each other since each bpatcher only refers to its own contents and each js file lives within this bpatcher, but any time I try to change anything outside of the first bpatcher, they return null references.
- Aug 11 2014 | 7:24 pmNever mind, I figured it out. I can't prototype my module in this sense; I'm getting overlapping varnames. Well, this makes everything a whole lot messier...
- Aug 12 2014 | 8:20 amyou shouldn't need to send a compile message to the js unless you've changed the code and don't have autowatch set to 1 - otherwise it's compiled automatically at loads time.don't see anything wrong with what you've described and not quite sure what you mean by overlapping varnames...
