http://wiki.monome.org/view/MonomeSerial

major improvements over serialio:

* assignable prefix (not just /box)
* dynamic cable position assignment
* x/y offsetting for multiple units
* native MIDI, virtual ports created
* /clear
* /frame

bug reports please!


NOTE! the default prefix is /40h

to use this with our "old" patches (they'll be revised soon) you *must*
change the prefix to /box

ahh, finally its out!

sounds great!

quick question: is it universal binary?

jmelnyk wrote:
> sounds great!
> 
> quick question: is it universal binary?

yes.

Cable orientation = awesome.  Fantastic!!

thanks, this is great!

cable orientation & assignable prefixes=crucial for multi-units.

running two 40hs at once, i was able to run two instances of the 
monoGrid app for live, each with their own prefix (just replaced /box 
with /box2 throughout the code).  with each 40h set to its own channel, 
using the follow actions in Live, full 8x16 sequencing!  then change the 
grids for another page of 8x16 sequencing! (MonoGrid by ahlstrominfo, 
and assignable prefixes, rock).

one thing, not a bug, just a detail.

In MIDI mode, MonomeSerial reacts to Velocity=0 as a led-off message. 
Ableton Live sends Note OFF rather than velocity=0.  So in MIDI mode, 
Monomeserial doesn't react to the MIDI info sent back by Live.  LEDs 
light but don't turn off.

i prefer the pages in the monoGrid app (and it makes me feel smart to 
have code on my screen, ha:)

dp

d-p wrote:

> In MIDI mode, MonomeSerial reacts to Velocity=0 as a led-off message. 
> Ableton Live sends Note OFF rather than velocity=0.  So in MIDI mode, 
> Monomeserial doesn't react to the MIDI info sent back by Live.  LEDs 
> light but don't turn off.

this is on the bug list. the motherboard in joe's macbook died while 
listening to r kelly, and it's getting repaired by apple. should be 
fixed within a week.

ha///

> In MIDI mode, MonomeSerial reacts to Velocity=0 as a led-off message. 
> Ableton Live sends Note OFF rather than velocity=0.  So in MIDI mode, 
> Monomeserial doesn't react to the MIDI info sent back by Live.  LEDs 
> light but don't turn off.

not really related to monomeserial, but what's the difference between 
velocity=0 and note off? i thought they were the same?

forgive me if this rather obvious but how does momomeserial work? i 
downloaded and fired it up and become excited at the list of options but 
can't get MS to talk to anything...midi/osc.

for example i opened up MS and set it for OSC, then /box, opened up MLR 
and nothing.

i mean maybe there's more steps involved or i'm just way out to lunch 
here, but i need some help from you all. maybe some examples or a help 
file?

thx in advance
a

It seems that leds don't work with Reaktor using OSC protocol.

stephen wrote:
>> In MIDI mode, MonomeSerial reacts to Velocity=0 as a led-off message. 
>> Ableton Live sends Note OFF rather than velocity=0.  So in MIDI mode, 
>> Monomeserial doesn't react to the MIDI info sent back by Live.  LEDs 
>> light but don't turn off.
> 
> not really related to monomeserial, but what's the difference between 
> velocity=0 and note off? i thought they were the same?

no, note off is actually differant, most midi devices send note on with 
a velocity of 0, but some send note-offs.

actuel wrote:
> forgive me if this rather obvious but how does momomeserial work? i 
> downloaded and fired it up and become excited at the list of options but 
> can't get MS to talk to anything...midi/osc.
> 
> for example i opened up MS and set it for OSC, then /box, opened up MLR 
> and nothing.
> 
> i mean maybe there's more steps involved or i'm just way out to lunch 
> here, but i need some help from you all. maybe some examples or a help 
> file?
> 
> thx in advance
> a

can someone assist? SerialIO & _40h_Serial.mxb are still working fine, 
but i got nothing with this new MonomeSerial...

> actuel wrote:

> 
> can someone assist? SerialIO & _40h_Serial.mxb are still working fine, 
> but i got nothing with this new MonomeSerial...

went out for lunch and sunshine. started up MonomeSerial the same way as 
i'd been trying previous but now it works! (shruggs shoulders) good 
enough.

carry-on :)

actuel wrote:
> 
>> actuel wrote:
> 
>> 
>> can someone assist? SerialIO & _40h_Serial.mxb are still working fine, 
>> but i got nothing with this new MonomeSerial...
> 
> went out for lunch and sunshine. started up MonomeSerial the same way as 
> i'd been trying previous but now it works! (shruggs shoulders) good 
> enough.
> 
> carry-on :)

that sunshine'll get ya every time.

ok.  got this running and its awesome!  love the cable orientation 
option!

question: should it be saving my previous settings?  because every time 
i open it, it defaults to midi mode.  when i change to osc, it defaults 
to /40h for the output destination prefix.  so i have to change these 
both every time i open in order to work with older patches.

also, will there be save-able preset options?  like one for Live, one 
for older max/msp patches, one for new patches, etc?

anyway, great work joe!

lovin the cable orientation as well!

i'd also love to see save-able presets. additionally, is it possible to 
add to the I/O Protocol a "Both" option. so you could communicate 
OpenSound and pass along midi data.

so for example lets say i have mlr rewired to a track in Live. if you 
program midi notes in mlr, 8 per row, you could jam in rewire mode into 
Live and then while sending midi so you could go back later for editing, 
trimming, etc.

hopefully that makes sense. essentially, the other night i was playing 
mlr into Live via rewire and realized that passing along midi would 
handy.

so yeah, OpenSound/Midi (both) option.

actuel wrote:
> i'd also love to see save-able presets. additionally, is it possible to 
> add to the I/O Protocol a "Both" option. so you could communicate 
> OpenSound and pass along midi data.

this sounds awesome!  the only problem i can think of is that 
monomeSerial would also have to transform incoming midi note data into 
osc messages to be sent along to mlr (in your example).  otherwise, 
you're only sequencing the button presses of mlr and have no ability to 
play them back.

i love the potential of this idea, tho!

actuel wrote:
> i'd also love to see save-able presets. additionally, is it possible to 
> add to the I/O Protocol a "Both" option. so you could communicate 
> OpenSound and pass along midi data.

boom: http://forum.monome.org/topic/694#4299

jmelnyk wrote:
> actuel wrote:
>> i'd also love to see save-able presets. additionally, is it possible to 
>> add to the I/O Protocol a "Both" option. so you could communicate 
>> OpenSound and pass along midi data.
> 
> boom: http://forum.monome.org/topic/694#4299

whats in door #2...

Any news about Monome Serial OSC protocol support using Reaktor?
Thanks

yes, once joe gets the source code back together (it was lost), that bug 
will be corrected.

reaktor itself has a strange implementation of osc.

Thanks, I hope to contribute soon with some Reaktor apps

you can always use serialio for now...


reaktor actually has a pretty normal OSC representation, its just very 
comlete, in that it sends OSC-bundles, which start with timestamps.

the wierdness is just reaktor in general - it only does floats (well, 
not really, the ocre layer thingee does ints, but that cant reach out to 
the outside world of DAC or MIDI/OSC connections, or even GUI).  so, 
since reaktor only has floats, thats all it sends.  obviously it sends 
ints (bytes) for MIDI, but for OSC there is int and float, so it cant 
tell when you mean int and when you mean float.

if reaktor ever adds integers to its primary programming layer, and also 
strings, ill be in heaven i think!

Any news on monomeserial being updated to send velocity=0 instead of 
note-offs?
I get no reaction from ableton live to the monomeserial/monome led off.

are you using the most recent version?

i believe that problem has been fixed. let me know if it persists.

i'm using 0.13.
i'm trying to control ableton live 6.07 (newest) with just monome serial 
(os x) set to midi mode mapped to session view samples.

settings on monome serial
midi input device: monomeserial 1
midi input channel:1
midi output device: monomeserial 1
midi output channel: 1

settings on ableton live
input: from monomeserial 1 - track on - sync off - remote on
output: to monomeserial 1 -  track on - sync on - remote on

i can trigger sounds. i can see led feedback. the problem is that it 
stays lit.
i thought it was just using note-off data but now i know it isn't the 
case.
any ideas?

i just confirmed that the note-off values aren't turning off the leds. 
joe should have this fixed in the next day or two.

thanks for the heads up.

thanks for the update information.
go joe!

I'm running MonomeSerial 0.13 on OS X (10.4.10 PPC). When a program 
sends LED-on data to a point outside of the 40h's configured grid (0-7 x 
0-7, or wherever it's been offset to) there's a good chance that the 40h 
will freak out. All lights on, or some lights on, or dimmed lights. And 
generally needs to be reset (unplugged/replugged).

This is primarily of issue when using a 2x 40h setup, but also arises 
when doing something like mapping an 8x8 section of a larger Conway Life 
board (via Processing) to the 40h.

Things work fine when using SerialIO, but then of course there are none 
of the fancy new MonomeSerial features: custom prefixes, cable 
orientation, saved settings.

And speaking of saved settings, and a 2x 40h setup, MonomeSerial stores 
the settings for multiple devices, but seems to apply them from a stack 
as devices are plugged in and not per the devices' serial numbers.

fixes!

http://wiki.monome.org/Attachment/MonomeSerial0.15.tar.gz

- /clear now works as described
- /sys/prefix reported on any change of prefix
- midi note offs now work


i haven't had any out-of-bounds problems as you've described. if you 
could give me a detailed way to replicate the problem, i'll pass it 
along to get fixed.

as for settings saving, that's how we designed it to work. settings are 
saved per serial number. i'm not sure from your explanation what the 
problem is.

let me know.

woot! thanks mate.

It certainly occurred to me that the out of bounds problem might be 
something on my end, because it's universally repeatable (set the grid 
size in Life to larger than 8x8 as I mentioned, or with the new 
_40h_test patch light up some buttons outside the 8x8, or run mlr with a 
16 block-sized sample and play it across into the right half, &c, all 
with 1 or 2 40hs plugged in), and if it were actually a MonomeSerial 
bug, someone else would have definitely run into it.

So if it isn't turning up left and right, it's got to be something on my 
end. The confusing part lies in the fact that the problem occurs only 
when using MonomeSerial, that SerialIO works just fine. It must be some 
other aspect of my setup _in conjunction_ with some way that 
MonomeSerial handles LED outut differently than SerialIO does. What that 
could possibly be, I have no idea. Anyone?

Regarding the settings saving, something is definitely amiss. To test, I 
fired up MonomeSerial and configured two 40hs. I set the prefixes to /L 
and /R, for the sake of testing, and left everything else default. 
Unplug /L and plug it back in, and it's prefix is restored. Same with 
/R. Unplug /L then /R, replug /R then /L, prefixes are restored 
correctly for both devices. But, if you unplug /L then /R, and then 
replug /L then /R, the prefixes are reversed. It seems that the saved 
settings of the most recently unplugged device are being applied, 
instead of the settings matching the newly plugged in device's serial 
number.

thanks for the details.

i'll do these same tests and let you know how it goes (prefix saving)

for the out-of-bounds, try downloading the newest set of base patches, 
which has a large-grid in _40h_test.mxb, let me know how that treats 
monomeserial (move offsets around, etc).

random suggestion-- make sure you have the most recent ftdi driver. i'm 
not sure how monomeserial would ever end up sending mis-figured serial 
packets, it seems like their *must* be a bug if that's the case.

The new set of base patches with the 16x16 tester makes it very easy to 
cause the problem. I had written my own 8x16 tester last week to try and 
debug it, with no luck other than running SerialIO. (SerialIO works fine 
with the new test patch as well, after changing all it's prefixes to 
/box.)

Offsets and cable orientation don't seem to make a difference. Which of 
the 2 40hs is plugged in, or both, or which is offset to where, doesn't 
seem to make a difference. Out of grid LED-ons tend to mess things up, 
generally resulting in the 40h locking up, either in all lights on or 
all lights off mode. Sometimes button-in messages still work (more often 
on the 40h with the updated firmware than on the original).

It occurred to me this evening that teej is likely describing the same 
issue in this thread: http://forum.monome.org/topic/954

I re-installed the most recent FTDI driver, to no avail.

I am going to try to reboot my machine with as little as possible 
running (no Quicksilver or anything else that launches in the background 
at startup) and see if perhaps it is something else that I have running. 
I'll report back.

does this happen when you have only one 40h plugged in?

this is more than likely not about your setup. in os x everything is 
pretty consistent. i'll test tomorrow when i can and then try to get joe 
to fix it quickly. i'm fairly certain i'll be able to recreate the 
problem.

Yes, it happens with only one 40h.

I did just discover that with the cable orientations set to the SerialIO 
default (the left 40h has the cable to the left, and the right 40h has 
the cable to the right) the problem does NOT arise in MonomeSerial, as 
long as you limit LED-on messages to the 8x16 grid. Using _40h_test to 
send an LED-on message to some of the gridpoints bellow the grid will 
still cause errant lights on and lockups though.

I did some more testing. Ran under the guest user on my machine, and dug 
out my old PowerBook and installed the necessary software. And was able 
to reproduce the problem under both sets of conditions.

i downloaded the new 0.15 but the about MonomeSerial says the version is 
still 0.13

i've just noticed a little bug:

in ableton live if i select another mapped sample on the same channel 
without turning off/stopping the current playing sample, it doesn't turn 
off the led.

a good way to see this annoyance is to use follow mode on a group of 
samples mapped in series both in live and on the monome. they all start 
lighting up but just stay on.

@ joelb:

are you using the newest version? joe added midi note-off values should 
turn off the lights, though i only tested it with max/msp. i might need 
to do a more thorough debugging, though i'd appreciate a hand from 
anyone with some time.

@ kramer:

thanks for the version problem, i'll report it.

@ revbean:

weird, thanks for the info. i'll do some testing. could you also give me 
thorough details about your current system setup?

I've been able to reproduce the problem on two different setups:

PowerMac G5 running OS X 10.4.10
FTDI VCP driver 2.1.7 and 2.2.7
MonomeSerial 0.15 (and previously 0.13)
MaxMSP 4.6.3
(with a range of other USB devices, including a Wacom tablet and a 
USB/midi keyboard)

PowerBook G4 running OS X 10.4.9
FTDI VCP driver 2.2.7
MonomeSerial 0.15
MaxMSP Runtime 4.6.3
(With no other USB devices plugged in and no other device drivers 
installed)

I've tried plugging the 40hs directly into the computer as well as 
through a powered USB hub.

Original 40h and/or 40h/se. The /se tends to retain button press 
functionality for longer than the original, but this also leads to some 
stranger serial malfunctions, as illustrated in these two photos:

http://www.flickr.com/photos/bean/779444842/
http://www.flickr.com/photos/bean/779445204/

I added print commands to debug what Max was sending and receiving and 
it receives the correct button down and up info, and sends the correct 
LED on and off info in return.

In any case, once the 40h begins to malfunction the only solution is a 
hard-reset (unplug/replug).

thanks tehn, something else i've noticed with MonomeSerial is flin, 
anything past 3 rows down doesn't show width or speed. with SerialIO all 
is good.

using newest monome serial at current time. 0.15 (says .13 on about 
window).
the midi off works properly besides the bug i mentioned above.

@joel:

i'm not sure this is a bug in monomeserial, but potentially a problem 
with the way/order ableton sends out it's midi data. meaning it might 
not send out the "off" note for the first sample?

i really don't know ableton very well, can anyone confirm this vs. how 
the chuck routers work?

i just confirmed the settings per device saving bug, and the 
out-of-bounds bug, and the wrong serial number.

i'll let joe know right away.

Thanks!

http://wiki.monome.org/view/MonomeSerial-2

everything should be fixed.

- led data outside visible window is now filtered properly
- settings saved per serial number, not plug order
- version number corrected

And thanks again! Works like a charm for me.

is the LED/Ableton Live problem fixed?  mine still doesn't work right, 
LED's light up when triggered but dont go off.  When i use OSC and the 
_40h_midi.mxb everything works fine.

mine is still funny as well. they sometimes light up, sometimes stay on. 
it seems a little random.

i used to think it was just ableton lives way of sending note off but 
this works with other methods of osc conversion so i think it's 
monomeserial.

thanks for the heads up. i'll take a look.

i agree with you joelb, since _40h_midi.mxb seems to work, there's 
something in MAX's handling of incoming MIDI that needs to be 
incorporated into monomeserial...

this is a huge improvement!
great work

>mine is still funny as well. they sometimes light up, sometimes stay on. 
>it seems a little random.
>
>i used to think it was just ableton lives way of sending note off but 
>this works with other methods of osc conversion so i think it's 
>monomeserial.

I believe there is a bug with the MIDI implementation in MonomeSerial. 
it seems if multiple notes fire simultaneously at MonomeSerial, it only 
deals with one of them.  I only know this because I witnessed this bug 
sending MIDI to MonomeSerial.

I'm not too savvy on CoreMIDI but I'll look in to it as I'm updating the 
MonomeSerial to support the 64/128/256 devices, so I'm familiar with the 
code structure.

Also Live had a MIDI timing bug until 6.0.10, but this only affects 
so-called "VSTMidiEvents" (plugin->host), for instance from MonoChrome 
VST.

Best,
Steve