At the moment, when connecting a recording computer to the dlive, when using the import channel names, it takes the names from the channels themselves and not from the input.
It makes no sense, when recording tie lines from the stage box, it would make more sense to import the names of the inputs rather than of the channels. because then if a file has splits or is not organized exactly like the input list that feature is useless
It could be that I am misunderstanding your situation and what you are asking for, but I don’t understand why pulling the DAW channel names from the console’s channel names isn’t going to make the most sense in about 98% of the situations.
If you want “clean” direct out sources for your recording, why wouldn’t you be using the “post-preamp direct out” from each channel? This way your naming scheme would be accurate in just about every situation. Pulling the direct outs from the stagebox seems like a weird way of doing it. Plus I’m not even sure what names the system would automatically use because you cannot edit the individual source names as far as I know. Are your DAW channels names something like “Input 1” and “Input 2”?
Let’s consider a real life example… If I have an electric guitar channel, I want that name (ie “Elect Gtr”) to be reflected in the DAW regardless of what physical source input I use. I might need the guitar on stage right one show and stage left the next show (and therefore would likely be using different physical inputs). I certainly don’t want the DAW channel name to change based on what physical input I might use which sounds like what you are doing.
By using direct outs from the channels instead of the individual sources, your input/source routing CAN change and it won’t mess up your DAW channels. The only time it would be a problem is if you have a console channel labeled “Elec Gtr” and you actually have the keyboard as the source. But clearly that is a much larger problem because it would be wrong both the console and the DAW. Both Elect Gtr channels would actually be a keyboard channel.
thanks for the reply, I’ll try to explain myself better.
I am the technical manager and head sound engineer of a venue that has DLIVE DM48 WITH S5000 surface.
at my club we host multiple engineers, bands, technicians and so on.
our recording method is by Tie Lines, routed from the MixRack itself.
by my experience, its the ‘Safest’ way to make sure I have all the inputs on stage routed to the recording (because I record the entire mix rack, so no option of missing an input) also, the routing is simpler for my technicians rather than channel direct out.
now, for our example: lets say I have a guest technician, who’s working today on an existing file from another show that he has done in our venue in the past. lets say in that show channels 11-14 are two keyboards that will not perform today.
so he removes them from his surface, but he doesn’t change the entire naming scheme of his file, he is just working around them.
at the moment, if I’ll import names from the console to the DAW then channels 11-14 will be named after those keyboards that are not in the current show.
or lets say we have 4 vocals, but the guest technician likes to put the splits right next to the channel, (for our example lets say we talk about inputs 20-23),
on the surface channel 20 will be Voc 1 and Channel 21 will be Voc 1 Split, in that case, the names that will be assigned to the DAW will import the Splits names as well.
basically, as I have experienced with the DAW so far, unless the channel naming is exactly as the inputs on the stage box(Mix Rack), importing the channel names will not represent the real inputs that are getting recorded.
I can see how in a situation of a running show/production that has the same tech group and file over and over your suggestion makes sense, but in a venue or festival with multiple file and technicians it just doesn’t
Hope I was clear enough, thank you for your respond
I mean I get the fact that your DAW file might have channels that you don’t want. For example, you are correct that the DAW will have two keyboard tracks/channels that aren’t being used in the show. But those DAW channels also won’t be recording any information on those tracks (because there is no audio present on those channels) and it would be trivial to simply delete those tracks either before you start recording or after the show is finished.
Same thing on the vocal splits. Although the DAW could possibly record data for those tracks (since there is audio being passed on those tracks), it would be trivial to either unarm or delete those tracks before recording the show, or simply delete those tracks after the show (which is the method I would recommend).
But if you run through the procedure of “auto-naming” you DAW tracks before each show, you will be assured that your DAW tracks match up with the console channel names. Sure there may be “extra” tracks that you don’t need, but like you I would rather record too much and then delete what I don’t need after the show than mess with changing things before a show and realized I messed something up and didn’t record what I needed.
The input list of the show, given to me in the bands rider, often don’t correspond to the naming of channels on the Surface.
so the automated naming feature doesn’t really help me if I still need to go through it and change the naming by hand.
in the example I gave, I have the stage inputs connected to the MixRack inputs 1-20
But the channels on the surface are mixed in their position. So if we’ll use my previous example - I do have data coming into inputs 11-14, it’s just not the keyboards that were last time but something else. The sound engineer took new channels on the surface to use on his show and the original keyboard channels are “Skipped”
It’s a safer procedure for me to route the direct inputs from the MixRack rather than the channel direct outs, And anyway the naming in the DAW will not be correct.
If we’ll take Digicos Copy Audio function for example - it will show you on the matrix itself, each input channel name, so an option to pull data of that sort will be very helpful.
Sockets have no individual names and have no fixed relation to the channels.
It is changeable with scenes. So it would not work reliably.
And every channel can support up to 4 inputs at the same time if you are using the input ABCD feature.
If nothing goes wrong, it could be a way to copy the channel names to the DAW and associate them to the sockets. But that requires a 1:1 patch.
This is true! That’s not your fault either. I’m just struggling to understand your work flow and why it “works better”.
The “disconnect” for me is that fact that the engineer has to take the inputs from the stage boxes/mix rack and assign them to the console’s channels being used for the show. Given that this step HAS to occur for audio to pass through the console correctly, why wouldn’t you also take the direct out for the DAW from these channels as well? (There is no need to change the DAW’s I/O routing using this method). In fact, the major advantage to using the Harrison software with the A&H systems is the fact that you can sync the DAW to the console each event which would ensure your track names match up perfectly with the console’s channels.
Can you help explain why taking the direct outs from the individual sockets instead of the console’s channels works better for your workflow?
EDIT - The only possible benefit I can think of with taking the direct outs from the individual sockets vs the console’s channels is with playback/VSC. One could argue that if the sockets ALWAYS had the same source plugged into them that it would make playback/VSC more consistent. However this assumes that the sources are always plugged into the same sockets across every single show/event. I don’t know about you, but it would be impossible for me to be that consistent with where I plug my sources into the Mixrack across every single show/event. Besides, if you have that level of consistency with the sources, it is likely that your channels would be just as consistent.
Even if they weren’t, all you would have to do for playback/VSC is load the correct Showfile that corresponds with the DAW recording and all of your console channels would match the DAW recording tracks. I save a Show file for every event I do and save it with the date as part of the name. I also save my DAW session files with the same date, so it’s easy to match the two files up when I want to playback/VSC something on the console.
In my venue I have the house technician, and the bands sound engineer, usually it is not the same person.
So when they work together, I don’t want the house technician to try and work out exactly what’s happening in the current show file, where did the bands engineer had placed or misplaced his channels. And I don’t want them to waste balance time on it.
So our workflow is to just take the source straight from the mixrack, and have the stage plot to see the channel list that corresponds exactly to the mixrack inputs.
Also, I ask them to assign the entire mixrack to be recorded (all 48 inputs in our case)
So the mixrack is always routed 1-48 to Dante 1-48 and in such case I can know definitely that everything is being recorded and nothing is missed
That makes sense. Thank you for the clarification!
EDIT - I now understand why you made the request, but I am not sure how you expect it to work. You cannot edit/change the individual socket names on the Mixrack or other A&H stage boxes, so I am not sure exactly what you expect the Harrison software to “sync” with. As far as I am aware, the only two places a user can label something (like “Elect Gtr” or “Voc 1 IEM”) on the DLive (and other A&H systems) are the names of the console’s channel and busses.
Therefore even if the Harrison software could sync with the socket names, the socket name could only be the socket number - “1”, “2”, “3”, etc. I doubt that is the end result you are looking for.
Given the fact that the guest engineer is still using your DLive system, I still think using channel direct outs for the DAW is the best solution. The only thing the venue engineer would need to do is make sure they sync the Harrison software with the Dlive system before starting the recording. If there are a certain set of sockets that you always want recorded but would not be part of a guest engineer’s show file (room mics for example), it would be fairly easy to set that up and then glocal recall block that portion of the routing schematic to ensure a guest engineer cannot overwrite that functionality when the load in their show.
EDIT 2 - honestly you probably already have most of these type of scenarios globally blocked from recall anyway. For example, I doubt you have your Dante routing or output buss routing, etc “open” to scene/show file recalls.
I updated post above, but probably after you already looked at it. I’m posting here just to give you a notification that I changed it. Sorry about the confusion!
Regarding the “how it’s going to work part” , well, I’m not a software engineer, but I do know that in Digico in the “copy audio” menu, you can see the assigned channel name next to the physical input (basically in that menu you can see the stage boxes and so on and reroute the signal from there), so I recon there is a way of pulling that data somehow, but I’m really not familiar enough with the Dlives software and its limitations…
You could try using the VSC record send. The technicians just have to select the channels in use on that evening and no other channels should pass through Harrison on paper.
Also why are there channels from the day before? Isn’t there a standard Show, that is recalled every day?
Using tie lines from the sockets is the usual workflow in like 99% the cases I saw in live recording. Nobody wants channel direct outs.
You just don’t understand the situation in the venue, and the reason we work like that.
Your suggestion to work through vsc doesn’t solve the naming problem I have. (Not a big problem, but still)
Regarding the technical possibility of socket names - if Digico is capable of it, I figure the technology exists. Whether it’s technically possible to program is a question for the software engineers, which I’m not part of. So I’ve suggested the feature, from here on it’s out of my hands..