vladistone Posted March 23 Share Posted March 23 Do you think so? any other opinions? https://forum.keyboardmaestro.com/t/specify-midi-or-keystorke/4521?u=vladistone Quote Link to comment Share on other sites More sharing options...
Bullfitta Posted March 23 Share Posted March 23 This is the way I use Keyboard maestro to send all types of midi: https://forum.keyboardmaestro.com/t/midi-program-change-action-midi-to-external-device/27043 Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 23 Author Share Posted March 23 (edited) thanks again for your help, I appreciate it! but I would like to understand the reason behind the action of the KM moderator? The KM is commercial product that is not free (like Hammerspoon and is open to criticism and PR...) As I mentioned in the KM forum thread: the problem is that KM - fragments a single Sysex message into 3 parts (as separate messages that do not make sense) which is also interpreted by MIDI receivers in fragments ... and does not lead to the desired result! for SysEx order exsample: F0 00 00 66 10 12 90 64 7F F7 KM result: 12:39:43.200 From Keyboard Maestro SysEx Loud Technologies / Mackie $6 bytes F0 00 00 66 10 12 12:39:43.200 From Keyboard Maestro Note On 1 $64 $7F 12:39:43.200 From Keyboard Maestro Invalid $1 bytes and in fact the moderator's reaction is a painful topic that he does not like! Edited March 24 by vladistone Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 24 Author Share Posted March 24 especially in another thread there was a constructive dialogue and analysis of my bug https://forum.keyboardmaestro.com/t/how-to-send-sysex-or-obtain-more-midi-values-with-km/14002/2 Quote Link to comment Share on other sites More sharing options...
gacki Posted March 24 Share Posted March 24 I'm not quite sure what you're trying to achieve. The $90 is a classical "user error"; in a perfect world KM wouldn't even allow you to input this - but I fully understand why this isn't high on their priority list. Quote Link to comment Share on other sites More sharing options...
Mamajolai Posted March 24 Share Posted March 24 Bullfittas way is the way I use too….much better then trying to twist Keyboard maestros arm… Quote Link to comment Share on other sites More sharing options...
volovicg Posted March 24 Share Posted March 24 What am I missing here ( no I didn't read the other forum yet). 90 is in invalid data element in a sysex message. So while a syntax check disallowing this from the getgo would be good - end result is it is invalid. So why do you believe 90 is correct ? sure you didn't confuse hex for decimal ? - 90 decimal is valid - 90 hex is not. Quote Link to comment Share on other sites More sharing options...
gacki Posted March 24 Share Posted March 24 What is happening here (and why it is not really a bug): The $90 is a new status byte. The MIDI specification says: Quote Except for Real-Time messages, new Status bytes will always command a receiver to adopt a new status, even if the last message was not completed. So what @vladistone is observing is exactly what any receiver (in this case MIDI monitor) should do: the part up to the $90 is considered an (albeit incomplete) sysex string; the $90 $74 $7F is considered a Note On (which gets MIDI monitor out of its "Sysex" state); and the remaining $F7 is invalid because it is an "EOX" status byte on its own which only makes sense in an ongoing Sysex transmission - however the initiated transmission was automatically ended by the $90. Quote Link to comment Share on other sites More sharing options...
gacki Posted March 24 Share Posted March 24 Some more thoughts: The moderator is correct - it's not KM's problem. I'm not 100% sure how the internals of macOS work nowadays but I'm pretty sure that KM simply hands the bytes to CoreMIDI. It might well be that CoreMIDI then adds the additional $F7 when the message hits the $90 value. Or MIDI Monitor adds it on its own (I'm too lazy to look through the sources). Insisting that this is KM's fault or problem or bug is simply wrong. I don't know if I would consider it "rude" (I think of myself as having a rather thick skin) but it certainly could be seen as annoying. Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 24 Author Share Posted March 24 2 hours ago, volovicg said: What am I missing here ( no I didn't read the other forum yet). 90 is in invalid data element in a sysex message. So while a syntax check disallowing this from the getgo would be good - end result is it is invalid. So why do you believe 90 is correct ? sure you didn't confuse hex for decimal ? - 90 decimal is valid - 90 hex is not. Hi @volovicg it's not mistake: I need to send the message to controller addres 0xF0 0x00 0x00 0x66 0x10 0x12 0x90 0x64 0x7F 0xF7 (in another word command: ""Note On" channel 1 "E6" velocity =127") Quote Link to comment Share on other sites More sharing options...
gacki Posted March 24 Share Posted March 24 2 minutes ago, vladistone said: I need to send the message to controller addres But you can't. It's a mistake (as was pointed out numerous times by now). You can't have 0x90 in a SysEx dump. Plain and simple. 1 Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 24 Author Share Posted March 24 1 hour ago, gacki said: Что здесь происходит (и почему на самом деле это не ошибка): $90 — это новый байт состояния. Спецификация MIDI гласит: Ну и что@владистонэто именно то, что должен делать любой приемник (в данном случае MIDI-монитор): часть до 90 долларов считается (хотя и неполной) строкой sysex; $ 90 $ 74 $ 7F считается Note On (который выводит MIDI-монитор из состояния «Sysex»); а оставшийся $F7 недействителен, потому что это байт состояния «EOX» сам по себе, который имеет смысл только в текущей передаче Sysex, однако инициированная передача была автоматически завершена с помощью $90. Well,.. and what is the verdict? How would you shape the sysex string to remain unfragmented before or after the handler? about the KM forum and dialogue blocking: if you notice befor: I asked for help or clarification in the KM syntax, which I may not have taken into account when forming this Sysex message... and to assert categorically and block the dialogue is considered disrespectful to the public ... although even more amateurish statements about MIDI appeared there, for which I had to explain the rules for the formation of SysEx ... I agree that it was superfluous Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 24 Author Share Posted March 24 (edited) 11 minutes ago, gacki said: But you can't. It's a mistake (as was pointed out numerous times by now). You can't have 0x90 in a SysEx dump. Plain and simple. Do you think this is a stalemate? or have is other decision? Edited March 24 by vladistone Quote Link to comment Share on other sites More sharing options...
gacki Posted March 24 Share Posted March 24 2 minutes ago, vladistone said: Well,.. and what is the verdict? How would you shape the sysex string to remain unfragmented before or after the handler? Once more: There is no SysEx string possible containing a 0x90. Whatever you're trying to do there you're doing it wrong. You can't have other Status bytes within a Sysex string; the highest SysEx data byte is 0x7F. 1 Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 24 Author Share Posted March 24 (edited) 4 minutes ago, gacki said: Once more: There is no SysEx string possible containing a 0x90. Whatever you're trying to do there you're doing it wrong. You can't have other Status bytes within a Sysex string; the highest SysEx data byte is 0x7F. welldone! it's clear me! But how to reach the target? (message 90 64 7F to virtual MIDI port 1) Edited March 24 by vladistone Quote Link to comment Share on other sites More sharing options...
gacki Posted March 24 Share Posted March 24 It would help me if you could describe what you're trying to achieve. This looks at first glance like some Mackie Control stuff. Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 24 Author Share Posted March 24 (edited) yes! it's MCU emulation I would describe this task like this: you need to switch on the lamp of the controller button that is responsible for tracking of changes of the LPX GUI "compare" button (when any parameters change in the FX/plugin/smart control window) in order to signal the change and it will possible to change this state back with this button here additional task discribtion: Edited March 24 by vladistone Quote Link to comment Share on other sites More sharing options...
gacki Posted March 24 Share Posted March 24 In response to your other thread "interception of hidden LPX events": There are no "hidden Logic events" that can't be captured by MIDI monitor or other tools. After all; originally the MCU was a MIDI-only device that would be attached to any MIDI port - and what is transmitted over those ports can be traced anyway. I don't have my MCU at home so I can't run in-depth tests right now. But one thing to keep in mind is: Logic pretty much controls what the MCU shows. The GUI elements don't send any messages to the controllers directly; those messages are sent by another software layer (essentially: the driver for the control surface). That's simply because not every control surface has a specialized element for some GUI element. So if you hit "Undo" on a control surface and the Undo LED is turned off it's also a function of that layer/driver. Before I get deeper into this I'll have to pick up my MCU; this might take a few days. 3 Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 24 Author Share Posted March 24 (edited) 23 minutes ago, gacki said: In response to your other thread "interception of hidden LPX events": There are no "hidden Logic events" that can't be captured by MIDI monitor or other tools. After all; originally the MCU was a MIDI-only device that would be attached to any MIDI port - and what is transmitted over those ports can be traced anyway. I don't have my MCU at home so I can't run in-depth tests right now. But one thing to keep in mind is: Logic pretty much controls what the MCU shows. The GUI elements don't send any messages to the controllers directly; those messages are sent by another software layer (essentially: the driver for the control surface). That's simply because not every control surface has a specialized element for some GUI element. So if you hit "Undo" on a control surface and the Undo LED is turned off it's also a function of that layer/driver. Before I get deeper into this I'll have to pick up my MCU; this might take a few days. About that "there are no hidden events": I suggest going to that topic for discussion... since these "hidden events" are still there (I described about "undo"-feedbacking for the MCU controller) - MIDI monitor does not intercept them! Therefore, I was puzzled by the search for the best "interceptor" toolkitthe same is true for the other buttons listed in the topic... which under control by LPX but how implemented don't described into Logic control Edited March 24 by vladistone Quote Link to comment Share on other sites More sharing options...
des99 Posted March 24 Share Posted March 24 (edited) The feedback messages (sent by the MCU Control Surface module) are documented in the control surfaces manual (the original emagic one, not the later simplified Apple one) if you want to know the messages. I've written code to parse a lot of that feedback, to do things like display the controller rings around vpots in it's various modes. They all work fine, and ther's nothing *hidden* about them... 😉 Edited March 24 by des99 Quote Link to comment Share on other sites More sharing options...
vladistone Posted March 25 Author Share Posted March 25 9 hours ago, des99 said: The feedback messages (sent by the MCU Control Surface module) are documented in the control surfaces manual (the original emagic one, not the later simplified Apple one) if you want to know the messages. I've written code to parse a lot of that feedback, to do things like display the controller rings around vpots in it's various modes. They all work fine, and ther's nothing *hidden* about them... 😉 if You mean this Emagic logic control manual - yes, I am aware of it and support you that it provides more information than the Apple tutorial. and as for the control of the controller rings - it is not difficult at all and can be configured thanks to the Emagic manual - in a few minutes, holding the manual in your hands ... but why no one has voiced how the message is transmitted to turn on the backlight of the "undo" button - this remains a mystery that I would like to find out in the next my post Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.