I am using midifire for the dynamic clock module. My setup: Forscore sends control command to the dynamic clock and then i start the clock with FA and send the clock to midi-in of my hardware metronom. In general that works. I am sending the sysex message as shown in the manual's example:
The <ThousandsHundreds> or <TenthsHundredths> when <TensUnits> is between 80 and 99 do not make a difference. They do alter the note but still let midifire misinterpret the sysex message
To me it looks like the sysex command sourounded by the F0....F7 is somehow split into the sysex command for only the <ThousandsHundreds> and than the values of <TensUnits> and <TenthsHundredths> are interpreted as seperate midi messages.
Hi gdohmen , Not certain about sysex, but most MIDI messages use only 7-bit data bytes (max 3F, 127 decimal). That allows the control bytes to be identified by the high bit being set. I think the 2-digit pairs in your message should range from 0..99 decimal, or max 63 hex. You may be mixing hex and decimal. In StreamByter you can use $99 for decimal, but I'm not familiar with your app.
Edit: nic I looked at the MIDIFire manual, and it says "F0 5A 01 25 37 F7 = 125.37 bpm". That implies that the displayed digits are a mixture of decimal and hex, which seems like a technical impossibility, I suspect this should "= 137.55". That would clarify how this is meant to work.
uncledave is on the right track, it is because the tempo set message may not always be a valid MIDI message. I guess when I specified this interface I didn't take that into account, d'oh.
In valid sysex, the first nibble of each (7 bit) data byte should never be 8 or 9, so in theory you cannot set Thousands, Tens or Tenths to 8 or 9 without it being an invalid MIDI message.
Are you sending the sysex message to set the tempo from Forscore to MidiFire via virtual CoreMIDI port or over a hardware/bluetooth connection?
I think it will be possible to write a little StreamByter script to fix this for you, but I'd like to understand the path your tempo sysex messages are taking first, since virtual CoreMIDI quite happily passes 8-bit sysex and MidiFire will also quite happily receive it.
NB, the tempo set message is a mixture of hex and decimal positions, so the manual is correct. The F0 5A and terminating F7 are hex, but the tempo data payload is a sequence of decimal digits. Nothing like a bit of consistency...
Hi Nic, I am not using Bluetooth or other Hardware. I set the tempo from Forscore to MidiFire via virtual CoreMIDI port. i would appreciate som help.
I tried the below and it kind of did the job. Probably can be done much better: # Press 'Install Rules' when done If M0 == F0 If ML == 6 Ass L2 = M2 Ass L3 = M3 Ass L4 = M4 Block Send F0 5A L2 L3 L4 F7 +F End If ML == 4 If M0 >= 80 Ass L2 = M2 Block End End Else If M0 != FA If M0 != FC If M0 != B0 Ass L3 = M0 Ass L4 = M1 Block Send F0 5A L2 L3 L4 F7 +F End End End End
OK, I guess what is happening is that Forscore does not like the bad MIDI message which is fair enough. Maybe we could try something where we change the format of the sysex message you specify in Forscore to something valid and then use StreamByter to convert to the format that Dynamic Clock expects. How about we change the format of the message you put in Forescore to: