yeah, this was a design choice – basically, I was trying to consider what would be easiest to recall upon load.
right now, a saved Live set with a bunch of crow devices just needs you to select the hardware crow to send messages to. previously, I outfitted each device with its own dropdown, but that led to a few problems:
- if you instantiate two [crow] objects and have them both transmit to the same crow hardware, you get dropped messages + general lag
- even if we could address that, this approach meant identifying your crow up to like, 9 times every time you opened a saved Live set.
the ^^command_center approach seemed like the best way to handle the launch, where most folks would be using only one hardware crow but a lot of m4l devices. I originally wanted to use --- prefixes to help route traffic to multiple ^^command_centers (and multiple crow hardware), but these are the challenges I ran into:
- --- prefixes increment as long as Live is open, not with each new set load, which means the counter resets back to 001 only when the program closes. so, let’s say you open a Live set with two sets of ---^^command_center: if this is the first thing you do in Live then you’ll have 001^^command_center and 002^^command_center. dope! but…
- to avoid you having to choose which one every time you load a set, I’d like you to be able to save this identifier. let’s say you save a Live set specifying that each of your m4l devices talks to 001^^command_center and 002^^command_center. but if you have already opened a Live set that uses --- prefixes, then Live will auto assign 003 and 004 to these devices, since it increments agnostic of your intent. this means your loaded set will be sending messages to ^^command_centers that don’t exist. so you’d have to close Live each time you wanted to switch sets 
that said, here’s where I think I’ll go:
- decide on an arbitrary cap of 3 crow hardware maximum
- hard-code unique identifiers and bundle 3 different ID’d versions of the m4l suite, let’s say 1[name of device]
- allow a multi-hardware user to instantiate 1^^outs, 2^^outs, 3^^outs to talk to 1^^command_center, 2^^command_center, 3^^command_center (for example)
- single-hardware users will just instantiate as normal
I hope this makes sense? plz send objectivity!
sam solved it below! I’ll get this folded in tonight
