|
|
Post by uncledave on Jan 18, 2022 13:37:33 GMT
I've fixed it. Turns out nic was right. But please tell me the correct numbering for the filters. I'm not going to fire up my computer just to find out. Just log what you need for the three bytes: mixer, filter#, filter type. I'll be out for a while, and I'll post the update when I return. |
|
|
|
Post by mo13 on Jan 18, 2022 13:59:04 GMT
Input 1 -
LPF - 00 00 01
HPF - 00 01 03 (although I thought it would be 02 on the third byte, turns out if I check the box Enable filter then it's 03, otherwise it's 02)
Input 2 -
LPF - 01 00 01
HPF - 01 01 03
Input 3 -
LPF - 02 00 01
HPF - 02 01 03
|
|
|
|
Post by uncledave on Jan 18, 2022 15:30:40 GMT
Input 1 - LPF - 00 00 01 HPF - 00 01 03 (although I thought it would be 02 on the third byte, turns out if I check the box Enable filter then it's 03, otherwise it's 02) Input 2 - LPF - 01 00 01 HPF - 01 01 03 Input 3 - LPF - 02 00 01 HPF - 02 01 03 That looks good. I suspect position 1 in the filter type is used for the enable flag. Then the remaining bits select the type. |
|
|
|
Post by uncledave on Jan 18, 2022 15:50:34 GMT
So, here's the working script. It runs in MidiFire and sends complete SysEx messages, as shown by the monitor in the screenshot. My test driver just sends the CCs to the MidiFire virtual port; you'll replace that with your contoller. It turns out that nic was right. He suggested sending the SysEx fragments internally to SB (+I flag on each Send). It seems that the message added to the SB input queue collects the fragments into one valid message. We don't actually process this message, it just flows through SB, same as all unprocessed messages. I've updated the script for the new filter type selections. And it now checks for and only processes CC# 0-5. This avoids craziness in case any other CCs reach here. It blocks all messages except the SysEx, so it doesn't matter what you feed it, it will only do this one thing.
#SetFilterFreq
# adjusts filter cutoff frequencies in an ES-9
# CCs 0-5 on MIDI channel $14 control cutoff for inputs 0-2,
# filters 0 and 1, configured as LPF and HPF.
# The SysEx message is longer than 16 bytes, and is sent in 3
# chunks. It is routed internally (+I) back to SB, which then relays
# it as a single message.
If load
# transmits a 16-bit value in 3 bytes coded in 2:7:7 bits.
Sub SendWord theWord
Mat I10 = theWord / 4000 # 2 high bits
Mat I11 = theWord & 3FFF
Mat I11 = I11 / 80 # middle 7 bits
Mat I12 = theWord & 7F # low 7 bits
Send I10 I11 I12 +F +I
End
End # Initialization ———————————————————————————
If M0 == BD # CC on MIDI channel $14
If M1 < 6 # ignore any unexpected CC#
Mat I00 = M1 / 2 # mixer number
Mat I01 = M1 % 2 # filter number
Ass I02 = 1 # filter type and enable
If I01 == 1
Ass I02 = 3
End
Send F0 00 21 27 19 39 I00 I01 I02 +F +I
Mat I02 = 100 * M2 # shift CC value up in 16-bit word
SendWord I02
# sending 0 for filter Q and gain, not used here
Send 00 00 00 00 00 00 F7 +F +I
End
End
If M0 != F0 # block everything except the SysEx message
Block
End
Edit: I tried this in AUM and it does not work at all with the block everything at the end. If I comment that out, it works, but only sends the fragments. However, routing the AUM output to the MidiFire port produces complete messages on the MF monitor. So the buffer assembly may be occurring at the input to MidiFire. YMMV, as they say. Attachments:
|
|
|
|
Post by mo13 on Jan 18, 2022 19:50:33 GMT
still testing things, in Aum it's working straight - EC4- SB- ES9, in MF only 9 bytes go out either through AUM or directly :   it's not behaving well with F8R faderbank, I tried hooking it up directly as in - without the midi breakout inbetween to EC4 but the filters become unresponsive to the point that I have to restart ES-9, so that'can't be all too good. I wouldn't know what that could be at this point, maybe it's not liking the Thru somehow, but that's something for me to figure out. Still troubleshooting all but curious why we have different byte outcomes in MF? |
|
|
|
Post by uncledave on Jan 19, 2022 0:17:24 GMT
Assuming you are using the new script (the +I on the Sends is the key), the only diff between your tests and mine is that I routed to output to a port. MF may treat that differently. We're up against fundamental idiosyncracies in the software we're using, MF, SB in MF, and SB AUv3, stuff over which we have no control. So it's just a matter of finding a pattern that works and using it.
|
|
|
|
Post by uncledave on Jan 19, 2022 16:36:27 GMT
Here's another thing I've noticed. Some controllers read their pots with a much higher resolution than 7 bits. They may send a CC every time the internal value changes, even though the 7-bit CC value may be the same. This produces a large stream of messges, which our script needs to process. This noisy traffic may cause glitches. I'll add change detection to the script, so it only reacts to a new CC value. This may help the SysEx messages to get through correctly.
|
|
|
|
Post by uncledave on Jan 19, 2022 17:23:16 GMT
Here's the updated version. It ignores a CC message with the same value as before. The first 6 positions in the L array are used to record the last value of each CC. LM1 is the prior value of the CC# in the current message.
I removed the block all because it upsets running SB in AUM. This script works for me in MidiFire, or in AUM, routed to MidiFire. The MF monitor always shows a 19-byte SysEx message.
Just incidentally, I noticed that the MF monitor does not always show messages in correct time order. Watch the timestamps.
#init_preset
#SetFilterFreq
# adjusts filter cutoff frequencies in an ES-9
# CCs 0-5 on MIDI channel $14 control cutoff for inputs 0-2,
# filters 0 and 1, configured as LPF and HPF.
# The SysEx message is longer than 16 bytes, and is sent in 3
# chunks. It is routed internally (+I) back to SB, which then relays
# it as a single message.
If load
Ass L0 = 0 0 0 0 0 0 0 0
# transmits a 16-bit value in 3 bytes coded in 2:7:7 bits.
Sub SendWord theWord
Mat I10 = theWord / 4000 # 2 high bits
Mat I11 = theWord & 3FFF
Mat I11 = I11 / 80 # middle 7 bits
Mat I12 = theWord & 7F # low 7 bits
Send I10 I11 I12 +F +I
End
Set name SetFlt
End # Initialization ———————————————————————————
If M0 == BD # CC on MIDI channel $14
If M1 < 6 # ignore any unexpected CC#
If LM1 != M2 # check for new CC value
Ass LM1 = M2 # save new value
Mat I00 = M1 / 2 # mixer number
Mat I01 = M1 % 2 # filter number
Ass I02 = 1 # filter type and enable
If I01 == 1
Ass I02 = 3
End
Send F0 00 21 27 19 39 I00 I01 I02 +F +I
Mat I02 = 100 * M2 # shift CC value up in 16-bit word
SendWord I02
# sending 0 for filter Q and gain, not used here
Send 00 00 00 00 00 00 F7 +F +I
End
Block
End
End
|
|
|
|
Post by mo13 on Jan 19, 2022 17:50:24 GMT
sounds good, thanks for the updates, just taking care of few things here and will report back within a day or two.
|
|
|
|
Post by mo13 on Jan 23, 2022 9:08:17 GMT
EC4 encoders work as expected now out of AUM, F8R faders are another story which I'll leave it that at now, connection directly from MF is still unresponsive but that's also not the end of the world, I'll investigate some more meanwhile, thanks uncledave ! |
|
|
|
Post by uncledave on Jan 23, 2022 11:42:12 GMT
Hi mo13 , If you're interested, I've implemented the same functionality in Mozaic. Mozaic sends the whole SysEx message in one, so eliminates the problem of SB sending the message in pieces. Mozaic is an AU MIDI effect, so you can load it as a module in MidiFire (or AUM). Mozaic may be a better long-term solution for longer SysEx. I've attached the script below. Detailed instructions are included at the end. Cheers, Dave Attachments:SetFilterMoz.txt (3.86 KB)
|
|
|
|
Post by mo13 on Jan 24, 2022 9:56:32 GMT
nice, is it generally a good idea to load it in MF with having busy scenes that are constantly switching ? as only have been using SB in there as modules so far.
|
|
|
|
Post by uncledave on Jan 24, 2022 11:14:18 GMT
nice, is it generally a good idea to load it in MF with having busy scenes that are constantly switching ? as only have been using SB in there as modules so far. That's hard for me to say. If you're happy with the SB implementation, you might as well stick with it. If you need Mozaic, then you'd have to test it in your environment. At least we can use Mozaic in future if necessary. |
|
|
|
Post by mo13 on Feb 11, 2022 13:54:33 GMT
OK, here we go. First, I have the Disting manual for firmware 1.11. The way I read the description of SD 6 Triggers is that you can select one folder with param 7, then 6 files with params 8-13. Anyway, the script is configured to use 6 CCs from 7-12, as you described. You can change it however you like by adjusting the few parameters at the top. The attached file is a zipped copy of a file saved by stand-alone StreamByter. You will need it to access the file. It's a free app. Download the file, unzip it, tap and it should open in StreamByter. To use it in StreamByter AUv3, you would need to save it to iCloud. To use it in MidiFire, select all the text and copy it to a StreamByter block in MidiFire. Hook it up to the EC4, put the MidiFire monitor on the output, and open its large view to see the SysEx messages being sent. I assume the messages always come in pairs, with nothing else in between. You should probably avoid turning two knobs at once, just in case that pairing is disrupted. I've tested this using another script that converts my incremental encoders into 14-bit CCs, like what EC4 should be sending, and it generates the correct SysEx stream as I read the manual. hey Dave, this has been running steady the whole time! Though now I’m having a new fader module arriving soon that allows to send out pitch bend from the faders as well, from the description : The Midi CC number and channels can be different for the TRS jack and the USB port. The firmware has been tweaked to allow also Pitch Bend, which is pretty handy because you can get much better resolution through Midi (from min to max values Midi CCs have 128 steps and Pitch Bend has a resolution of 16.384 steps).since you didn’t mention the 14bit Pitch Bend when working out the EC4 script, I’m curious if you think this could be set up and work as accurately as you achieved with MSB/LSB to SysEx or does Pitch Bend bring along it’s own increment problems ? |
|
|
|
Post by uncledave on Feb 11, 2022 15:35:57 GMT
You could use Pitch Bend. There are some limitations. Only one Pitch Bend per MIDI channel, so not quite as simple as CC# to manage. Pitch Bend normally defaults to the middle value (8192, hex 2000), indicating 0 pitch change, with zero meaning max negative, and 16381 (3FFF) meaning max positive. If the controller just converts knob rotation into Pitch Bend, that should be fine. The resolution won't be any better than MSB/LSB, just a different way of transmitting it. Also, of course, many apps and hardware respond to Pitch Bend, so you'd need to make sure they don't see these messages.
|
|
