|
|
Post by panmanphil on Jul 14, 2015 3:29:51 GMT
I am hoping I am doing something obviously wrong, simply correct. I am doing something that seems quite similar to the example done for converting program change messages to chords online and on youtube. For the record Tom W. is somebody I work with too.
The setup is:
scarlett focusrite --> MidiBridge input (stream byter and program change are enabled here)
MidiBridge output --> Loopy HD
MidiBridge output -> Midivisiion
the stream byter is configured on the Midibridge input. For reasons I don't understand if I put on the MidiBridge output, nothing happens, nor can I do the manual program change plugin from there.
what I want to happen is one one program change comes in, that one and 2 others program change messages go out. These will trigger multiple bindings in loopy. Like mute all, select track 3, set record time to 8 bars, that sort of thing.
my script looks like
c1 01 = c1 01 (with or without +C, no difference)
c1 01 = c4 05
c1 01 - c4 01
and so on. What I get out in midivision is just the last one, and the first if I add +C to it.
what am I missing?
Thanks
|
|
nic
Soapbox Supremo 
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 14, 2015 9:50:52 GMT
Hi panmanphil, Try this: C1 01 = C4 05 +C
C1 01 = C4 01 +CWhat this will do is clone the original program change event (MIDI channel 2, Program Change 001 - counting from 0) to Channel 5 program change 005 and 001. It will leave the original event unaltered so you will get 3 events coming out in total. Your original rules would rewrite C1 01 to C4 05 (rule 2) and that would be all since rule 1 does nothing and rule 3 won't match since you rewrote the event in rule 2. In terms of routing, you probably just need two routes. Suggest the following (assuming you want to monitor with MidiVision): Scarlett -> MidiVision Scarlett -> Loopy HD Remember the MidiBridge Input (on left) and output (on right) are *not* connected internally. You can place these rules on the Scarlett input (on left) or the the Loopy destination (on right). Hope that explains things a bit. Get back to me if you need more help. Regards, Nic. |
|
|
|
Post by panmanphil on Jul 15, 2015 10:54:43 GMT
Yeah that worked, thanks. What I learned from this is that the +C clones the input, not the resulting output. Obvious (now) from the docs.
Is there any benefit or disadvantage to routing the scarlett input to midibridge output (right side) and then the midibridge input (left side) to loopy and midivision, the missing internal connection you mention? I hadn't shown that, but was doing that too. It seemed a way to group common messages that may always be transformed, in this case to send the same thing to midivision and loopy but perhaps some unaltered messages to another app.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 15, 2015 11:54:36 GMT
Hi panmanphil, I think what you are saying is that your routings are: Scarlett -> MidiBridge (single green line) MidiBridge -> Loopy + MidiVision + MidiBridge (green line that forks 3 ways) What that means is that the MidiBridge output is a copy of the Scarlett events which 3rd party apps can access by configuring them to 'listen to' MidiBridge Conversely, whatever gets sent to MidiBridge by another app will be echoed to Loopy, MidiVision and any app listening to MidiBridge. Unless something is sending to the MidiBridge virtual port nothing should happen with this, so I suspect that 3 way route is not actually being used in your setup. My personal 'simple' method of configuring things (adjusted to your case) is: 1. Scarlett -> MidiBridge (put filtering on the MidiBridge output port on right) - no other routes - 2. Configure 3rd party apps to receive input from either MidiBridge for filtered events or Scarlett for unfiltered events I recommend this approach as many apps' own virtual input is broken, and although you are not currently using any of those 'broken' apps, you may choose to do so in the future and you'll avoid some pain. Regards, Nic. |
|
