|
|
Post by mo13 on Jan 16, 2022 22:38:22 GMT
uncledave , somewhat a follow up on this, could I use a similar script for another SysEx accepting device (ES-9) from same fabricate as Disting for this purpose : from the manual39H – Set Filter F0 00 21 27 19 39 <mixer> <filter> <type> <3 bytes of frequency> <3 bytes of Q> <3 bytes of gain> F7 Sets the parameters of a mixer filter. with there being 3 sets of 3 bites, is that another thing to do through MSB and LSB or is it also doable with 7 bits CC? as that would be enough for me increment wise.
|
|
|
|
Post by uncledave on Jan 16, 2022 23:58:29 GMT
Yeah. They use 3 bytes to transfer a 16-bit value, 2 bits in the first byte, 7 in the second, and 7 in the third. MIDI can only send 7 data bits in a byte, since the high bit is reserved for the commands. For what we did before we only needed values up to 999 (I think), so we only needed the two 7-bit bytes. You might need the high two bits for frequency, if it's above 16383. And I don't know what values they expect for gain and Q. You could use a regular 7-bit CC for input, but you might need to shift it around to make it work. What are the ranges of those parameters?
Edit: I should mention that a single Send can only include 16 bytes, and this SysEx message is 19 bytes long. You'd need to split it into two Sends, and use the "+F" flag on each. +F disables validity checking, which will fail on message fragments, as described in the SB manual. This is not a problem, just a little gotcha to look out for.
|
|
|
|
Post by mo13 on Jan 17, 2022 14:11:47 GMT
okay if you say it's safe, but good to know anyway, here are the frequencies and I opened a window where the order of the filters is seen, I'm only using the first 2, and 3 of the input channels. I'm not sure how this would look written out in SySex but here are the decimals : <mixer> 00 <filter #> 01, 02, 05, 06, 09, 10 <type> 01, 02 <3 bytes of frequency> - if possible controlled from CC increment <3 bytes of Q> OFF <3 bytes of gain> OFF frequency control by : Input 1 - LPF - BD 00 _ HPF BD 01
Input 2 - LPF - BD 02 _ HPF BD 03
Input 3 - LPF - B2 04 _ HPF BD 05in case the above is only possible by MSB/LSB then it's fine to leave it at this, as I would like to use a faderbank for these which only does CC's.  |
|
|
|
Post by uncledave on Jan 17, 2022 15:27:38 GMT
The screenshot doesn't help much, since it interprets the data for easy reading. For example, it shows the gain as 0 dB in the middle of the slider. So what is the 16-bit value for 0 dB gain? Is it 8000 (half-scale), 0 (if value is signed), etc. Does the frequency go from 10 to 22000 Hz as the 16-bit value goes from 0 to max, or does it contain the frequency value exactly? We need to know what the hardware expects.
When you say "controlled from CC increment", do you really mean using an encoder in incremental mode, or do you just mean the ordinary CC value?
Could you clarify the frequency control by items? Does that mean that the frequency for input 1 LPF is controlled by the 3 bytes BD 00 xx? Or do you mean that's the CC input from the controller? If it's the controller, how do those map into the message bytes, filter # and type?
Inherently, the message contains 16-bit values, encoded as 2 bits and 2 7-bit values. But we don't have to use a 14-bit encoder to enter those values. We could use a 7-bit CC value multiplied by a scale factor. We could scale it logarithmically (better for frequency, think octaves), or look it up in a table. If the input is actually incremental, we can add up the increments (integrate) to get any 16-bit value with really high resolution.
I have tested sending a SysEx message in pieces, using +F, and it seems to work fine, so it will be easy to build a message step-by-step.
Edit: I have the ES-9 manual and it's not very informative. Could you put a MIDI monitor on the config app and see what it sends for certain values? Especially the frequency, low, high, and somewhere in the middle. Also, what is the data value for 0 dB gain? And the data value for the Q you want.
|
|
|
|
Post by mo13 on Jan 17, 2022 16:09:46 GMT
Since Q and Gain are systematically deactivated on LPF 1st and HPF 1st, (you can't make that out from the image but you can't move those faders they are turned off) I assumed they won't need any specific msg there,
with controlled by CC I ment just ordinary CC out of a fader with 127 values to control the Freq. As you already mentioned it should be doable by multiplication.
Does the frequency go from 10 to 22000 Hz as the 16-bit value goes from 0 to max, or does it contain the frequency value exactly? We need to know what the hardware expects.
That's a good question, there is not much more in the manual on how it's ought to correspond to control; further understanding of this is a little too over my head as well.
Could you clarify the frequency control by items? Does that mean that the frequency for input 1 LPF is controlled by the 3 bytes BD 00 xx? Or do you mean that's the CC input from the controller? If it's the controller, how do those map into the message bytes, filter # and type?
I'm thinking that it's CC input of the controller for Freq, in my own words again :
Input 1 BD 00 = F0 00 21 27 19 39 mixer1 -00 filter# -00 filter type -00 Freq 3 bytes -00-to-127 (aka CC value 0-127) 3 bytes of Q -00 00 00, 3 bytes of gain -00 00 00 F7
Input 1 BD 01 should be the same only now it's the next filter @ Input 1 in the row of 4, and the type is now changed to HPF, I can set everything manually as well from the Configuration panel, the only desired control is over the Freq. But please, If this is not helpful then don't bother putting work in it. Guess this parcticular way of SySex control is a bit less obvious then on the Disting.
|
|
|
|
Post by uncledave on Jan 17, 2022 16:35:14 GMT
'Less obvious". The problem is the documentation, which just says "3 bytes" for the frequency. They obviously don't intent this to be user adjustable, so they don't bother to explain. And you guess that we don't need any specific message for Q and Gain, but we'd have to include them in a message. Do you assume 0 would be OK? Or will the hardware reject that as invalid? Hard to say.
Can you get a look at the SysEx messages being sent by the config app? We need to know how the slider values are converted to the 16-bit value, so we can figure out how to scale a CC value to fit.
Also, if the max frequency is 22000 Hz, 22000/127 = 173 Hz. So one CC increment would be insignificant at the high end, but huge at the low end. That's why we'd need a logarithmic scale. And that could be more precise if the range is limited. So you need to think about the actual range over which you want to adjust the frequency. Then we can cook up a suitable log scale.
|
|
|
|
Post by mo13 on Jan 17, 2022 16:53:01 GMT
ofcourse, didn'nt think of it, good call @what comes out!
Freq Input 1 filter 1 LPF :
fader all the way to the left :F0 00 21 27 19 39 00 00 01 00 00 00 00 00 00 00 00 00 F7
right : F0 00 21 27 19 39 00 00 01 01 7F 7F 00 00 00 00 00 00 F7
Freq Input 1 filter 2 HPF
HPF:
L : F0 00 21 27 19 39 00 01 01 00 00 00 00 00 00 00 00 00 F7
R : F0 00 21 27 19 39 00 01 01 01 7F 7F 00 00 00 00 00 00 F7
Freq input 2 filter 1 LPF
L : F0 00 21 27 19 39 01 00 01 00 00 00 00 00 00 00 00 00 F7
R :F0 00 21 27 19 39 01 00 01 01 7F 7F 00 00 00 00 00 00 F7
hope this is a little clear from here now?
|
|
|
|
Post by uncledave on Jan 17, 2022 17:34:54 GMT
Much better. It looks like the 16-bit values here are signed. 03 7F 7F is the meximun 16-bit value, but it uses 01 7F 7F for the max frequency, leaving the negative side unused. And, as you thought, zero is valid for Q and gain, so that's easy.
Could you check a few freq values in the middle? Say 500, 1000, 2000, 5000, 10000, 22000 Hz? Only need to check one filter, or course.
And is the range always 10 Hz to 22,000 Hz?
I just want to see if the freq in the message is a simple linear value, or if it's log scaled (like notes or CV).
I assume you'll be using this in MidiFire, correct? It makes a little difference if it's in AUM instead.
|
|
|
|
Post by mo13 on Jan 17, 2022 17:56:50 GMT
yes Midifire and range is indeed fixed 10 Hz to 22,000 Hz
the config tool doesn't allow to set Hz that accurately so this is is as close as I got :
527.8hz F0 00 21 27 19 39 00 00 01 01 03 76 00 00 00 00 00 00 F7
1043hz F0 00 21 27 19 39 00 00 01 01 1A 4A 00 00 00 00 00 00 F7
2061hz F0 00 21 27 19 39 00 00 01 01 31 1E 00 00 00 00 00 00 F7
4996hz F0 00 21 27 19 39 00 00 01 01 4E 58 00 00 00 00 00 00 F7
10567hz F0 00 21 27 19 39 00 00 01 01 67 4D 00 00 00 00 00 00 F7
|
|
|
|
Post by uncledave on Jan 17, 2022 18:01:54 GMT
Neat. I'm gonna check this out.
This will take a little time, but it ought to work. We'll see.
|
|
|
|
Post by uncledave on Jan 17, 2022 22:52:41 GMT
This turned out somewhat easier than expected. It turns out that the input frequency scale is logarithmic, confirmed by your test data. The formula converting frequency F to binary value V is
V = 32767 * (log(F) - 1 ) / (log(22000) - 1)
1 is log 10, so this works smoothly. The logs here are traditional logs to base 10. This gives exactly the values you saw, when you account for the annoying 2:7:7 split.
I've tested the following in MidiFire, driven from controllers in LK, configured to match yours, and the SysEx outputs appear correct. Note that the monitor in MidiFire truncates the display with ... The only monitor I found that shows the full message is the old MidiFlow Monitor, running stand-alone. I had trouble making it work properly using internal routing between AUv3 in AUM. Seems like the message is transmitted in chunks, so it makes no sense. You're sending it to an external port connected to hardware, so should work fine.
#SetFilterFreq
If load
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
End
End # Initialization ———————————————————————————
If M0 == BD
Mat I00 = M1 / 2 # mixer number
Mat I01 = M1 % 2 # filter number
Send F0 00 21 27 19 39 I00 I01 01 +F
Mat I02 = 100 * M2 # shift CC value up in 16-bit word
SendWord I02
Send 00 00 00 00 00 00 F7 +F
Block
End
Notice how we send the message in 3 parts, first the prefix, with mixer and filter selections, then the 16-bit frequency, then the tail. The SendWord function slices a value into the 3 bytes required for transmission. We can just multiply the input CC value by 100 to position it correctly in the word. A CC input of 127, or 7F, will produce 7F00, the max possible using 7 bits in a positive 16-bit word. You should find that the middle position of your controls gives frequency of
√(22000*10) = 469 Hz.
That's what you'd expect for a logarithmic scale from 10 to 22,000 Hz.
I checked the frequency ratio you'd see for a step in CC value of 1, corresponding to a change of 100 ($256) in the 16-bit value, and it's 1.061973. A semitone is 1.054963, so this is just over a semitone, which is pretty good resolution for filter cutoff frequency. Because of the log frequency scale, it will be the same throughout the range.
And that middle value of 469 Hz is about Bb4 (middle of treble clef) (using C4 as middle C). So that's where you should find yourself. An octave should be 11.5 steps in CC, and there are about 11 octaves full-scale. That's a handy mnemonic.
|
|
|
|
Post by mo13 on Jan 18, 2022 7:39:35 GMT
it's definetily not taking a liking to a few things, tested with F8R faderbank and EC4 which is already used for DIsting Sysex control, the Freq is pretty much non responsive but will occasionly jump from 22.00hz - somewhere in the middle - 10hz. I got the MidiFlow monitor, here is what it gos out :    is it sending the right things? the faders in the config tool also become laggy and less responsive after it receives SySex from the controller, at one point it also froze MidiFire which happenned for the first time ever. so maybe too much inpredictabilty going on here? |
|
|
|
Post by uncledave on Jan 18, 2022 11:57:26 GMT
Yes, it's sending the right things. It exactly matches the samples you posted. Sounds like it's only responding to the high bit, in the first byte of the 3-byte frequency value. The high bit comes on at exactly halfway. I suspect there's a problem with sending the SysEx in 3 pieces, which SB requires since it can send at most 16 bytes in one message. It looks like MidiFlow Monitor is collecting the pieces and displaying them correctly. I thought that showed that MidiFire was collecting them before sending to the port, but maybe it's not. We need something that will collect the pieces and forward them as one MIDI message. nic had a suggestion, but I'm not sure how to make it work. You could try sending it to one of the MidiFire virtual ports (enable them in settings), and in AUM, route that port to ES-9. That might do the trick. Exactly how do you connect from iPad to ES-9? Via a ES-9 USB port, using a 5-pin interface, how? How does ES-9 appear in MidiFire? Aside from that possible work-around, let's put it aside for a day or 2 and let me think and try some tricks. |
|
|
|
Post by uncledave on Jan 18, 2022 12:21:28 GMT
Here's another trick that may work. Use the StreamByter AUv3 in AUM. Load the script to it. Replace the LK inout in the routing shown with your controller, and route the script output to MidiFire. In MidiFire, route the messages to ES-9, replacing the MidiFire output port shown. The transfer from AUM to MF seems to collect the message, as shown on the monitor. It says 19 bytes, which is correct, although it truncates the message with ..., which is annoying. When I run the script in MidiFire, the monitor shows fragments, so this is encouraging. It might actually be enough to route the script output directly to ES-9 in AUM; I'm not sure where the collection of fragments happens. Tap on these thumbnails to view them full screen. Edit: looks like it might be OK straight out of AUM. You could try that if you're not sending anything else to ES-9. If there are other messages for ES-9, it's probably better to handle all that in MF, so it can merge the data into a single stream. Also, if you're already using AUM, you can add SB and this routing to what you already have. It's just an extra unrelated feature, added to what's already there. Finally, I wanted to mention that the script only blocks the BD messages that it handles, and it doesn't check that the CC# is between 0 and 5. We could add that, if needed. And to ensure nothing leaves the script except the SysEx, just add Block as the very last line, after the last End.   |
|
|
|
Post by mo13 on Jan 18, 2022 13:24:17 GMT
got it sorts of working with your last example, from AUM - EC4 - SB - MF-virtual out - MF - ES-9, [after reading your edit it also indeed works directly from AUM] ES-9 shows up in MF, as it's on a usb hub on the iPad. a little less luck with F8R faders, but that might be understandable, as the way it's connected is first it gos to a midi breakout module connected by dupont cables, out of the breakout it gos by 3.5 midi into EC4 where it get's forwarded to ES-9, there is some seriously noticable latency as well compared to controls straight out of EC4. I think I've made a mistake about the second filter of Input 1, as BD 01 is now also responding to LPF instead of HPF and I compared the SySex again and it's not exactly what I wrote earlier, sorry for that. the most convenient way without mistakes would be to open up the config tool, you don't need the hardware for it to generate SysEx, www.expert-sleepers.co.uk/webapps/es9_config_tool_1.2.html (works in Google Chrome for web midi) if you scroll downwards to the filter section, when you move the faders it will show you the last SysEx sent in the upper window. strange and interesting how it doesn't like it going straight out of MF though! |
|
