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!
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
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
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. )
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.
Yes, of course the mackie control mode works with cubase, live and other application… I don’t how it works with software.
It’s seem it’s just duplex that don’t send the “off” message to hardware, so if you’re pressing button on hardware or in renoise leds should turn on or off.
The problem don’t make renoise unusable but it’s just annoying for live.
Which is something which should be fixed, obviously
As the lead dev of Duplex, I have been a bit on a time-crunch lately - but I’ll promise to look at it ASAP
It’s probably simple to fix, but it’s always more tricky when you don’t actually have the hardware…
Duplex 0.98b11 has arrived: download link has been updated, as well as SVN
New core classes: UIKey, UIKeyPressure, UIPitchBend, OscClient
New application: Keyboard (including various device-configs)
Release notification for applications
Event handlers now receive message as argument
New option for MidiDevices: “allow_zero_velocity_note_on”
The big news (apart from a large number of internal changes and additions) is the ability to trigger samples via the Keyboard application.
A lot more info on that one is arriving shortly, as a separate topic. Edit: here
If this is the case, could you check with the new release? I have made it an option to allow sending notes, having the feature turned on for the Mackie Control.
I’ve found the most stable and reliable way to use my monome with duplex is to use the monomeserial configuration in duplex and the Max 5 serialosc->monomeserial bridge patch. Of course not the most ideal solution, but it seems to work consistently.
I did a quick edit to the monome128_keyboard lua file to try it out on my 64 (I just took out all the pads on the right.) Seems to work great, thanks for your work!
Cool, the monome configuration is a bit on the simple side ATM.
I think the final version should be a little more like the launchpad, where you at least get to control volume and have one (or more) keyboard splits to work with?
Is there support for Novation Remote SL61 (version 1 not mk2? I see mk2; or is mk2 backwards compatible with v1 SL61?).
Nevermind I sorted this. It works backwards compat. I had to choose “User2” as automap target on SL61.
Wow, this is crazy. Renoise is working better with my hardware than Ableton.
Presonus FaderPort: works flawless
APC40: works 99%
Remote SL61: works flawless
This is truly a testament to the skill of the development team of renoise.
Massive props. You guys are my fucking heroes.
I able to get the FaderPort and APC40 working together in Live, but not consistently - it was buggy. The Automap in SL61 clobbered some other stuff too. Renoise actually works better than any others so far.
I feel a little bit spoiled having so much control, but the reason I have these devices is because I couldn’t get some to work in other hosts; StudioOne and FaderPort obviously are in harmony, but so is Renoise now.
You guys are making it extremely hard to justify using anything but Renoise. If I didn’t have the need for a piano roll and session -> arrange recording in live (and the follow actions), with some better audio track handling, I wouldn’t even use any of the other hosts I own.
I’m willing to test and help out with Renoise in any way I can with my hardware devices.
Also I have an iPad and can help test touchOSC or OSC or whatever you guys need.
A while back, I received some feedback that a few controls didn’t work in SL 25 mk1 (namely, buttons beneath the faders). But perhaps this is not an issue with your device, being a different model and all?
That would be rather awesome. TouchOSC on iPad is possible, but so far we’ve not made any configurations for it. It wouldn’t be hard to make, but for some reason the TouchOSC editor doesn’t come with the iPad templates (except one called “Mix 2 iPad”), and I would like to base any standard Duplex configuration around those (as they are accessible to Android users as well. For some reason, you can’t edit nor import TouchOSC templates to that platform).
Assuming that the iPad version of TouchOSC comes with a set of templates made specifically for that device, does anyone knows where it’s possible to pick up these files?
enjoy.
)
