Check Check One Two Forums - Blogs

Remote control - any Yamaha Digital desk - with Studio Manager and the BCF2000

whale-av — Sun, 02 Jan 2011 11:38:14 GMT

This has been thrown together, so there could well be updates. You will find all the screenshots and a copy of this document as an attachment (below).

I have bitten the bullet, and gone for a setup with two laptops, one at the desk position, and one remote, connected by a VPN, and running rtpMIDI for any midi that I need to transfer between the laptops. I am using VLC as a server for the headphone monitor from the desk to the remote laptop. The Mac version of rtpMIDI truncates NRPN messages for some reason (it is fine with SysEx). Andy's "Sends on Fader" and "Change Recorder" are only available for PC. Everything else works well on the Mac, and sometimes better, but "Everything Else" is unfortunately "Not Much". However, if you stick with SysEx only over rtpMIDI then you can use any modern Apple device including the I-Phone, and of course your laptop for remote control. rtpMIDI is called "Network" Midi Device by Apple. If both laptops have the same screen format, 4:3 or 16:9 you can avoid endless scrolling on the VPN viewer.
The laptop at the desk is most usefully a PC as Andy's Change recorder is vital when using BCF2000 units for the band to control their own in-ear monitors. These BCF's need to be running NRPN, as if they are running SysEx they cannot "follow" the desk or each other, and anyway Change Recorder records NRPN and not SysEx.
The Yamaha Digital desks "talk" SysEx with Studio Manager at any resolution up to 0-16383.
They "talk" NRPN via the 5-pin DIN connectors at 0-16383 (14-bit ABS) resolution if NRPN has been selected on the desk MIDI setup, and "high" as the resolution. BUT NOT ALWAYS, the Gate Knee has a resolution of 1023! I am looking at using "low" resolution (0-256) in large setups so as to increase the NRPN speed, but that requires some more study.
When the desk receives NRPN at the Midi-In it outputs the equivalent SysEx to Studio Manager.
When the desk receives SysEx at the Midi-In it executes and sends it though to Studio Manager if it understands the message.
When the desk receives SysEx from Studio Manager it outputs NRPN via its Midi-Out.
SysEx is only seen at the Midi-Out connector if a Parameter or Bulk Dump request has been sent.
When "Sends on Fader" is in the flow synchronisation of Studio Manager with the desk can be badly affected by any attempt to break into it's connections using MidiOx.
Because we are dealing with any "Yamaha Digital Desk" we must not use desk specific SysEx ( F0 43 1n 3E 0D .... F7 ) (01v96) but commands in a format that will work with any Yamaha Desk ( F0 43 1n 3E 7F ...... F7 ). EXCEPT THAT IT IS NOT THAT EASY! There is a table in the attached folder showing some troubling differences depending upon where you input your data, and in what format.

If you are using more than one desk then you need to use ID's, and be careful about where you send any data. See the Yamaha docs if you are using for example two 01v96 desks with different ID's.
NRPN is not desk specific, and should be (nearly) the same for every Yamaha Desk, and therefore you have to be even more careful about where you send your data.
There are two files in the attached folder for control of channels 1-8 on a Yamaha Digital Desk using a BCF2000. You can dissect them most easily using "Birdie" http://rapidshare.com/#!download|332...edit_V0.41.zip
NRPN .... This has channels 1-8 in NRPN on faders, Toggle on/off in NRPN on (lower) upper buttons and Select (01v96 only) in SysEx on (upper) upper buttons.
SysEx ..... This has channels 1-8 (any Yamaha Desk) in SysEx on faders, Toggle on/off in NRPN on (lower) upper buttons, Solo (01v96 specific) in SysEx on (upper) upper buttons and Select (01v96 specific) in SysEx on the knob buttons.
All the BCF2000 units are in mode U3.
NRPN is a bit slow, as each control has a resolution of 0-16383, so it is not suitable if I am using a BCF2000 for FOH mixing with 8 faders moving at the same time. In that case I am using SxsEx where possible at a resolution of 0-1023. I have to use NRPN FOH for the toggle ON/OFF of desk channels, as I cannot "toggle" a SysEx command on the BCF2000. I could use SysEx with 2 separate buttons, one for ON and one for OFF, but there is no need as the NRPN value is only 0 or 16383 so fast enough. The BCF button lights do not respond correctly to received NRPN commands however. This is not a huge problem. Using Apple OSX on the remote laptop I cannot use NRPN for on/off (see 1st. paragraph).
I am using Andy's "Sends on Fader" for any monitor level changes that I need to make from FOH, as then "Change Recorder" and the desk are correctly updated, but unfortunately not any band BCF's that are on a different set of controls (I can ask the desk to send updated info when the BCF's change presets, but it is a SysEx request and the reply is SysEx, which the BCF's do not understand).
((Note to Andy - could Yammie be programmed with an option to "Play" it's recorded file every few seconds, so that everything is constantly updated?))
It is important that all of the BCF2000 units are set to different ID's and that they have the latest Behringer driver associated with them (V1.2.1.3) as then they all have different names in the computer {ID1 will be BCF2000(1)}. Otherwise setting up the system is a nightmare. If you see "USB Audio Device" in "Device Manager" associated with a BCF2000 then you need to update the driver and choose the correct driver yourself. "Search Automatically" will not find the correct driver.
rtpMIDI http://www.tobias-erichsen.de/rtpMIDI.html and the latest version of MidiOx - MIDI-OX BETA 7.0.2.372 - do not lose any packets.
If you are using wifi for the remote laptop and you lose the connection rtpMIDI normally reconnects, but the VPN might have to be reconnected and MidiOx ports might need to be refreshed (closed and re-opened) if they are connected to rtpMIDI.
Beware which devices you connect to the same USB host. The host controller directs traffic flow to devices, so no USB device can transfer any data on the bus without an explicit request from the host controller. In USB 2.0, the host controller polls the bus for traffic, usually in a round-robin fashion. The slowest device connected to a controller sets the bandwidth of the interface.

Now the Setup.

Studio Manager and Sends on Fader are connected directly to the desk by USB or ethernet as shown in Andy's "Sends on Fader" setup instructions. They are not connected to MidiOx.
Change recorder is connected to Maple Midi ports 3 and 4, but these could of course be MidiYoke3 and MididiYoke4 or others of your choosing.
The BCF's are also shown in the MidiYoke map and are self explanatory.
The Input in MidiOx "Mezzanine for MidiOx" is the input from the rtpMidi connection.
In the screenshot "all talk different" the BCF's all update the desk (and then of course Studio Manager) through the "Terratec" Midi ports.
In the screenshot "all talk" the BCF's also update each other as well, but this is of course not normally necessary.

If the desk is on stage:
The laptop connected directly to the desk is running "Sends on Fader" and Studio Manager, rtpMIDI, MidiOx, a VNC server, a VLC server for the FOH headphones, and "Change Recorder". It can also be running a Media Player for playback, and recording software. The recording can be digital at the sample rate of the desk. I run the playback analogue into the desk so as to avoid sample rate problems. There are some screenshots of the laptop dirctly connected to the desk in the attached folder
The FOH laptop is running a VNC client, VLC to receive the Solo signal, rtpMIDI to send the SysEx from the FOH BCF2000, and something to send SysEx to the BCF's during setup.

If the desk is at the FOH position:
The laptop on stage is running MidiOx to gather the BCF's and rtpMIDI to send the NRPN to FOH. Also "Change Recorder" and a VPN server so that it can be controlled remotely.
The laptop at FOH is running "Sends on Fader" and Studio Manager, a VPN client, rtpMIDI and MidiOx. Personally I am also running Quicktime for video on a projector and sound to/from the desk.

If the desk is elsewhere (5th balcony, behind glass):
The setup is similar to the desk being on stage, except that the laptop at the desk position is connected to the onstage BCF's via a Belkin Network USB Hub over a FIXED ethernet connection. Wireless is unadvisable for this connection as MidiOx does not like to lose it's ports.

IF I SEND SYSEX TO THE MIDIIN ON THE DESK IT GOES THROUGH TO STUDIO MANAGER, BUT DOES NOT ECHO NRPN AT THE MIDI OUT. In order to update on-stage BCF's which are running NRPN on the same channel parameters the SysEx needs to be put into the input to the desk via USB from Studio Manager. I have kept the Sends on Fader/ Studio Manager Midi separate from MidiOx to avoid any conflicts, and so am unable to do this. Anyway, my FOH BCF is controlling the input faders, to which the band do not have access.
02.12.2010 Whale AV - David Kent.

Attached Files

Total Remote Mixing (part3)

whale-av — Wed, 31 Mar 2010 11:10:40 GMT

To download this blog, with the pictures that are missing, go to
http://www.checkcheckonetwo.com/foru...4&d=1270328744

I have ordered some powerline ethernet CPL adapters.
It took me a while to remember my setup for testing for BCF Sysex commands. It was pretty simple. Just put the BCF in Mode 4 and connect output �A� to another midi device and then you can record just the sysex that the BCF is receiving.
So the command for �SEND ME BACK THE CURRENT PRESET and don�t even think about it� is:
F0 00 20 32 00 14 40 7F F7
The trouble is that the information returned does not say what the preset number is.
I start to wish that I never had!
But it does return a �name�. This name�s default is �init�, but it can be changed in all of the BCF editor programs. It will not show up on the BCF�s display. Behringer say that the firmware will not support it (true?), but when you save your Preset setup to the BCF the name goes with it, and when you retrieve that file from the BCF it comes back. So now I can identify the current preset when the power comes back. Yes, the BCF starts up where it left off, just like your car, it just forgets who was along for the ride.
The "Name" will be bytes 34,35,36,37,.......... of the returned file, and of course as this is Hex and the first byte is numbered "0" we are looking at the 53rd to the 56th+ bytes in the list.(in decimal-speak). This name can be up to 24 Bytes long (the space is reserved), but of course I will only need to use the first two (for my preset names 1-32). Beware, the file contains another 'init' a little later, which clears the edit buffer.

And then, while I was looking for something else, I found

SEND ME BACK THE CURRENT PRESET NAME
F0 00 20 32 00 14 42 7F F7

And it does just that! It returned: F0 00 20 32 00 14 21 00 7F 41 6C 65 78 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 F7

In this case the preset name was �Alex� � 41 6c 65 78 in hex, and 24 �name� bytes have been returned . I don�t know as yet what all of the part F0.....7F means. F7 means �end of message� as usual, and some of the rest I can guess at. The 21 is 33 in decimal. Maybe that means that the current preset is held temporarily as preset 33 while it is being used?

So now a bit of sysex "request" message analysis:
$F0 System exclusive message header
$00 $20 $32 Behringer
$00 Device ID = $00.....$0F (=ID on actual device) or $7F(=any)
$14 Model = $14(=BCF2000) or $15(=BCR2000) or $7F(=any) or $xx?(=BCD2000)
$42 Command = well, we now know some of them!
$7F Preset $7F(= current) $7E (= all or any) $00....$1F (preset 1...32)
$F7 End Of Exclusive message

I want to be able to tabulate the data that is returned and use it for recovery automation so I am now off to learn some VBS script, and to mow the lawn (BLOG).

A+

Hopefully I am pretty much finished with Sysex, NRPN, and Midi at this point.
If I keep it simple and just name my preset Sysex files 1.....32 then I will know what it means in my real world. Although this could become complicated with the Hex, I am trying to automate a process, so I think that I will stick with real world for the bits that I will have to deal with manually, like making new preset files, and sort out the hex connundrums in the programming.
I would like two files, one that I can run at Boot � before a soundcheck, and one that I can run if the power goes down.

AT BOOT:
Start
Ask for confirmation that all components are plugged
Open Belkin Control Center
Close (minimise) Belkin Control Center
Start MidiOx
Load MidiOx Profile
Minimise MidiOx
Open SOF
Open Studio Manager
Open Console Manager
Establish Console Manager Midi links
Synchronise Console >> Pc in Console Manager
Open Change Recorder
Load Last Change recorder XML file
Confirm, and show and ask for confirmation of/offer to change Last BCF current Preset sync XML file data

Open BCF Current Preset sync file
Ask BCF (idx) Current Preset and parse data
Insert Data to sync file
Repeat (governed by sync file - file must be set up with data previously listing the presets used)
Set all BCF to Preset 1
Play Change Recorder
Repeat (governed by sync file)
Set all BCF to last current preset parsing data from Preset Sync file
Start Change Recorder Record
Confirm
End

IF POWER FAILS:
Start
Stop Change Recorder Record
Save Change Recorder Recorded XML file
Close Console Manager
Close Studio Manager
Close SOF
Close MidiOx
Exit Belkin Control Center

Ask for confirmation that Power is restored
Open Belkin Control Center
Close (minimise) Belkin Control Center
Start MidiOx
Load MidiOx Profile
Minimise MidiOx
Open SOF
Open Studio Manager
Open Console Manager
Establish Console Manager Midi links
Synchronise Console >> Pc in Console Manager

Open BCF Current Preset sync file
Ask BCF (idx) Current Preset
Insert Data to sync file
Repeat (governed by sync file - file must be set up with data previously listing the presets used)
Set all BCF to Preset 1
Play Change Recorder
Repeat (governed by sync file)

Set all BCF to last current preset parsing data from Preset Sync file
Start Change Recorder Record
Confirm
End

I would like a post-show shutdown script as well. I have left out things like "start Audacity, pause, record" etc. Once I have a better understanding it will be easy to put such things in.
The three scripts will be very similar, but as I have done almost no programming since Fortran was the leading language (Cobal was just starting for this sort of application) this bit is going to take a while. Don�t hold your breath. Instead, you could write some of it for me if you like?

If you are holding your breath.... STOP.
Here is something else.
You will remember, if you have read the start of this Blog, that I wanted to be able to monitor the 01v96v2 (or other desk) SOLO at my computer.
First I must explain my setup. My 01V96 is on stage and connected (along with my USB soundcard and BCF's for the band) to a Belkin 5-port USB Hub which is connected via ethernet (wireless works too, but at short range) to my laptop. I have another BCF connected to my laptop for mixing and other control (such as fine aux tuning).
Trying to monitor at my laptop I had no luck with "Jack Control". XP does not allow connection of one soundcard input to another soundcard output. But the problem is solved with "Audacity"- http://audacity.sourceforge.net/download/. Preferences set to "software playthrough" ticked, and then the program set to input from my soundcard and output to my laptop soundcard and then put in paused record and minimalised.
I had tried the separate program called "software playthrough" but it Hung repeatedly.
This works with a slight delay when monitoring, which is actually helpful when trying to identify hums and buzzes and distortion.
I can play audio from my computer to my 01V96 at the same time. Playback is with micro-mini-tiny latency. The soundcard is connected analogue (for simplicity) to the 01V96 headphone socket and a couple of inputs.
This setup in XP Pro uses 18% of CPU and less than 5% of the ethernet connection when maxed, and is stable unless I pull the ethernet plug repeatedly. I can access the internet via wifi, and play videos to screen with the audio to the 01v96 without problems with the audio or the midi or the Video, but I would not recommend surfing as the audio will always go to the mixer and you might forget to mute the inputs.
In OSX the same setup works with Midipipe, but the Belkin Hub cannot access my Terratec Phase26 soundcard, so no monitoring or playback. I have just bought a Maya44 which might work, and which should anyway allow me to record the desk output at the same time.
The graphic representation of SM2 is not as pretty in OSX, and OSX has some problems mixing sample rates that XP handles easily (by re-sampling everything at 48K - YUK), but the setup is extremely stable, not caring one Hoot if the ethernet connection is repeatedly broken.
I am also working on foam pads for the BCF faders, as in quiet numbers or conference situations I do not dare to use the BCF�s unless I remember never to return the faders completely to Zero.

I received a couple of Devolo CPL's - CPL Devolo MicroLink dLan 200 AVdesk. They plug to the mains with a cable, which I prefer as I find that "on tour" anything with a plug built in gets broken. They tell me that they are capable of about 50mb/s when they are about 20M apart and on different phases (my house has 3phase power) and I have had them running my system for a day now without any dropout. I had put every lighting dimmer in the house at half power, and turned on all the fluorescents in the basement as well. I am now going to see whether I can access my setup from my nearest neighbour, who lives about 500M away. I will be pleasantly amazed if it works!

David Kent
Whale AudioVisual

Attached Files

Total Remote Mixing (part2)

whale-av — Tue, 30 Mar 2010 13:21:00 GMT

To download this blog, with the pictures that are missing, go to
http://www.checkcheckonetwo.com/foru...4&d=1270328744

If I feed the NRPN back to the BCF then its faders will not move as they are sending sysex ((see the bit you jumped!)) and don�t recognise NRPN. Great? But this feature is not necessary, as my chosen faders are only being moved by the BCF (FOH by me, monitors by the Band), and as I change pages on the BCF (ch1-ch8 >>> ch9-ch16>>>> and back again) the faders will move to their new positions each time anyway as they are held in the BCF�s temporary buffer.
The problem rears up if there is a power failure. I am looking of course for a stable system. The BCF�s will then not remember their last fader position unless I have the presence of mind (and the time to waste) saving every move that I make. On power up any fader movement will write over the last value of the desk, and as the faders are at minus infinity when I change pages (on the BCF�s) the mix will be destroyed by immediate mutes.
Change Recorder to the rescue. It only talks NRPN and remembers always the last values that it has received for all parameters. As the desk is spitting out the NRPN equivalent of the Sysex messages that it receives from SM and the BCF�s, CR will hold the latest values for all parameters at the moment that the power is turned off by that idiot who won�t own up! Stop CR Record (I am using a laptop, with a good battery!), and once the power is back up play back the NRPN. The BCF�s will receive the NRPN and the motorised faders will set to the value received. NO THEY WILL NOT � because they are sending sysex they will not recognise the NRPN values.
Back to the drawing board.
Now is the time to nearly forget about Sysex, although I hope that what you have seen above will help your understanding of the whole caboodle.
NRPN turns out to be easy in Birdie:

This is a screenshot of the setup for the first (1-8) faders. I believe that it will work for any Yamaha digital desk, but that I have not verified. All of the settings can be programmed directly with very little typing required (READ BIRDIES INSTRUCTIONS ON HOW TO USE THE PROGRAM!).
Now my BCF�s will receive NRPN and the motorised faders will move. However, when they move they will send their new position (required, that is their purpose after all). This NRPN will be sent back from the desk and will be received by the BCF. This sets up an indirect feedback loop and is disastrous.
So � I do not want to connect the BCF�s to the midi out of the desk. I want to record the midi out from the desk in CR, and then play back CR after a power cut, repeating the playback for each preset on each BCF. Now I want to be able to automate this. How? With sysex program change messages I expect. I am going away to look at that right now.
Today, 10 March 2010, that is as far as I have advanced. Andy is I hope going to modify CR (see my last couple of posts), and he will give me a recoverable set-up on a silver platter!
This has become a bit of a blog (my first ever!). I will tidy it up into a tutorial maybe, but I believe that understanding is a vital accessory to information, so I might well leave it as is.
David Kent.
.................................................. ..........24 March 2010.............................................. ............
Thank you Andy, that is brilliant. CR now recognises all NRPN and does not care about message order. I was having trouble because the BCF�s chuck out NRPN as:
MSB > LSB > MSB data > LSB data and the desk sends:
LSB > MSB > MSB data > LSB data
CR now records all of the NRPN and when recording is stopped and the data is played back the BCF�s update just fine! No they do not!!! They only update their current preset. Grr!
The BCF can be sent SYSEX preset info. It can be asked to send it back ( you do not have to press EDIT + PRESET> on the BCF if you send the correct SYSEX ). And you can tell it to change to another preset.
Here is the sysex that I have so far:
GO TO PRESET 20 $F0 $rev F1 $recall 20 $end
Translates as: F0 00 20 32 00 14 22 13 F7 (paste this into the SyxEx command window and send it from MidiOx)
So the �22� means go to (load) preset and the �13� (HEX) means 19 (decimal) which is preset 20 in midi-speak. Ugh!

SEND ME BACK PRESET 18 (single preset dump) F0 00 20 32 00 14 40 11 F7
The �40� means �send me the sysex file for� and the �11� means 17 (decimal) which is 18 in midi-speak. This command also means �and do not require local confirmation�

Want more?
For a BCF unit set to ID2
GO TO PRESET 1 unit ID2 F0 00 20 32 01 14 22 00 F7
Obviously the �01� means �this message is for the unit set to ID2�. You will be able to draw your own conclusions about how the rest will pan out. Do not forget that all of the values are Hex.

SEND ME BACK EVERYTHING (id1 DUMP) F0 00 20 32 00 14 40 7E F7
I am interested to know which is the current preset, as I want to return to it when I have finished restoring the data in the BCF temporary buffers. Otherwise I think that the musicians, and especially the drummer, could become confused. I need a message �send me back current preset�. I hope that it exists.
And I would like to script the whole process, as time might be of the essence and errors due to panic are to be avoided.
And I will try to do all of the IP talk over a mains Ethernet link.
Back later. Continue >>> http://www.checkcheckonetwo.com/forum/entry.php?11-Total-Remote-Mixing-(part3))

Total Remote Mixing (part1)

whale-av — Tue, 30 Mar 2010 13:20:00 GMT

To download this blog, with the pictures that are missing, go to
http://www.checkcheckonetwo.com/foru...4&d=1270328744

I am sure there are a number of engineers like myself, with minimal knowledge of Midi, that have already solved all of the numerous problems that present themselves when trying to remote control any digital desk. Still, I could not work it out so I bought a Yamaha 01v96 and a Behringer BCF2000 and a Belkin USB Network Hub so that I might verify any possible outcomes before dying on a live show! Of course you could use a BCR2000 or an M7CL or any other suitable combination.
Thanks to Apple (Macintosh) for driving me to finish my project, after reading their patent application for remote mixing. They really want to own the World! � and my world too!!
My requirements �
Control of the desk from my PC.
Playback of audio from my PC to the desk.
Headphone monitoring on my PC of the desk solo output.
Stereo recording of the desk control room output on my PC.
Musicians direct control their own in ear monitor mixes.
Real linear fader control of the main mix from my PC.
All stable, and as failsafe as possible.
All of the above via one dedicated Ethernet cable.
I started my exploration of Midi before purchasing the mixer. I found that all of the Studio Manager emulators (apart from the PM5) will send system exclusive (sysex) Midi messages when their controls are moved, even when not connected to a mixer. These messages are desk specific, as the first part of the message says which piece of Yamaha equipment it is for. This could be useful if it is necessary to control more than one desk remotely.
.................................................. .................................................. .................................................. ............

YOU DO NOT NEED TO UNDERSTAND THE NEXT PART IN DETAIL, BUT IT WILL EXPLAIN ANY PROBLEMS THAT YOU MIGHT HAVE IF YOU TRY TO USE THE �LEARN� MODE ON THE BCF

Their format is: $F0 $43 $10 $3E $7F $01 $1C $00 $00 $00 $00 val7.13 val $F7
The �val� bits you can investigate, along with some other great leaps of knowledge, by reading (and understanding??) �Behringer�s Secrets�, a document that results from some pioneering work and that can still be found at: http://shoshin.110mb.com/genmce/bcr2000/files/SecretBC.pdf
The $ denotes that what follows is a Hex value. The �val� parts are the variables that change as, for example, a fader is moved. If you look at the sysex messages in MidiOx you will see 14 Hex values. You will not see �val� nor �val7.13�. These two items will appear as $(Hex that changes as you move the control)
�val� is bits 0 to 6, the Most Significant Bits (MSB) of the 14-bit number that represents the control�s position.
�val7.13� is bits 7 to 13, the Least Significant Bits (LSB) of the same number.
The whole message, which is repeatedly sent as a control is moved, reads like this:
$F0 (new sysex message)
$43 (Manufacturer�s ID number - Yamaha)
$10 (device no. and Midi channel (0=1 for midi))
$3E (MODEL ID � Digital Mixer)
$7F (specific Model � apparently the 01v96 should be 0D, but it accepts 7F � ERR????)
$01 $1C $00 $00 (address)
$00 $00 (input ch1 fader)
val7.13 (LSB)
val (MSB)
$F7 (end of message)
Time to set about using this knowledge to set up a BCF2000, and to use the faders to control Studio Manager and the desk. I found that I was only really interested in the faders on the BCF in order to control the faders and the aux sends, and maybe the buttons for On/Off and Solo. Studio Manager was fine for controlling everything else.
I also found later that I was not really going to want the controls on the BCF to continuously respond to incoming Midi. At first this was frustrating, and as I was still tearing out my hair trying to understand NRPN (non-registered parameter numbers) Midi messages, I started to despair. So now I could make the Desk and SM (Studio Manager) respond to my BCF, but the BCF would not follow the other controls as it is set to send Sysex, but cannot recognise those messages.
HOW? Using

Birdie link: http://rapidshare.com/files/115649724/bcfredit_V0.41.zip.html
Like this....
.........
...........................

Into the Tx box I typed (using a spreadsheet and cut and paste is easier) the following for the first four input faders of my new 01v96.
$F0 $43 $10 $3E $7F $01 $1C $00 $00 $00 $00 val7.13 val $F7
$F0 $43 $10 $3E $7F $01 $1C $00 $01 $00 $00 val7.13 val $F7
$F0 $43 $10 $3E $7F $01 $1C $00 $02 $00 $00 val7.13 val $F7
$F0 $43 $10 $3E $7F $01 $1C $00 $03 $00 $00 val7.13 val $F7
Etc.
Note that for channel 11 and 12 it will be:
$F0 $43 $10 $3E $7F $01 $1C $00 $0A $00 $00 val7.13 val $F7
$F0 $43 $10 $3E $7F $01 $1C $00 $0B $00 $00 val7.13 val $F7
You will need to love Hex!
You will note that I decided to send with a resolution of 1023, which I thought would usually be enough. Later I changed the �Abs� to �Abs 14� and typed 16383 into �val2� to use the same 14 bit resolution as SM.
So now I am the proud owner of an 01v96 and I can�t wait to connect it all up. To get where I want to go I need to buy more BCF�s, another Belkin Network Usb Hub (NUH) and another sound card, but for the time being all is well.
.................................................. .................................................. .................................................. ............

BUT THIS BIT YOU WILL NEED!

Thanks to Andy for �Sends on Faders� (SOF) and �Change Recorder� (CR). I am not really using SOF as I have given control of the monitors (in-ear) over to the band. This allows me to do other things during rehearsals. I have incorporated it into my setup however as it is a great piece of software that others will certainly find useful.
Change Recorder is crucial though. I found that the desk would spit out NRPN Midi messages on the Midi Out 5-pin din when it received Sysex messages. These two types of message are interleaved in the Midi message flow. They don�t interfere with each other, as all of the equipment understands the differences, and I have found that useful. Continue >>> http://www.checkcheckonetwo.com/foru...Mixing-(part2))

IEM Interference

Andy — Sat, 27 Mar 2010 08:28:39 GMT

Our monitor guru, Dan, came up with a great way to combat the interference that drummers often get when playing their kit.

Any experienced IEM monitor engineer knows that often you can get RF "hash" from playing the hi-hats on a drum kit. The metal against metal must produce some sort of interference. I've never really studied it, but I've defintely heard it and heard many drummers complain about it.

Well, Dan now does his RF scan (with the new Sennheiser 2000 series IEM) while sitting on the drum kit and playing the hats. That way, if the hats are going to produce some interference, the Sennheiser will reject those interfering frequencies coming from the hats. I think it used to annoy the rest of the crew when they were working, but now that they know why he's "playing" the kit, they're more forgiving! :icon_wink:

That's the theory, anyway, and so far it seems to be very successful!
Great thinking, Dan! :eusa_clap:

Open Mix Tools

Andy — Wed, 23 Dec 2009 19:18:11 GMT

Christian (user: guessi) has just uploaded the second version of OpenMixTools
http://www.trbtr.de/pmw/pmwiki.php/OpenMix/OpenMixTools

This program allows the export and import of XML data to the Yamaha session files. What this means is that data from one type of console can be exported and then imported into another console. For example, you can take the data from a scene in a PM5D and bring that information into an M7CL. The program is still in alpha, but shows great promise. It's at version 0.02a; as of Dec 23rd 2009. Read the instructions carefully.

added: import and export of InputEQ

changed:
channel names can now be longer: 6 chars on LS9, 8 chars on M7CL
if the desk to be exported to has more channels than the source theese will be filled with default values and patched to none (instead of being skipped in 1st version)

Give it a try and post feedback here: http://www.checkcheckonetwo.com/foru...MT-new-version

MIDI Bulk Dumps

Andy — Sat, 28 Nov 2009 16:09:14 GMT

Sounds a bit rude, doesn't it! :eusa_think:

I have tested and verified now that the MIDI bulk dump format for the Yamaha consoles, once converted from 7-bit to 8-bit is in fact the same format the setup files are. This opens up possibilities for sending and receiving large amounts of data without having to save and load files. Not sure of the practical applications just yet, but it's interesting, nonetheless.

The data is formatted as 8 bytes of 7-bit data which needs to be converted to 7 bytes of 8-bit data.

Byte(0) = 7 MSBs of the following 7 bytes, big-endian style. i.e. Bit 6 = MSB for Byte(1), Bit 5 = MSB for Byte(2), etc.

Byte(1)..Byte(7) = Bulk data without the MSB.

Yamaha gives us the conversion formula in the owners manual:
Code:
 
[Recovery from bulk data to actual data]d[0..6]: actual data
b[0..7]: bulk data
 
for(I=0; I<7; I++){b[0] <<= 1;
d[I] = b[I+1]+(0x80 & b[0]);
}
In reality, it's a bit trickier. The console sends out groups of bulk data bytes which need to be strung together to get the final converted set of bytes.

Each group has a header and a footer which need to be stripped off. The format of the header is detailed in the manual, and the footer is the usual F7 that's at the end of all sysex messages.
The number of bytes in each group is a 16-bit integer contained in the header at position 4 and 5. (little-endian)

So in vb.net, it looks like the following code. BulkDataLen is the size of each chunk. BulkData() is the incoming sysex of all the chunks, and RealData() is the converted data.
Code:
BulkPos = 0
RealPos = 0
 
DoDim BulkDataLen As Integer = (Int(BulkData(BulkPos + 4)) << 7) + BulkData(BulkPos + 5)
 
For Ofs As Integer = 12 To BulkDataLen + 5 Step 8For i = 0 To 6BulkData(BulkPos + Ofs) <<= 1
RealData(RealPos + i) = BulkData(BulkPos + Ofs + i + 1) + (BulkData(BulkPos + Ofs) And &H80)
Next
RealPos += 7
Next Ofs
BulkPos += BulkDataLen + 8 ' Skip the next header
Loop Until BulkPos > (BulkData.Count - 8)
Seems to work.
:cheers:

Latest Project

Andy — Tue, 17 Nov 2009 16:46:20 GMT

With the group I'm currently working with, we have a unique problem that I haven't run into before. The cast of 5 players have "alternates" who will replace the main cast members from time to time, from just one player to all players. The combinations and permutations of cast members is a lot.
Some use wedges, some are on IEMs, although they are all currently "on their way" to using IEMS.

So, we had to come up with a way to have everyone's IEM and wedge mixes accomodated, no matter what combination of players are playing. It's extremely tricky, as not only do you need to change the mixes for the person playing, but you also need to change the other players' mixes depending on who they're playing with.

Add to that the need to make sure everyone has their latest settings. If one alternate hasn't played with the group in a month, it doesn't do any good to load the last setup that that player had since all the other players have had changes since then.

A way needed to be devised to pull in JUST the latest information for each player, based on who they are playing with. I needed to write a program that figures out what information to pull from previous setup files, based on what combination of players would be performing.

Turns out it's quite complex. Getting my head around "how it should work" took just as long as writing the program! Turns out you need to identify 2 things for each player: What channels do they "play" and what mixes do they "listen to".

For example, the bass player plays the bass DI & MIC channel and his vocal and the acoustic guitar. The drummer plays all the drum kit mics and the click. The bass player listens to his IEM mixes, and his wedge. (If he's an IEM user, the wedge mix is muted).

So you end up with this matrix of players, channels and mixes. I used a DataGridView to show it, with colour coding based on the player.

Add to that the complexity of 40+ scenes in the show and the fact that players move around on stage, singing into other mics than their own, playing multiple instruments. The "who's channel/who's mix" matrix had to store information for each scene separately as they can change.

So, the program is simple enough to use, but Very complicated to get the right information into it at setup time. Picking the correct "Who's" is quite tricky. Also, setup files have to have all matching scenes to work.

Anyway, it's custom made for our group, and I can't imagine trying to get it to become generic enough to release, let alone support, since the setup is so difficult to get right.

Good news is that it works perfectly if you do get it set up right, and I learned quite a bit more about Yamaha session (scene) files and some additional programming.

Here's a demo of how the program works:
http://checkcheckonetwo.com/files/FlexiCast_Demo.html

(Firefox users: http://checkcheckonetwo.com/files/flexicast.SWF)

IEMs for Wedge Veterans

Andy — Sat, 14 Nov 2009 22:26:30 GMT

Well, it took a bit of work, but we now have all of the "die-hards" who said they would "Never use IEMs" on IEMs now and they are loving it.

Here's what worked in our case:
1. Get the best gear you can afford. We got the new Sennheiser 2000 series IEMs with one of those fancy-shmanzy (directional?) antennas. The band bought UE-11s for each player with custom moulds. They wore the IEMs for a while with their iPods to make sure they fit well and were comfortable.
2. Use a virtual-soundcheck setup to allow time to build "perfect" mixes for each player. Use the virtual soundcheck system to let the player hear their mixes before they play a note. Let the player play and sing along with the Virtual Soundcheck tracks and see how they like their mixes.
The band were "Blown Away" by how amazing their mixes sounded. The extended low end of the UE-11 made it so that even the bass player didn't need an amp or kick from the sidefill. I turned off his amp while he was playing, he never noticed. The drummer doesn't need or want a thumper either.

One player who was particularly hard to convince, after just one show said. "Why the hell didn't I do this years ago?".

The roadblock I think for a lot of players is the 1st time they try IEMs they weren't using quality equipment, proper moulds and their mixes weren't dialed in. If that's what they think IEMs sound like, then of course they're not going to be excited when the idea is brought up with them again. All they remember is how crappy it was the 1st time.

Now to clearing the stage of wedges and all that cabling! :headbang:

MLan

Andy — Sat, 14 Nov 2009 22:22:24 GMT

mLAN - a brilliant concept from Yamaha to put Midi, Audio and control in one firewire cable. Using drivers, you can connect a PC to this mLAN "network" and stream audio, midi and control data. They started this concept in about 2000, to try and alleviate the bottleneck that was happening with the 1984 MIDI spec. MIDI is very slow, limited channels, and needed an update. mLAN looked to be the saviour.

Unfortunately, Yamaha seemed to have botched the initial launch and the drivers, and never really recovered. Originally, the mLAN spec would be licensed to others so all mLAN-enabled products could speak to each other. It never really caught on.

Interestingly, it seems that the biggest problem was the PC hardware. In my own testing of mLAN, I've found that it's VERY particular about the specific 1394 hardware that you are using on the PC. Because of the driver incompatibilities with some hardware, mLAN was labelled unreliable and a failure. Seems to me, all Yamaha would have had to do was to make an "approved" hardware list, and additionally sell "Yamaha" Firewire interfaces that were guaranteed to work.

I have been using mLAN for a while, and it works ABSOLUTELY PERFECTLY if you have the right PC hardware. Believe me, though, it took a VERY long time for me to find the right hardware. Since there was no (up-to-date) approved hardware list, I had to go by trial-and-error until I found something that works. Of course the mLAN installer doesn't have a test to let you know before you finish the install to let you know whether or not the hardware will work, so the install, testing, is quite a process. You can end up wth flakey operation with a lot of hardware, so you just assume the product is flakey. When in fact, you just have incompatible hardware.

mLAN was the only way to record and play back multitrack audio to/from a PC without a soundcard. Very cool. Now new protocols like AVB and Dante allow multi-track via the LAN connection, but for many years, mLAN was the only way.

Quite a shame, really, that they didn't get the hardware side sorted out before the whole mLAN movement got started. Now Yamaha has dropped all support, and still the product works perfectly well.

Virtual Soundcheck

Andy — Sat, 14 Nov 2009 22:16:00 GMT

I am a huge fan of Virtual Soundcheck.

If you have a digital console and are not using this feature, why aren't you?

I've used it countless times to do the following things:

Tweak the sound with and without the band members offering suggestions. You can work on any part of any song, any instrument as long as you want, AS THE BAND PLAYED IT. You can't do it to this level during a soundcheck, as the band really isn't going to play the way they do during the show at soundcheck. And can you get them to keep playing a specific part while you "experiment"? Try that and see how long they wanna do it! Plus, how can they come out and hear what they really sound like? It's a great thing. Tweaking eq's, experimenting with effects, it's simply one of the best ways to improve a band's mix.

Recently, we took a band of seasoned veteran players who swore they would "never go on in-ears" and now have them on ears. And now they'll never go back. Why? Well, like most musicians, they get a chance to try in-ears, and it's done wrong, and then they don't ever want to try it again. With Virtual Soundcheck, we can take their performance, build a mix exactly to their liking, then they can play along with it as long as they need to until they're happy. Get them the right in-ears, take the time to do it right, use Virtual Soundcheck, and it's amazing what can be accomplished.

Build custom "board mixes" for the players. A nice mix for the guitar player with his guitar and vocal out front, another one for the drummer with the drums and bass up loud. They can listen and improve their performance. If the players have their own multi-track software, give them the files and they can listen to whatever they want at whatever mix they want. Figure out why some part "sounds weird" during the show, etc. Fabulous learning tool for them.

Lots of reasons to do it, so get doing it!