I’m trying to get Duplex and my Monome 40h to work on my new laptop (the old one crashed).
Renoise 2.7.1 + Duplex 0.97 = work fine.
Renoise 2.7.1 + Duplex 0.98a2 = work somewhat buggy
Renoise 2.8.0b5 + Duplex 0.98b9 = no response, no lights
Thanks - I’m investigating right now. Hopefully, a fix will arrive shortly.
Edit: yes, I had broken some stuff. I will just do a few tests and release it.
Oooo, fingers crossed this is why I was having LED problems rather than it being a serialosc thing!
Duplex 0.98b10 has arrived
- You can now link specific instruments to tracks in the StepSequencer: simply provide the same name for the track & instrument you want to link. - “Rotate” is a new application, basically a port of taktik’s Rotate tool which I found useful in combination with the StepSequencer (see the Launchpad config for an example) - A XYPad configuration for the monome with tilt sensor support has been added (monomeserial-only for now) - Improved support of multiple min/max values in XYPad application, plus some bug fixes - Automatic device configs : just copy a device-config to any /Configurations folder and it’s automatically included on startup
–
Firstly, the monome issue is resolved. Once I got around to reinstalling my OS, I soon discovered that I had messed up “normal” osc message while developing the bundled-message support for wireless devices.
But now, finally both monomeserial and serialosc support can be confirmed as working.
As for obtaining the right ports and addresses: I found this nifty little tool, which can locate the current port of the monome on Windows:
http://www.tobias-er…numBonjour.html
Mac users can use a similar program called Bonjour Browser, they both do the same thing.
I think it’s standard practice for the serialosc service to register at port 8000, which means that you could probably use these device options
Still looking for the place that serialosc1.0 put it’s configuration on windows, because when using MaxMSP applications this might change between sessions.
Been trying to monitor the serialosc process using ProcessMonitor, but I haven’t found anything useful yet…
Scratch that, their location has been found. Look here
I could get button presses to work with serialosc the first time I tried, but no LED-feedback. I used the enumBonjour tool. After trying with monomeserial I couldn’t get serialosc to work again. Don’t know why.
With monomeserial, press and feedback work fine. I actually used serialosc to connect the Monome to Pages, and then Pages to Duplex using monomeserial protocol.
There were a few bugs using monomeserial, I’m testing with GridPie:
The right column (pattern position/block loop) doesn’t work. No response from presses and no LED feedback.
Play button doesn’t stick, switches back to stop immediately.
The mute buttons stay lit all the time and doesn’t respond to presses.
Everything works using the GUI.
Oh, I also notice it says “Monome 64 [N/A]” on the device drop down.
I also have a few ideas for GridPie (I noticed three unassigned buttons in the monome 64 layout).
-
Auto capture instrument and track when selecting a clip would be nice (last selected, maybe a slow blink indicating the active clip). That way you can quickly select instrument/track and jam along.
-
A recording function. Press Rec button. Assuming the above suggested function, this enables pattern follow and edit mode (Indicating active clip with fast blink). This allows you to record notes and automation. Switching Rec off copies the edited clip back to it’s original position.
-
Another unassigned button could simply be an undo button.
-
And a third unassigned button could be copy. Press and hold, select target clip (indicating with blink), select destination… and the clip is copied.
Thanks for the bug report!!
It’s working here, monomeserial 0.2.1.5 and serialosc-1.0. But whatever the problem, I’ve had my fair share of trouble with both.
Confirmed, that’s a bug. The feature works on the Launchpad, though…hmmm investigate.
Strange, that’s working fine here. I tested with both serialosc & monomeserial.
Perhaps it’s a result of the pages translation?
Not a bug per se, just a matter of how OSC devices are presented. We don’t actually know if it’s connected or not, so perhaps they should be listed differently?
I can try installing and running through monomeserial directly to see if there is any difference.
monomeserial 0.2.1.5 wouldn’t run for some reason, some dll’s were missing. But 0.2.1.3 which I had used before worked. And what do you know… mute buttons and play is working. No right column tho.
Sorry, but although the monome wiki documents it, nothing actually happens - at least not here. It’s the first thing I checked after reinstalling.
Also made sure that I had run an MaxMSP patch through serialosc, disconnected and re-disconnected the cable, in case it was a question of serialosc somehow only writing a configuration file after it had been used. On OSX, the file is located where it should be.
So I’m guessing the most recent build of serialosc doesn’t comply with the documentation on the monome wiki.
ProcessMonitor is great then, because it can tell you stuff about a given process that would otherwise be left to guess-work (registry and file read/write, etc).
–
EDIT:: I found out what’s going on…
It seems that serialosc is trying to create the configuration in this location, but fails to do so:
C:\WINXPSP3\system32(null)\Monome\serialosc\m128-510.conf
I then created those folders, and added the following configuration (the exact location and model name might vary on your system, but you can use ProcessMonitor to obtain the right path):
server {
port = 8082
}
application {
osc_prefix = "/duplex"
host = "127.0.0.1"
port = 8002
}
device {
rotation = 0
}
Stopped and started the service, and now it reponds to the right port & prefix 
I seem to have got this all up and running and working now, both with my monome and with monemur on the Lemur iPad app. It was quite late last night when I got round to doing it so I can’t comment on any bugs or general weirdness at the moment, but the problem I was having with getting no LED feedback has gone - all lights are responding as they should - hooray!
I had to use the monomeserial bridge because a direct serialosc connection doesn’t seem possible (thanks for the tip nightmorph) - I wasn’t doing this before; I was determined to get it working without having another window open! I think my brain melted when I tried to get serialosc installed, then get all of the monome apps and then get Duplex running with it too, all on the same day. I really need to learn to take a step back sometimes rather than DO ALL THE THINGS!!! in one session…
Will report back with any glitches I find over the next couple of days, but like I said, the LED feedback is now working so it’s definitely all moving in the right direction!
The bridge is a workaround, but if it’s a good one then who is complaining… But still, it means that the whole Bonjour Browser vs. static configuration trick has not worked for you?
My personal experience on XP is like this:
monomeserial 0.2.1.5 works fine once connected, but can have issues connecting to the device
monomeserial 0.2.1.3 device connectivity and messages work fine, but the program itself is unstable
serialosc 1.0 configuration is tricky, and has a tendency to drop out after a while (problem seems to be on the Renoise side, more info is needed)
So, I’d say that for any monome + Duplex users who are XP based like me, monomeserial 0.2.1.3 is currently the way to go. But your mileage might vary.
Oh, and the serialosc issue I describe is actually a new one, it doesn’t happen immediately but seems to happen eventually. Like Renoise’s connection is somehow choking, because the more messages that are sent, the sooner it wll happen (with tilt sensors, a couple or minutes or so). Once this issue has been ironed out, I would not hesitate to call serialosc the better choice.
BTW: I have just committed tilt support for serialosc devices. Check it out.
I had been using the Bonjour Browser anyway and had been trying to assign static ports for a while but due to the way serialosc works (as far as I understand, and from what I’ve been seeing while I’ve been testing things over the last week or so), the port is replaced automatically on each new app you connect, and the settings in the .conf file are saved upon disconnection of the monome. So, if you connect to Duplex and set the port and prefix manually in the .conf file then disconnect your monome, the .conf file is saved with the prefix “/duplex” and the port number you assigned to it. Unlike the Max-based serialosc apps which have a dedicated “connect” button which writes this to the .conf file, Duplex doesn’t seem to be able to feed this info into the file itself so you need to do it manually. If you then open another seialosc-based app and connect to that the file gets overwritten with a new prefix and a new random port. This new config is saved again when you disconnect the monome, so if you then move back to Duplex the prefix and port are incorrect again until you manually change and save the .conf file again.
Since I realised Bonjour Browser only gives you the same info you can get from the .conf file itself, and I’ve figured out all the stuff I’ve posted above (which is just how I think it works, by the way - I may be wrong about some of the details), the browser app wasn’t really helping with anything I’d not figured out anyway. For some reason the server port for serialosc just doesn’t want to let me assign anything other than Max patches to it. The monomeserial bridge solution is fine now that I’ve figured out where the weak link was in the connection - it works a treat and saves you having to open text editors etc.
By the way, if anyone is running the Lemur monome app, the simplest way to get it working with Duplex is to change the prefix in the Duplex window itself, from /duplex to /monemur. It saves any kind of messing around with bridges or editing the Lemur scripts themselves, etc.
(edited for some kind of clarity, but I’m still not convinced that first paragraph makes a whole lot of sense… 
Did you get the “rejected, port already in use” message? Happened to me on OSX as well…
Feedback from Linux + monome/serialosc users would also be greatly appreciated 
I was getting “already in use” message when I was first trying this out, yes. I’ve not had it since though, now that I’ve realised what I was doing wrong.
Maybe this is a bit dense of me, but I hadn’t realised that the server port listed in the .conf file is the port number that needs to be used as the output from Duplex. Obviously the port listed under the prefix and host address in the .conf file is the input for Duplex, but I was looking for a third number to use as the output - that’s why I was having so much trouble getting the LED feedback - I was looking for a port number that didn’t exist, and ignoring the one which was right in front of me. SInce I sussed that one out it’s made sense - the port error message happens if you assign the server port to the input of Duplex, which is how it should be, as you don’t want information flowing in opposite directions from the same source. I’ve never had the error when I’ve assigned that port to the output of Duplex, as the data from Duplex is flowing in the correct direction, back to the monome.
Having said all that, even though I managed to stop getting the errors I still couldn’t get it to work without the monomeserial bridge!
hey everyone, duplex works in pages version a30 now.
http://monome-pages.googlecode.com/files/pages-0.2.2a30.zip
for future reference the issue seems to be that Monome64 -> Grid Pie was sending, for example, /duplex/led 15 0 1 instead of /duplex/led 7 0 1 to light up the far right column. monomeserial / serialosc were correctly handling this but pages wasn’t. it is now! 
enjoy.
edit: pages external app config that works for me is:
OSC Prefix: /duplex
OSC Hostname: 127.0.0.1
OSC In Port: 8082
OSC Out Port: 8002
Hello,
I have some some problems with this new Beta. First i’m very glad see a new feature : the mackie control !!! i have tested to program this but it was not as such functional as your one…
My sound card is the Mastercontrol from Alesis and it’s a mackie control like.
The problems when i try this presets (mixer and recorder) are :
- leds turn “on” but not “off” on the Mastercontrol (is it because the function doesn’t work in the two way just “in” and not “out”?)
- some buttons are the good one (to move between tracks for example)
- the rotary control isn’t work and we can not move into the song
Otherwise, it works but but when all the leds are “on” i don’t know where i am…
In any case, thanks a lot for this usefull (for me) feature.
If you need some help to continue this code email me even if immediately i don’t know a lot about Duplex Code 
Excuse me about my english, i’m french… 
Hi,
Oh, I can replicate this issue on my nanoKONTROL2 too. I’ve misunderstood that it is the nanoK2’s dedicated issue. It should be fixed.
@danoise;
Below is the difference of the signals between Mackie-Control mode and CC mode. Simply these are the results when I pushed a Mute button twice. Could you tell me where I should edit??
(It seems that we need “Note-ON signal with 0 velocity” for turning off leds, maybe. 
)
Mackie Control mode:
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI 90 10 7F
MidiDevice: nanoKONTROL2 1 CTRL send MIDI 90 10 7F
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI 90 10 0
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI 90 10 7F
MidiDevice: nanoKONTROL2 1 CTRL send MIDI 80 10 0
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI 90 10 0
Common CC mode:
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI B0 30 7F
MidiDevice: nanoKONTROL2 1 CTRL send MIDI B0 30 7F
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI B0 30 0
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI B0 30 7F
MidiDevice: nanoKONTROL2 1 CTRL send MIDI B0 30 0
MidiDevice: nanoKONTROL2 1 SLIDER/KNOB received MIDI B0 30 0
Ahh, this is because that current Duplex does not support relative knobs yet. Just wait until it will be implemented in the future update.
So, the problem with the LED only applies when using the (note-based) Mackie Control mode, and not the common (CC-based) mode?
Yes, any incoming notes with a velocity of 0 is already interpreted as a note-off. I can’t remember if something similar is happening to outgoing communication, but I’ll check what can be done about it.
Yes, only when using the Mackie Control mode.
The LED which turned on once never turned off unless I extract USB plug. Changing config cannot turn off LEDs too.
I confirmed that turning on&off LEDs works in Ableton Live, with this Mackie Control mode.
Btw, this is the problem only about LED.
I can control Renoise correctly except the LED behavior.