|
Post by klay2000 on May 11, 2021 4:26:44 GMT
Another issue with this is when I start the clock in band helper I need to press the cc message twice to start the clock whereas before clock would start immediately
Clock start message I assign to cc66 on channel 7 in band helpers remote control section. It's not detecting it till my second press.
|
|
|
Post by klay2000 on May 11, 2021 4:52:27 GMT
The reason I asked Nic to help me with blocking duplicate messages was Bcs the lighting controller when it receives the same note on message twice this blacks out the lights (equivalent to a note off message I guess)
It's only the note on messages that need to have the duplicates blocked.
All cc conversion messages I think shouldnt need blocking of duplicates. Maybe that's the issue with band helper clock not starting immediately on a cc command?
|
|
|
Post by klay2000 on May 11, 2021 5:09:22 GMT
You quoted: First, the last line of your script, XX = XX +B explicity blocks every MIDI message received by the script.
So in this stream byter block it doesn't see any midi messages at all except for midi clock which is converting ticks to note on messages for the lighting controller? Bcs midi clock is converted in this script and doesn't pass through it's not going through to my other midi devices which are physically connected to um1 output?
You Quoted: If you want the clocks to go anywhere else, you'd need to route them separately.
So if I connect band helper tempo block directly to the um1 output where my devices are connected the midi clock is successfully received but why does it interrupt the stream byter block that processes and converts ticks into note messages for the lighting controller ?
And to reconfirm... I have the midi clock from BandHelper routed to Midifire only
Thanks
|
|
|
Post by uncledave on May 11, 2021 10:04:47 GMT
Just comment out the "Block" after "Increase tick counter" to let the clocks through. I've tested it both ways, and it works as expected. The double note script is fine.
|
|
|
Post by uncledave on May 11, 2021 10:09:10 GMT
The reason I asked Nic to help me with blocking duplicate messages was Bcs the lighting controller when it receives the same note on message twice this blacks out the lights (equivalent to a note off message I guess) It's only the note on messages that need to have the duplicates blocked. All cc conversion messages I think shouldnt need blocking of duplicates. Maybe that's the issue with band helper clock not starting immediately on a cc command? The duplicate notes script works only on "Note On" messages, MT==90. Everything else, including clocks and CCs, passes through unchanged.
|
|
|
Post by uncledave on May 11, 2021 10:21:20 GMT
Another issue with this is when I start the clock in band helper I need to press the cc message twice to start the clock whereas before clock would start immediately Clock start message I assign to cc66 on channel 7 in band helpers remote control section. It's not detecting it till my second press. I don't have Band Helper, but it sounds like what you're describing is outside of the MIDIFire configuration. Where do you "press the cc message"? How is it connected to Band Helper? The "Band Helper Tempo" block in MIDIFire is just a virtual MIDI output from Band Helper, input to MIDIFire. The MIDIFire script cannot have any effect on it.
|
|
|
Post by uncledave on May 11, 2021 10:32:40 GMT
You quoted: First, the last line of your script, XX = XX +B explicity blocks every MIDI message received by the script. So in this stream byter block it doesn't see any midi messages at all except for midi clock which is converting ticks to note on messages for the lighting controller? Bcs midi clock is converted in this script and doesn't pass through it's not going through to my other midi devices which are physically connected to um1 output? Your StreamByter script sees every MIDI message coming into it, not only the clocks. The XX=XX +B at the end means that none of the incoming messages are passed on. That's why it had to clone the converted CCs, so they would go through. My revised script handles that more gracefully. I have no idea why routing the clocks directly to the output blocks the note messages. If you use the revised script, you don't need that, because the script passes clocks, CCs, and notes; everything you need.
|
|
|
Post by uncledave on May 11, 2021 10:45:01 GMT
Your script has a bunch of CC conversions at the top, which I revised slightly.
Where do those CCs come from? Is it some hardware controller? I see the script has input from UM-1, so I guess you have a controller connected there. Is it the lighting controller?
Where do those CCs go? Right now, they go to your interface, along with the clocks and notes. Are they supposed to go to BandHelper?
Could you describe, or diagram, your entire setup, including all the external gear? And identify what signals (CC, notes, clocks) are meant to come from or go to them?
|
|
|
Post by uncledave on May 11, 2021 14:33:48 GMT
I downloaded this, but it looks like the original scripts, not my new versions. So it probably works the same as before. Maybe you didn't Install Rules? You must always do that for SB to "see" any code changes. I suppose it creates an internal copy, and that's what's saved in the Scene. Edit: Sorry, I was looking at the wrong file. I see you do have the updated scripts.
|
|
|
Post by uncledave on May 11, 2021 14:54:49 GMT
I just tried sending the clock to the MIDIFire virtual output, along with the notes and controls from the VL3 script (clock blocked). Monitoring this in a separate instance of Audiobus shows that both clock and notes are coming through correctly. So I don't know why that doesn't work when sent to your UM-1.
|
|
|
Post by klay2000 on May 12, 2021 9:22:19 GMT
Scene-Main PB DMX 4 Qtr dave2.mfr (4.43 KB) Im using this scene copied and pasted from your message but I deleted the block on the tick counter. I'm still not getting the lighting controller and dittox4 functioning simultaneously the ditto 4 looper receives midi clock but the lighting controller doesn't respond to 1/4 notes my setup is pretty simple. I have a tc helicon voicelive 3 which is connected to the input of the um-one. This is sending cc messages to control band helper selecting songs and starting clock. on the output of the um-one I have 1) obey40 simple lighting controller, 2) Roland Td20x drum module (receiving clock ) 3) dittox4 (receiving clock) 4) other um-one (receiving program messages ) at the moment, with the script I sent gives me midi clock at the ditto 4 but lighting controller not responding at all. the strange thing is I see the note ons going through the event monitor with the clock ticks. im likely missing something simple with the routing. It looks like it should work Bcs the event monitor displays ticks and 1/4 note bylaws in note messages.
|
|
|
Post by klay2000 on May 12, 2021 9:53:39 GMT
I see the note on messages pulsing on the event monitor in midi fire . The output of the event monitor is connected to midi fire. But the lighting controller doesn't respond to what the event monitor implies it should
|
|
|
Post by klay2000 on May 12, 2021 9:58:51 GMT
How does midi fire route the clock to the um-one? I don't have the um-one output on the canvas so I'm confused how messages get there?
I understand the um-one input takes cc messages from an external device. But I'm not sure how midi fire is sending it's data out to the um-one (which is connected to all my devices)
|
|
|
Post by klay2000 on May 12, 2021 10:02:46 GMT
BandHelper is set to send midi clock to midi fire port
But I just closed midi fire and clock still arrives at the dittox4
|
|
|
Post by klay2000 on May 12, 2021 11:08:22 GMT
From the most recent diagram you sent I notice it’s only the note on messages visible in the event monitor. What I see is mainly ticks flying through there with note on messages quickly coming through in between ticks
What should I be seeing in event monitor?
Thanks
|
|