MIDI file, channel selection

[Martin .]

Hi,

is there a way to select the MIDI channel for output of a MIDI file?

searching the list archives I found this post from 2010 where it's said that it might be included in a future release:
https://groups.google.com/forum/#!topic/qlab/d_o3LW32VcU

(last two posts)

If it's not already implemented it would sure be useful.

cheers,

Martin

[micpool]

I didn't understand this thread in 2010 and I don't understand it now.

Surely if you have a midi file whether it is type 0 or type 1 all events are channelised in the file. A midi file can have events on any of the 16 channels included in it

If you have a midi file with note ons or cc's or whatever set to ch1 and you want them to work on ch4 then don't you have to remap them? 

Are you suggesting MIDI File Patches in settings  have a remap matrix on an edit patch button similar to device routing in edit patch in audio? Or do you want remapping on a tab in every MIDI file cue?

Mic

[mick...@gmail.com]

It was the first thing I looked for in a demo of v3 but I did find a workaround in v2 2010.

Id done various designs within Daws using external software outside the daw for processing and

had built up a bunch of midifiles of actions and multiple cc changes that I could use again and again.

All Daws have the option of chanelising midi so I made my files using midichannel1 knowing I could

always route that to whatever channel i needed.   

Back then I had a job that needed live cue'd processing on different bits of audio at the same time - I

thought great Cue my midi files and i can speed them up and down to time in qlab on site and save me making audio

bounces etc etc.  Without Midi chanelising ie a send to all/1/2/3/4/5 option it wasnt going to work.  I didnt fancy

recreating all my templates 16 times to cover all channels

I did set about building a little maxmsp chanelliser and then found the little app midipipe which gave me

my work around using multiple IAC buses

Qlab to send Midi file to Channel 5.......

Qlab file setting sned to IAC bus 5 

MidiPipe receiving IAC bus 5 and turning it into IAC bus 17 midi channel 5

Software receiving IAC bus 17 with all the independently discrete channels

You need up to 17 IAC buses for 16 separate channels in software 

- other midi devices seen can be treated the same

So Martin dont know if this might be of help to you its limited to the number of midi devices qlab will see at once 

I did also have some issues with midi files made in different ways and qlab seeing extra bars of nothing as well

as timing anomaly's which i never really got to the bottom of.  A 4 bar midi file of a click made in Logic/protools and reaper

would all have slightly different bad timing in Qlab playback.  Ive just avoided midi looping in qlab ever since 

mick

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[micpool]

I couldn't quite follow the details of what you are doing, but for anyone who wants to reroute   all 16 channels of MIDI in a midi file at once you can do this using an IAC bus in and an IAC bus out in MIDIPIPE. See attached screenshot.

[micpool]

On Monday, August 11, 2014 1:20:15 PM UTC+1, mickblah wrote:

 A 4 bar midi file of a click made in Logic/protools and reaper

would all have slightly different bad timing in Qlab playback.  Ive just avoided midi looping in qlab ever since 

How did you do MIDI looping in Qlab in the first place. The MIDI file playback is rudimentary and as far as I can see there is no way of setting the start end or loops of a midi file in v2 or v3.

There are timing anomalies though. The first events are always late in relation to the rest of the sequence. It's certainly not the best implemented cue type in Qlab.

Mic

[mick...@gmail.com]

My short midi files are single channel sets of cc data for particular processes and effects.  My multiple IAC/midipipe

workaround is a way of choosing in qlab which midi channel my qlab cue goes to as qlab doesnt have the

channelising option  and it is essential for them to be discrete.

I did tests with midi looping with autofollow start cues and repeats before discovering the timing issues and

ended up creating longer than needed audio click tracks less flexible but reliable.

mick

<MidiPipe.jpg>

[Chris Ashworth]

For what it’s worth we’ve discovered that the timing errors in MIDI file playback are coming from Apple’s MIDI file playback module.  As such, to fix them we’ll have to rip out Apple’s code and write one from scratch.  Not a quick fix, but at least it is on our radar now.

Best,

Chris

[Matt Parker]

I just ran a Narrated Ballet on Qlab 2 generating MIDI timecode to trigger the Ligthboard, and midi fade cues in Qlab.  I had issues almost every show, seeing this post I wondering if it was an Apple issue or if I was over taxing Qlab.

The system is a Mac pro 10.6.8, with M-audio Lightbridge (they are awful with driver support but the only thing with multiple ADAT outs at that time), and MOTU MIDI micro express.  I was sending the MTC to the Lightboard, SM display, and Qlab.  The MTC cue was patched to "all cables" on the MIDI micro express with the physical outputs patched like this:

MIDI out 1 >back in to MIDI 1 in -for Qlab to chase

MIDI out 2 to ligthboard

MIDI out 3 >back in to MIDI 3 Then routed with Apple network MIDI to a laptop by the SM ( had tried using ipmidi didn't seem to carry MTC) 

Lightbridge MIDI out to Mixer

There were 2 group cues 1 for each act, 41 min and 54 min in length.  Each contained a wave file that ran the length of the act, MTC start cue,  about 20 fade cues with pre wait times from the start, 20 to 30 MIDI controller fade cues triggered from MTC, and stop MTC triggered by MTC(later changed to a prewait).

• The Opening performance none of the fade cues triggered off of time code, it worked during sound check but not in the run of the show, It had worked flawlessly all week in tech.  what had changed from tech to performance was only sending MTC to one laptop instead of 2 (LD, and SM), and adding many more fade cues (composer was handing me new wave mixes every rehearsal just before starting, have since incorporated those dynamics into the Wave so I can delete the fade for future performances).

As a result of that I added the 2nd physical loop back, I had been using just a loop back in 1 for network MIDI and qlab.

• 2nd show a MIDI mic cue fired early and the time code stopped 2 to 3 minutes from the end of the show.  My guess is qlab fired off all the remaining MTC events in it had on deck. 

 I changed the MTC stop from a MTC trigger to a prewait, to prevent this.

• The following shows I had 1 or 2 random mics not trigger.

I know I'm not going to see this in QLab 2 but, I would love to have the ability to route MTC to multiple MIDI outputs.  Then I could send one output to the MOTU for Lights and one to the IAC to loop back to qlab and network MIDI, which would reduce the overhead from blasting it out all 6 outputs.

Also a "self" option for timecode source would be great to save all the funky routing.

--

Matthew Parker       mailto:Matt_...@Asolo.org

Sound Designer

Asolo Repertory Theatre        http://www.asolo.org/

[Sam Kusnetz]

Hello Matt

Sam here, of Figure 53. There are a number of thoughts I have about your
setup.

1. I quite agree that M-Audio drivers are sketchy, and I would add that
build quality is often rather sketchy too. Another option is the
Focusrite RedNet 3, which can output 32 channels of ADAT lightpipe at
96kHz, and connects to your computer via ethernet using Dante's Virtual
Soundcard. It is considerably more expensive, but generally regarded as
top quality so it's something you may wish to consider in the future.

2. If I understand correctly, you're using QLab to generate the MTC, and
it's listening to itself and triggering cues based on that MTC. Is that
right? If there a particular reason you're doing that, rather than using
some combination of Group cues, pre-waits, post-waits, auto-follows, and
auto-continues? I definitely recommend the latter method, as it is
dramatically simpler and more reliable, as you have discovered.

3. While QLab 2 is still supported by us, and will continue to be for
quite some time, we are no longer actively developing it. All our QLab
development energy is going into QLab 3. If you were able to use QLab 3
for this project, I would recommend using LTC which is a much more
robust signal with higher precision, and which is simply audio so it can
easily be routed to any number of places.

As a side note, my personal opinion (and definitely NOT the opinion of
Figure 53) is that MTC is a generally horrible protocol, and nearly any
effort to avoid it will turn out to be worthwhile. If I were programming
a system like yours, I would try to see if it could be done with
individual MIDI cues firing off towards the light board and the SM
display, and use pre-waits to time the messages. Again, this is personal
preference and experience, and not any kind of policy.

Please don't hesitate to contact us again if you have any other
questions, or if there's anything else we can do for you.

Cheerio,
Sam
--
Sam Kusnetz
QLab Field Operative
s...@figure53.com

[Matt Parker]

HI Sam

Thanks for the reply.

On Aug 21, 2014, at 2:08 PM, Sam Kusnetz <s...@figure53.com> wrote:

> Hello Matt
>
> Sam here, of Figure 53. There are a number of thoughts I have about your setup.
>
> 1. I quite agree that M-Audio drivers are sketchy, and I would add that build quality is often rather sketchy too. Another option is the Focusrite RedNet 3, which can output 32 channels of ADAT lightpipe at 96kHz, and connects to your computer via ethernet using Dante's Virtual Soundcard. It is considerably more expensive, but generally regarded as top quality so it's something you may wish to consider in the future.
>

Actually I have a Yamaha CL 5 Mixer and I going to experiment with the Dante Virtual Soundcard this next week, the 48k output with Dante has held me back from using it. I have a 44.1k workflow and have had headaches when I have experimented with switching to 48k

> 2. If I understand correctly, you're using QLab to generate the MTC, and it's listening to itself and triggering cues based on that MTC. Is that right? If there a particular reason you're doing that, rather than using some combination of Group cues, pre-waits, post-waits, auto-follows, and auto-continues? I definitely recommend the latter method, as it is dramatically simpler and more reliable, as you have discovered.

Thought it would be cleaner triggering them with MTC, I figured I would end up with the fades triggered by pre-waits ( auto-follows would have been a mess, delete or insert one part everything that follow has to be adjusted and checked for tracking errors) , and didn't know how taxing 80 plus cues with pre-waits, on top of generating MTC would be. The composer was working on it till the last minute, so I didn't get a chance to optimize audio for programing, i.e. cutting it up into tracks. Also, it was the first time I had gotten MTC working in Qlab and did know it was as troublesome as it ended up being.

>
> 3. While QLab 2 is still supported by us, and will continue to be for quite some time, we are no longer actively developing it. All our QLab development energy is going into QLab 3. If you were able to use QLab 3 for this project, I would recommend using LTC which is a much more robust signal with higher precision, and which is simply audio so it can easily be routed to any number of places.

Yesterday I made LTC audio files to experiment with for next month when it plays again.

>
> As a side note, my personal opinion (and definitely NOT the opinion of Figure 53) is that MTC is a generally horrible protocol, and nearly any effort to avoid it will turn out to be worthwhile. If I were programming a system like yours, I would try to see if it could be done with individual MIDI cues firing off towards the light board and the SM display, and use pre-waits to time the messages. Again, this is personal preference and experience, and not any kind of policy.

I generally agree more because of the lack of resolution, it's fine for Film/video which it was designed for. However, it's what we've got. I have an install I built in SFX5.6 that's been running solid (aside from Telnet issues) and evolving for 6 years that has 600 plus self triggered timecode events (build 25 was for me because I had hit the limit of timecode events the build 24 would trigger), hence my request for Qlab to internally chase it's own clock (removing MIDI transmission issues and hopefully a more accurate clock) . Qlab definitely has better time accurate functions than MTC, but in some applications it's the most productive programing path.

All the light cues were triggered off of timecode it was more efficient to program this way in the time we had, than for the LD to build his cues and relay the cues and times (converting frames to fraction of seconds) to me to build the MSC cues. After the timecode stopped in the one show, the following performance the light board-op turned on the intenal timecode in the light board but didn't turn it off end the end of the act 2. During the curtain call it's clock wrapped around from 2h51m to 1hour which was the top of the show ( and dark) because it didn't have any more events past that time, and the mouse on the Ion was unresponsive till I resumed sending timecode.

While all in all not a complicated show, it's a poster child for not over automating a show. I have never been burned by how automation was implemented or performed like i was with this show.

>
> Please don't hesitate to contact us again if you have any other questions, or if there's anything else we can do for you.
>
> Cheerio,
> Sam
> --
> Sam Kusnetz
> QLab Field Operative
> s...@figure53.com
>