Hello I came here interested i nthe remote control of an M7cl and saw the total remote thread which is closed. I am hoping to gain insite on all he did as it ws exactly what i was needing.Also the answer here let me know that what he was doing on the 01v should work on the M7 also
Hello cuzzlowe.
It’s good to see that you are on the same road! I moved the Total Remote thread to a blog on Andy’s site - Andy pointed out that it would work better. I have not updated it for a while (too busy). You will find it at http://www.checkcheckonetwo.com/forum/entry.php?11-Total-Remote-Mixing-(part3)
One thing you should know - I have gone back to sysex for my FOH BCF2000, as it was much too slow using NRPN. The on-stage monitor controls (also BCF’s) are still using NRPN which is fast enough for the ocasional changes that the musicians make, and allows “change recorder” to work. I do not need to record my FOH changes.
My blog is a bit “wordy” but I hope understandable. I think that it should all work for the M7CL. Andy will know for sure.
All the best, and any problems or new ideas - please let me know.
David Kent.
Thanks for letting me know . We are using an M7CL which uses an eithernet DME-N forr studio manager rather than usb like the 01V. I have never worked with midi but am hopefull we can get studio manager and a remote surface to work at the same time as the sound system designers in this very expensive venue put the console where you can’ see or hear the speakers. At present studio manager is used out in the house but the lack of being able ot control more than one fade at a time makes it pretty limited. IM pretty sure We would haveo do al the hookup via eithernet and wifi
I just double checked. The M7 is still using midi (sysex) messages to talk to Studio Manager (but via DME Ethernet). I can give SM (M7CL) a couple of ports to connect to ( Maple or MidiYoke) and see the sysex messages being produced by SM arriving in MidiOx. The PM5D software for SM is the only one that would not produce any messages unless actually connected to the desk (no idea why?). The messages will be the same format as I am using for the 01v96, but the “desk name” byte will be different.
Unfortunately, although I had an M7 in front of me all last week, I am not likely to see another one for a while, and I did not need to use a control surface as I was the sound designer and the desk was in the correct position (Dammit!). You will be able to capture and examine the sysex messages in midiox, and then tell your control surface to send such messages, but I do not know whether you will be able to connect your surface through MidiOx to the same ethernet connection. You might find that it is possible, but I have found the M7 to be a bit “touchy” about it’s ethernet, and I have had to reboot the desk on occasions to re-establish the connection. You will almost definitely need to establish the SM to desk connection, and then break into it once all of the ports are established.
If you cannot do it that way then you will need to use a midi extender sytem to connect to the desk’s 5-pin din connections, and then use the sysex or use the standard Yamaha NRPN messages to control the desk from your surface while using SM over DME at the same time for all those things that your control surface is not really set up to perform.
If you have a midi in/out box for your computer then you do not have to use DME at all, as you can set everything up via 5-pin midi.
I will be very interested to learn whether you manage to merge SM and your control surface over DME via MidiOx, as I will certainly see an M7 again sometime. OK, it’s true, I am just, sadly, interested.
All the Best,
David Kent.
Wow i was just about to post and i got booted. So Ill try to do it again
I have successfully come up with a solution although it was not as simple or as elegant as i has wished. Studio manager will not share its midi connection with the console be it dme or regular midi. I can use dme to control the console with the bf2000 but not if studio manager is using it. Once studio manager takes a path to the console midiyoke cannot use that connection. Thus I have spent most of my time working on midi Ive ip. I was hoping to be able to use a wireless usb hub like the belkin but even the belkin site says they are unavailable. I cant afford to use something that cant be replaced so in my search i found a couple network to usb servers.
Unfortunately they seem to be one way devices. midiyoke will give an error saying can’t connect the output. As I need control and feedback from the console to the bf2000 I had to find another solution. I have come up with two approaches both of which require 2 computers, one for the remote location with he bf2000 attached and the computer running studio manager connected via dme . The other computer works as a usb server with a usb to midi adapter connected to the console. A usb audio device could be attached also for solo etc. I tried ipmidi combined with midiyoke and other than quirks in the demo version it works well with no latency issues, but it is strictly a network midi connection and will not go over a router (IE Internet). I have used 3 different usb over network sharing solutions. One by Etima software was so slow I could move a fader and look over to the other room and then watch it move on the console.So it was out of the question. The other two one from fabula tech and the the other from kernalpro both work well. They both have client and server programs . The computer at the console is the server sharing the usb midi adapter. The client runs on the remote computer and connects the bf2000 to the midi adapter with midiyoke. Both programs have demo version and the license is scalable by the number of devices you want to share. Kernalpro is the cheaper but you need a static ip address for the server. Fabula tech will find the server by computer name. This system works well with wifi and i saw not signs of latency. On a different note. In the version 3 of the m7cl, solo is no longer an option on studio manager although it can be programed into the bf2000. select is no longer a midi function. If you select something on the console it does not change your views in studio manager and vice versa. It has and is an interesting learning experience. My next feat will be to go the other direction to try to use several br2000’s for monitor mixing from the stage .
That’s a lot, and very interesting. I will have a sleep on why certain of your experiments didn’t work.
I have been using a BCF2000 connected via midi 5-pin to the desk and usb to a belkin 5-port hub. The hub then connected over ethernet to my PC and MidiYoke. That works fine while SM on the same laptop is talking to the desk over the same Belkin Hub and ethernet connection, but I have an 01V96 connected to that hub via usb which is not the same as your setup. However, that BCF communicates both ways with MidiYoke without any problem. It works over wi-fi with the hub connected to an access point, but is unreliable if the connection is lost, so your upnp solution is much better. I just don’t want to carry another laptop. It surprises me that MidiYoke will not establish the output connection, unless you have not established your connections and made the port available to MidiYoke first?
Note that if you use the bcr2000 for monitor control on stage rotary controlers are a bit more complicated to set up. The BCF2000 faders will output the resolution that you desire (0-16383 or 0-1023 or 0-127) over their travel, and will even output in reverse (useful if you are an old BBC engineer). However, if you try to output NRPN at 16383 resolution on a rotary encoder you will still be turning it at Christmas, as the rotary encoders are set to send 96 messages per revolution. There is a solution using SysEx, the .tx command and the .resolution command - see Behringer’s Secrets at: http://shoshin.110mb.com/genmce/bcr2000/files/SecretBC.pdf
Using this command you can tell the BCR encoder to go faster as you turn faster, so you get the resolution that you require when turning slowly and make greater jumps as you turn faster. But, it is a Sysex command, so the BCR will not respond (on it’s LED dial display) to any changes initiated in NRPN, and any subsequent change on the BCR will cause a sudden jump to the previous BCR value. This is probably not a problem as the only changes are likely to be made on-stage.
A thought! - You might be able to use .resolution with .easypar if you edit the .syx file in a text editor and add the .resolution command and it’s parameters at the end of each .easypar NRPN data set. - it is not clear to me - it’s a very BIG “might” be possible. You cannot do any damage by trying, the BCR will just reject the SysEx if it doesn’t like it.
I will post again if I have any other ideas that could be useful.
David Kent.
Hello,
I’ve written a Max5 standalone software to control M7CL remotely by using iPhone, iPod touch and iPad. It is called “KiwiRemote”, can receive OSC datas (fader and pan) from the mobile phones and convert into the midi sysex and send to M7CL. I am musician and play in a Pop Band, and all band members uses in ear monitors. We use KiwiRemote for 3 months and it works great. Even FOH engineer mixes us by using it.
If you are interested in, you can download and try the software from the site www.kiwiremote.com
Best Regarts!
Soner KIVANÇ
Hello,
I’ve developed a software called "KiwiRemote"to control M7CL remotely by using mobile devices like iPhone, iPod touch or iPad. It receives OSC datas (fader and pan) from mobile devices, converts to Midi Sysex and sends to the M7CL. I and My band have been using for 3 months and it works great! We can use simultaneously when soundcheck and giging. If you want to try you can download from the site instantly " www.kiwiremote.com ".
Best Regards!
Soner KIVANÇ
support@kiwiremote.com
I am replying to my own post, as I was wrong about the “.resolution” command. It can be used under “.easypar” and can therefore be applied to NRPN, and cannot be applied to a SysEx “.tx” command in the BCL programming language! The editing utility from Mountain utilities has some great info and tools - http://home.kpn.nl/f2hmjvandenberg281/bcman.html
David Kent.