|
Post by klay2000 on Apr 27, 2021 17:45:40 GMT
# increase tick counter MAT G0 = G0 + 1 END
Hi. Can someone explain in simple terms what is meant by increase tick counter.
It is used in my midi clock scripts for some reason that I'm not understanding
This is the entire script
# handle ticks IF M0 == F8 # 24 ticks == 1 beat, so determine # bar modulo into variable I0 which # will have a range of 0 to 95 MAT I0 = G0 % 60 # first beat of bar, I0 is 0 IF I0 == 0 # turn light on (note on) SND 9C 14 40 END # second beat of bar, I0 is 24 IF I0 == 18 # turn light on (note on) SND 9C 15 40 END # third beat of bar, I0 is 48 IF I0 == 30 # turn light off (note off) SND 9C 16 40 END # 4th beat of bar, I0 is 72 IF I0 == 48 # turn light off (note off) SND 9C 17 40 END # increase tick counter MAT G0 = G0 + 1 END
# reset tick count on start, continue or stop IF M0 >= FA IF M0 <= FC ASS G0 = 0 END END #
XX = XX +B
|
|
|
Post by uncledave on Apr 27, 2021 21:53:29 GMT
Hi, The script handles every MIDI clock message. The global variable G0 keeps the count of the clock ticks (messages) since start; could be quite a large number. G0=G0+1 is the operation that records the tick. The last part of the script sets the count back to zero on the start, continue, and stop messages.
Do you understand the arithmetic that's going on? As it says, there are 24 ticks (clock messages) per beat, 4 beats in a bar (96 ticks). 60 hex is $96, so I0=G0%60 gives the remainder after dividing by $96, or the position in the current bar. Then it checks when the count hits each of the beats.
G0 is a 16-bit, unsigned integer, maximum value $65535, so it will overflow after about $682 bars. When that happens, it will start again at zero, but the counts will no longer be aligned with the bars.
|
|
|
Post by uncledave on Apr 28, 2021 11:02:11 GMT
I wonder, what is your problem with this? The script looks straightforward, and should do what you already expect. It will only run when receiving MIDI clock, and the SB monitor should show a steady stream of Note On messages, one per beat. So, provided the note and channel numbers are correct, the only problems are likely from the configuration surrounding SB.
How are you running SB? Stand-alone, MIDIFire, Audiobus, AUM, etc.? Could you post a screenshot of the configuration? What is the MIDI clock source? How are the messages reaching your light controller?
Note that G0 is a global variable, shared with other SBs. There would be trouble if another SB modifies G0. If global is not required, I'd switch to a local variable, say J0, for the clock counter.
Also, the comments for beats 3 and 4 say "note off", but all 4 messages are note on. Probably just comment arror.
|
|
|
Post by klay2000 on May 9, 2021 7:40:33 GMT
Hi Uncle Dave
Yes that's right what you mentioned about the note messages being all 'on' messages but the description was wrong as it mentions the notes are off.
I'm using the BandHelper app and its midi clock to feed into midi fire
The problem I'm encountering is that when beat clock is routed to Midifire port from BandHelper the midi clock to 1/4 notes is recognised by the lighting controller. But when midi clock is routed to ''All" ports in BandHelper (I assumed this meant Midifire, um 1 interface and network session) The quarter notes that were processed in Midifire don't make the lighting controller flash to quarter notes
Is there a way I can send the midi fire scene to you so you could possibly work out why?
I'm trying everything I possibly can but it seems that the midi clock gets blocked at my um1 outputs if I route the BandHelper clock just to midi fire. It's like it converts the ticks into note messages on channel 13 but then the ticks are blocked and I can't see midi clock ticks at my other devices.
Thankyou again for helping me
|
|
|
Post by klay2000 on May 9, 2021 7:53:07 GMT
|
|
|
Post by klay2000 on May 9, 2021 7:58:32 GMT
I'm reading your information regarding how the script handles ticks in the global array and slowly I'm getting more of an understanding Thankyou
So Global means it affects every block on the Midifire canvas? I'm guessing so you can create global arrays to affect everything on the canvas and not need to keep repeating the information for each stream byter block?
Much appreciated for your help on this
|
|
|
Post by uncledave on May 9, 2021 9:51:57 GMT
Hi klay2000 , First, the last line of your script, XX = XX +B explicity blocks every MIDI message received by the script. So, MIDI comes into it and only the note messages come out. I assume that's because it's sending to the light controller, which expects only notes. If you want the clocks to go anywhere else, you'd need to route them separately. Second, using G0 for the tick counter means it is visible to any other StreamByter instance running on the device. This can be useful for sharing information. But it means that only one script should be updating G0, or else the count could run too fast, and might even be jerky. I read your description of BandHelper sending clock to all ports. I suspect it would be cleaner to send it just to MIDIFire, and do the routing there. That gives you more control over the situation.
|
|
|
Post by uncledave on May 9, 2021 9:57:51 GMT
I cannot access the link you posted. Maybe you could post a screenshot of the layout? If you use the green Reply button, you can access the full editor. Maybe zip the file and attach it.
|
|
|
Post by uncledave on May 9, 2021 10:31:46 GMT
By the way, the other steps that set G0 to zero should only be in the StreamByter that updates the count. That will ensure that the reset is clean, not glitchy.
|
|
|
Post by klay2000 on May 9, 2021 11:43:14 GMT
This is really great Thankyou. I worked on this the past few hours and did exactly as you advised which is I selected the midi fire port only to receive from band helper.
As an experiment I worked out that when I deleted the block message xx = xx +B I could then see the midi clock at my loop pedal which is great but as you said it affected the script and the quarter notes pulsing at the light controller on channel 13 were no longer pulsing
So now I need to work out how to get clock through using another block? I will give this a try to do it on my own and report back with what I find. Hopefully I can work it out on my own
I pressed the green reply button but can't see where to attach the midi fire files. I will also work that out to avoid the guess work
Thankyou so much . This is a big learning curve for me
|
|
|
Post by klay2000 on May 9, 2021 12:28:10 GMT
For the moment I need to set band helper clock to route to the um1 midi interface Bcs it's the only way I can get midi clock working for a clock track to a drummer and to a loop pedal for recording to the beat.
I haven't worked out how to alternatively route the midi so I can have lights working properly on channel 13 with note messages and also get clock to all my other devices.
The band helper tempo block I connected directly to the output blocks but there are some glitches in the receiving devices. For example the devices seem to receive the tempo double the tempo than what's intended
|
|
|
Post by klay2000 on May 9, 2021 12:37:27 GMT
If I route band helper clock port to um 1 , and um1 is the first input block in midi fire I'm wondering why it doesn't receive clock messages.
Is there a reason for this? Is it Bcs the band helper tempo block is the only way to get clock from um1 to midi fire input?
|
|
|
Post by uncledave on May 9, 2021 13:44:57 GMT
I think you're sending MIDI clock to the UM 1 output. Connecting the UM 1 input to MIDIFire will not see the data going to the output, only mesages from other gear into it. Can't you create a separate route in MIDIFire to connect the BandHelper clock to the UM 1? I've attached a screenshot showing what I mean. I used the MIDIFire virtual ports, but you'd use the actual ports, BandHelper on the left, UM1 and the light controller on the right. Attachments:
|
|
|
Post by klay2000 on May 9, 2021 15:59:18 GMT
When I do this the lights stop responding to midi clock 1/4 notes But I do see midi clock then at my looper
When you say BandHelper block you mean Bh tempo block ?
1) Bh tempo block to stream byter to um -1 (which is connected to lighting controller)
This is one route
2) the same bh tempo block split to a second um-1 output (connected to dittox4) looper
The output of the um-1 is connector to split to 4 devices needing midi clock
Perhaps I missed something?
Thanks
|
|
|
Post by klay2000 on May 9, 2021 16:14:47 GMT
I can send band helper tempo block to the lighting controller through the StreamByter processing to the um-1 and the lighting controller functions as expected (pulses to quarter notes)
I can break this connection and connect band helper tempo block to the um-1 output directly and I get midi clock received correctly at the ditto looper
I just can't have them both working at the same time for some reason . Even when I create 2 paths split at the BandHelper block
|
|