Re: midish as show controller

From: Dale March <dmarch80_at_gmail.com>
Date: Mon Nov 22 2010 - 00:04:55 CET
Alexandre,

Thanks for the hints. These do not help either. The BCF sliders stopped as
expected, but the software sliders in QLC still return to zero as soon as
the midi ctl statements stop.
I have snooped with kmidimon and dont see any extra stuff being sent either
way.
I kind of  suspect the alsa-midi-through port of causing the issue, but I
don't see how else I can attach QLC's midi port.
I will update again after I do some reading on alsa midi and do some more
experimenting.

Dale

On Sun, Nov 21, 2010 at 4:22 AM, Alexandre Ratchov <alex@caoua.org> wrote:

> On Sat, Nov 20, 2010 at 04:03:44PM -0800, Dale March wrote:
> >    Hello,
> >    I am trying to use midish to automate some lights in a show based on
> MTC
> >    of music playing from a hard disk recorder.
> >    I normally use a behringer BCF-2000 control surface to control Q light
> >    Controller (running also on Linux) to manually control the lighting.
> >    For a show we are doing I would like to automate this somewhat.
> >
> >    I am using midish.tar.gz development as recommended on the web site
> >    compiled on Ubuntu 10.01.
> >
> >    If I connect QLC via midi to the BCF directly sliders knobs and
> buttons
> >    work as expected.
> >     If I map them thru midish as below. all values keep trying to return
> to
> >    0.
> >    If I move a slider up, it will make its way back down to 0. I suspect
> that
> >    is because they are being treated as notes and last only one beat with
> the
> >    feed back loop on position causing them to jerk there way down.
>
> hmm... afaik, the bcf-2000 is not sending notes. I suspect there's a
> loop in the midi "circuit". Is the light controller sending feedback
> or acting as a ``midi thru box''?
>
> >    How do I make the controls stick?
> >
> >    dmarch@Aspire1:~/Show$ rmidish
> >    send EOF character (control-D) to quit
> >    [0000:00]> inew qlc {0 0} # the qlc program (dnew 0 "midi thru"  rw is
> in
> >    midishrc)
> >    [0000:00]> onew qlc {0 0}
> >    [0000:00]> inew board {1 0} # the behringer board (dnew 1 "usb-midi"
> rw in
> >    midishrc)
> >    [0000:00]> onew board {1 0}
> >    [0000:00]> fnew filter1
> >    [0000:00]> fmap {any {1 0}} {any {0 0}}
> >    [0000:00]> fmap {any {0 0}} {any {1 0}}
> >    [0000:00]> tnew lights2
> >    [0000:00]>
> >    [0000:00]> r
> >    [0000:00]> 0: sensing enabled
> >    3  31:01   s
> >    [0000:00]> save "lights2"
> >
> >    If you have any recommendations on how I might do this, or software
> that
> >    might be more suitable for this task, I would appreciate any comments.
>
> I would do it almost the same way, but with a single filter rule, ex:
>
>        fnew filter1
>        fmap {any 1} {any 0}
>        tnew lights2
>        r
>
> At this point, any events from the control surface (ie dev 1) get
> their device number changed to 0, ie they are routed to the light
> controller. Resulting events (with dev number 0) are recorded on the
> track. When the track is played back events are sent to their
> respective device, so all events go to the light controller.
>
> Since, no events with device number 1 are recorded, during playback no
> events will be sent to the control surface, so motorized faders won't
> move. If you wan't faders to move, you have to duplicate events:
>
>        fmap {any 1} {any 1}
>
> this is somewhat hackish, sorry there's no ``monitoring'' rules in
> midish yet. I'd avoid this if it's not necessary.
>
> You said, you're using MTC, but with above setup midish will use the
> system clock, which might be out of sync with the recorder. To synch
> midish to the recorder, you have to specify the MTC source device, eg:
>
>        dnew 2 "<recorder midi port>" ro
>        dmtcrx 2
>
> At this stage ``r'' and ``p'' will start waiting for the MTC start
> signal from the recorder, then midish will use the recorder's clock.
>
> Ah, last point, I'd open the light controller in write only mode, to
> avoid recording any events received from it. If for any reason you
> have to keep read-write mode, you can also filter out events from it:
>
>        fmap {any 0} {none}
>
> -- Alexandre
>
Received on Sun, 21 Nov 2010 15:04:55 -0800

This archive was generated by hypermail 2.1.8 : Wed Nov 08 2017 - 16:32:22 CET