[QLab] Qlab -> IAC -> Ableton Live ->midi control surface
zerolmzero
Nevertheless there is a midi related problem that bugs me for a while
now.
Workflow:
Live audio is managed by Ableton live.
We'll focus on volumes to make things less complicated.
Volume is controlled by Qlab (midi messages to IAC to Ableton live).
In addition the volume can also be controlled with an external midi
control surface (BCF2000 or apc 40).
Problem:
If I notice a volume (midi) fade from qlab is to loud it's difficult
to cancel it.
Using the control surface during the fade causes a conflict. The
combined midi messages result in a chopped up volume alternating
between the control surfaces and Qlabs values until the fade finishes.
Not good. I can wait until the fade finishes and pull the volume down.
But further in the cue list another problem arises. The next fade out
is a midi message from x to y where x was the end value of the fade
in. This value was changed manually and a volume jump occurs before
fading out.
SoundmanServer would probably resolve a lot of my problems but it's
not an option. Ableton live seemed like a good option to have some
sort of mixer with effects and eq I could control from Qlab. When my
soundcheck is real tight everything works just fine. But sometimes I
have to rush the soundcheck (also samples and lights in the cue list).
Would really love a better midi routing fixing my problem. I could
also write a pd or max patch to solve my problems but I think enough
stuff is already running on the laptop during the show.
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Sean Dougall
On Mar 12, 2010, at 12:45 PM, zerolmzero wrote:
> Using the control surface during the fade causes a conflict. The
> combined midi messages result in a chopped up volume alternating
> between the control surfaces and Qlabs values until the fade finishes.
This is going to be true any time you have MIDI controllers with the
same cc# coming from two different sources. If there's a way to map a
different MIDI controller (say, modulation) to a separate parameter
that controls the volume at a different point in the signal path (e.g.
a gain plugin in Live), then you could have QLab send cc#7 and the
control surface send cc#1, and the two volumes would get multiplied
together rather than replacing each other. In other words, the control
surface would be available for "trim" style adjustments while QLab did
the bulk of the volume control. Then you could also fade cc#7 out from
wherever you left it, and not have it jump around when the fade starts.
Another option you might consider is doing all the audio playback
within QLab, and using Soundflower (http://cycling74.com/soundflower)
to route QLab's audio into Live, where you could then do the EQing and
stuff. Then you wouldn't have any MIDI routing to worry about, and you
could trim the audio as needed in Live.
HTH,
Sean
zerolmzero
> In other words, the control surface would be available for "trim" style adjustments while QLab did
> the bulk of the volume control. Then you could also fade cc#7 out from
> wherever you left it, and not have it jump around when the fade starts.
Why didn't I think of that. Thanks
> Another option you might consider is doing all the audio playback
> within QLab, and using Soundflower (http://cycling74.com/soundflower)
> to route QLab's audio into Live, where you could then do the EQing and
> stuff. Then you wouldn't have any MIDI routing to worry about, and you
> could trim the audio as needed in Live.
I started implementing the same idea a while ago but I was afraid my
computer wouldn't handle it.
If I understand correctly this wouldn't solve the problem with my live
audio (microphones from the stage). Or is there a way to get those
into Qlab?
*
After trying to get all my levels perfect in Qlab prior to load in &
realizing they just don't always translate from one space to another &
never having enough time to adjust levels no matter how many dinners I
skip, I've gone a different route. External VCAs.
http://www.ashly.com/spec-sheets/vcm88.pdf
http://www.ashly.com/images/product/300dpi/rd8-f.jpg
This has solved my issue & other than cost might be the ticket for you.
Now with the QLab rig in the booth, I can sit at the tech table & ride my
levels during tech. When the show opens, I can sit in a seat with the
remote in my lap & ride the master (which controls all 8 VCAs) in
realtime. All post QLab.
It worked perfectly on our recent gala. A single XLR via a non
transformered patch point & you can go anywhere.
VCM & RC is about $750. I'm in love:)
*
On Fri, March 12, 2010 2:45 pm, zerolmzero wrote:
> Problem:
> If I notice a volume (midi) fade from qlab is to loud it's difficult
> to cancel it.
> Using the control surface during the fade causes a conflict. The
> combined midi messages result in a chopped up volume alternating
> between the control surfaces and Qlabs values until the fade finishes.
> Not good. I can wait until the fade finishes and pull the volume down.
> But further in the cue list another problem arises. The next fade out
> is a midi message from x to y where x was the end value of the fade
> in. This value was changed manually and a volume jump occurs before
> fading out.
*
OUT or available via a single TRS on a console input, you could route your
live MIC thru a VCM88C post console via the insert.
In my case, I'm running the outputs from Qlab straight into a auto
switcher & then those outputs hit the VCM88. Those outputs go to the PM5D.
In a different configuration, I could route the outputs of the console
thru the VCM88 instead.
Monitor levels? sure.
Stereo Mains? sure.
Announce mic? Sure.
Video feed? Sure.
All from a remote box that you can put in your lap.
I've never had external VCA box but it's really changed my game. There is
so much automation you can do before you need to grab some faders.
*
Sean Dougall
Soundflower and your physical audio device(s) -- which you'd have to
do anyway to get this to work -- then you should still have all your
physical inputs in Live alongside your Soundflower inputs.
Soundflower's nice and lightweight, so I wouldn't think performance
would be too much of a concern. You would be limited to 16 channels
output from QLab, though.
Cheers,
Sean
zerolmzero
> I've gone a different route. External VCAs.
I used to tour with an yamaha o1v capable of lots of routings.
But at the moment I'm running a lot of shows so I want to travel
lightweight (carrying desks to tables everyday is heavy). Sometimes
other technicians need to take over some shows so I try to keep
everything as simple as possible.
This is one of the main reasons I'm using Qlab and a soundcard
(firestudio presonus). With the software of the soundcard I can do the
things you proposed, but the software doesn't accept midi and it's
difficult to use with the mouse.
zerolmzero
I'll try this tomorrow
thnx Sean
On Mar 12, 10:55 pm, Sean Dougall <s...@figure53.com> wrote:
> Not directly into QLab, but if you created an aggregate device with
> Soundflower and your physical audio device(s) -- which you'd have to
> do anyway to get this to work -- then you should still have all your
> physical inputs in Live alongside your Soundflower inputs.
Rich Walsh
> But further in the cue list another problem arises. The next fade out
> is a midi message from x to y where x was the end value of the fade
> in. This value was changed manually and a volume jump occurs before
> fading out.
You should be able to fix that by adjusting the Takeover Mode in
Live's MIDI preferences: Live can be set to ignore incoming MIDI data
until it matches the current value.
Rich
luckydave
> Mode in Live's MIDI preferences: Live can be set to ignore
> incoming MIDI data until it matches the current value.
Has anybody ever accomplished this with AppleScript? I'm trying to adjust faders on a MIDI fader board, but I don't want the levels they're adjusting until they reach the current level. I'm thinking of something like an audio gate here. Probably will require a "database" AppleScript in conjunction with a "MIDI interceptor" script. I have ideas, and am not particularly asking anyone to write the code for me, but if anyone already has, or has insights that they think will help, it would be great for me, and for anyone else with similar issues. Of course, once I get this whole thing finished, I'll put it on the Wiki. Likely, it'll be done over the weekend, as I need it in tech tomorrow (in a perfect world), or by Mon at the latest.
TIA
luckydave
Rich Walsh
>> You should be able to fix that by adjusting the Takeover
>> Mode in Live's MIDI preferences: Live can be set to ignore
>> incoming MIDI data until it matches the current value.
>
> Has anybody ever accomplished this with AppleScript? I'm trying to
> adjust faders on a MIDI fader board, but I don't want the levels
> they're adjusting until they reach the current level. I'm thinking
> of something like an audio gate here. Probably will require a
> "database" AppleScript in conjunction with a "MIDI interceptor"
> script. I have ideas, and am not particularly asking anyone to write
> the code for me, but if anyone already has, or has insights that
> they think will help, it would be great for me, and for anyone else
> with similar issues. Of course, once I get this whole thing
> finished, I'll put it on the Wiki. Likely, it'll be done over the
> weekend, as I need it in tech tomorrow (in a perfect world), or by
> Mon at the latest.
I tinkered with this a bit a few weeks ago but abandoned it as the
latency was too high for this kind of thing to actually be useful. I
also wrote a script to send the current levels from QLab to the MIDI
controller, so you can make the faders jump to the right level before
adjusting them.
I don't think AppleScript is the right tool for this job, so I'm not
going to take it any further myself. I have a degree of irrational
resentment towards these scripts actually, as when I was testing them
I managed to drop one of my backup drives onto my laptop and put a
nice big dent in it right next to the trackpad! Anyway, I've attached
the work I've done if it's any use to you... I'm not sure of the
etiquette for sending attachments to this list, so please forgive me
(and let me know) if it irritates you.
Also, Filip Vandueren has put some more efficient code than mine on
the wiki: http://figure53.com/wiki/index.php?title=Script_-_Set_levels_with_MIDIPipe
- bypassing the mapping (which could of course be done in the
controller) and using an equation rather than a lookup table for the
fader curve.
Rich
luckydave
> so I'm not going to take it any further myself.
I complee agreetly. So, I've been taking the long, arduous and learning-curvy road of hopefully learning some barebones Cocoa in the hopes of making a useful app to do this. That post was me hoping someone had beat me to the punch in finding a nice way to do this without me having to accept that challenge right now. Hopefully, I can find my way around the latency and make something happen in the next couple of days.
re: attachments - as long as they're not bigger than a wordy reply, I can't see the bandwidth problem. Of course, always feel free to contact me off-list with them instead. But they do add to the community in a utilitarian sort of way, so it was probably a good choice (he said wordily).
Anyway, I'll let you know what I come up with.
Thanks,