This seems like it'd be a semi-obvious feature, but I don't know whether
the logic board is setup for it. Have seen any commentary about this so
far in my looking, but please point me to it if I've overlooked it. Will
it be possible to run one or more 64/40h applications on the 256 at
once? Or perhaps a 128 and 2x 64 apps? It seems possible in theory, and
would seem immensely useful to myself, but what's the official word on
software for the 256? Is it basically just capable of running one big
64/40h patch or can it do more? On a related note, will current 40h apps
be easily scalable up for the 256 if you want to do so (again assuming
that's even possible)? Thanks!

monome serial will support all the upcoming monome devices along with 
the 40h and kit 40hs.  actually, it will run multiple units just fine, 
too.  each device can have it's own OSC prefix, so it is possible to 
have multiple patches open, and have each device send to a differant 
patch.  i dont think you can open multiple instances of Max/MSP runtime, 
though, since they wonmt share the soundcard drivers afaik, but you CAN 
open and somehow mix multiple Patchers of mlr, for instance, in the same 
instance of max/msp.  so, you can mod mlr, make differant patchers run 
on OSC prefixes /mlr1, /mlr2, etc, and assign those prefixes to 
differant monome devices.  the only thing im not sure about it if 
buffer~ objects will confict if they have the same names, in differant 
parent patchers, but in the same instance of max/msp.  if that is the 
case, then youd have to find and rename the buffer~ objects.

what you CANT do, is have multiple prefixes assigned to the same 
256,unless there is some sort of change in monome serial design, i doubt 
it though as it would be pretty confusing having 2+ prefixes per device 
imo.  actually, this could be cool, basically assigning prefixes based 
on the 'virtual gridspace', and the prefix of the device is then based 
on where it is in the gridspace, via the device size and offsets.  i 
personally dont like this idea, its just adding more complexity to both 
the monome serial code and the end-user max/chuch/reaktor/etc 
programmer.

what you CAN do, though, if you have max/msp, is take the data from 
monome serial and the 256, and somehow seperate it depending on row/col, 
and send that to differant mlr (or other patcher/app) instances.  to do 
this correct, you have to remove the udpreceives in the patchers, and 
use normal send/receives like older mlr does, and have the udp 
send/receives in a seperate patcher that is responsible for routing the 
data to the appropriate app patchers, via send/receive objects.

does this help?  i may have not understood the question, and wasted 
everyone's time.

thanks for dropping that science, it helped me understand the underlying 
software development which I haven't delved into yet, it's been two 
weeks since I built my kit, I'm still figuring out the basics and 
enjoying playing with my 40h (gotta keep the balance between tech and 
music.)  THANK YOU ALL for the apps so far, so much fun, so much playing 
outside the box.

looking forward, settling on a naming convention to let people describe 
their own tweak of an app (or multiple apps at once) would leave the 
door open for that kind of experimentation and development.  something 
like
_devicename_appname_revnumber

these monome devices are such great blank slates, names and file 
organization can be sorted out and not be in the way of insane 
inventions and sane download sites.

I very much look forward to seeing how this community develops.

writing a 256 router that converts the OSC signal to 4 40h's would be 
really really easy. like, really easy. you just use the modulus 
operator.

also, dont forget an integer divide, to find what part you are in.

it's fair to say that anything is possible, since we designed 
monomeserial to treat the hardware as an abstract "window" into one of 
many layers of data.

like what was said before, i'm sure small routers will emerge to handle 
elaborate schemes (multi-patches per unit), though i've also been 
designing more dynamic patches which can use variable window sizes 
(8x8,8x16,16x16) along with dynamic context switching inside-app (like a 
key will flip to a bank of sliders, then back to the main context, etc).

nice writeup by the way, daniel. i need to publish something like that 
on the main site. (i'm in the midst of a massive (taxing) redesign...)

Awesome. I dig that. Good to know it can handle having the grid running
different patches simultaneous and changing on the fly. That's downright
exciting.

yes, monome serial has alot of cool features that i think are just now 
starting to get into.  i have to give both Brian and Joe Lake (who coded 
the original Monome Serial for OSX, my XP version is just a copy) 
massive credit, the concept is amazing.  the great thing about Monome 
Serial, is that literally ALL of the functionality is not just handled 
by the apps controls/GUI, but also mirrored via OSC functions.  these 
functions are located in the /sys prefix.  so, instead of clicking or 
typing in prefix, offset and cable direction/orientation changes in 
MonomeSerial, you can also change them via OSC commands.  the 
implications of this are huge, imo, since you can handle it 
programmatically in the app that the monome device is controlling (like 
a max/msp patcher).

another cool thing, is that you can request /sys command reports, by 
sending a /sys/report OSC command.  it returns something like this (this 
example assumes 2 40hs, just for giggles):

/sys/prefix 0 40h
/sys/prefix 1 40h
/sys/cable 0 left
/sys/cable 1 up
/sys/offset 0 0 0
/sys/offset 1 8 0
/sys/adc_offset 0 0
/sys/adc_offset 1 4
/sys/enc_offset 0 0
/sys/enc_offset 1 2

this example uses the same prefix for both 40h's, but you can just as 
easily use 2.  using one is good for making an 8x16 grid, while 2 
prefixes is good for controlling 2 differant patchers or apps.

the /sys commands can send to all devices, or if you put a number after 
the command name, you can send it to just one device (so, "/sys/prefix 0 
foobar" will change the prefix of just the first device to /foobar, 
while "/sys/prefix foobar" will change ALL active device's prefix to 
/foobar).

also, when you update the prefix via a /sys/prefix command, or even via 
the MonomeSerial GUI, a small prefix-only report is sent, so if you 
change the first device's prefix to "/ramble", MonomeSerial will send 
out "/sys/prefix 0 ramble".  pretty damn spiffy!  unfortunately, i 
mainly use Reaktor and it cant send strings over OSC (or, strings 
anywhere for that matter).  but, apps like Max/MSP, pd, chuck and plenty 
of others do allow this.

sorry if everyone reading this already knew this stuff, but i think alot 
of people might not even realize that some of these features exist!

I assumed/wished that there was a way to adjust settings separately by 
device via OSC, but hadn't gotten around to looking/asking about it. 
Thanks for the info.

One thing that I'm still curious about, is there a way to find out the 
serial numbers IDs of the devices in the stack?

do you mean via OSC? not at the moment, though it may be useful-- in 
addition to model ID (256 vs 128 vs 64 vs 40h)

if you mean just to know, yes, it shows up in monomeserial.

or if you're on os x or linux:

ls -lrt /dev | grep m40h

Yes, I meant via OSC. If you were using Max to quickly switch 
prefixes/offsets in a performance setting, for example, it would be more 
straightforward to do it per ID than per stack order. Of course one 
could always simply make it a point to have a plug-in order for devices, 
so that they always ended up in the same place in the stack.

this applies to MonomeSerialXP only, i dont know on the original OSX 
version:

the device order has nothing to do with the order they are plugged in or 
anything, its based on the ordering of the associated registry keys.  i 
apologize in advance for the C++/C# techspeak coming up, but im thinkng 
you (revbean) know some programming.  so, devices that are installed but 
not plugged in still get a spot in the array of MonomeSerialDevices, but 
their constructor is never run, and they basically point to null 
(similar to a NULL or (void)* pointer if C++, except null is a keyword 
in C#, and i believe null_ptr will be a C++ keyword in C++0x, also it is 
a valid keyword in C++/CLI already).  my point is just to point out 
that, in XP, the ordering is not a random runtime generated value, but 
system-based, i think also based on the order the devices were installed 
on the machine.  im assuming that Joe did something similar in OSX, but 
im really not sure as i didnt heavily read up on any of the 
OSX/UNIX-specific code bits in MonomeSerial yet.

anyways, i think that it would be a really great idea, perhaps part of 
the current /sys/report message, or a new /report message (i think it 
will be safe to add this to the current report, i doubt many if any at 
all people have used /report in their patchers yet, although if they did 
this will probably break their code!).  it would not really be hard to 
do either.

brian, you said maybe it should tell the serialnumber and device type? 
wouldnt the serialnumber itself technically tell the device type?  i 
guess it would be easier to parse in a seperate entry.  regardless, what 
i think would be better would be a /report string addition that instead 
gives the device's dimensions, which i think would be the most useful 
reason to know the device type (although MonomeSerial goes to great 
lengths to create a layer ofabstraction between actual device 
coordinates and the virtual grid that the devices reside in that the 
OSC/MonomeDevice programmer against, some uses still lend themselves 
towards per-device programming with differant prefixes per device).

sys/report

=

/sys/serial 0 m40h0002
/sys/serial 1 m40h0030

etc?

i could see how that'd be useful.

i was also thinking (this applies to os x for replugging) that /report 
should be triggered upon inserting a new device. the way i've been 
thinking about designing patches is to be able to "redraw" at any time, 
so by linking a "redraw" to receiving a matches /prefix (focus on the 
app) then context switching should work well.

On OS X it's definitely all about plugin order. I haven't gone looking 
through the MonomeSerial source, but from what I can deduce from use, 
the ftdi driver creates the /dev/cu.* and /dev/tty.* devices on plugin 
and removes them on unplug, so that there's no system record of a 
perviously used but unplugged device. MonomeSerial is either regularly 
polling /dev or has somehow registered with the ftdi driver as an 
"interested party" to be let known when new serial devices are available 
and adds them to the top of a stack.

In either case, additional information in the /sys/report seems like a 
good thing to me. My first thought was to adjust the line

/sys/devices 2

which simply reports the number of devices to something like

/sys/devices m40h0221 m40h0402

with a list that could be read into an array that the internal IDs could 
be mapped against. But actually Brian's suggestion above, of a 
/sys/serial line per device makes a lot more sense.

Adding info to /sys/report would almost certainly not break anyone's 
code, assuming that anyone has even written code to take advantage of 
it.

i agree. and no, it probably won't break anybody's code... i think 
everything is too new, so we haven't seen any patches that really take 
advantage of the new features.

yes, thats what i thought, that nobody has used it really.  but, i can 
see if they did there might be problems depending on how the report info 
is read.  honestly, it would probably be sloppy code anyways if adding 
new report data breaks anything, but it is possible.

brian, i like your first method, of:
/sys/serial 0 m40hxxxx
/sys/serial 1 m40hxxxx

since this is already the syntax used.

also, the unplugging/replugging thing sending a report is a great idea. 
or else, a /sys/deviceschanged osc out message, which the user could 
then lo for and ask for a report, but i think just sending the report is 
more to the point.  either way, though, this would let the user's app 
code handle device changes (plug-in/unplug) programmatically.  the only 
thing wrong with just sending a report is that its harder to tell the 
differance between a device change and a simple call to /sys/report, but 
of course not impossible either.

hotswapping on monomeserialXP is coming along!  unfortunately i dont 
have enough time to spend on it as id like, as im studying stuff for 
upcoming job interviews (brushing up on ASP.net and SQL), but it should 
still be done soon and hopefully i can release it as an update within 
the next 2 or 3 weeks.