This is also true as presets get added to the list - it changes how the system selects menu items from a given key press.Īnd you may also have the issue of different menu contents are displayed in mono or stereo or surround (different plugins will match those channel types), or between instruments and FX etc, which you have to be careful of. For instance, I started using "S" to trigger a "Save as", but after something has been saved, S now selects the first matching menu option, now "Save" (not "Save as"). I have found that using keys to trigger menu events sometimes won't give consistent behaviour if the menu contents change, as you're not in control of what the system will select for a given key. If you're still stuck, post back and we'll have a look into it. Add in some delays, and see how you get on. You just need to drill down and troubleshoot, but likely you're sending a key event before the menu has had time to initialise, or something like that. Sometimes I've found exactly what is causing the failures isn't entirely obvious (but that's part of any kind of programming, I think). I've never come across an instance where a macro is behaving unreliably that it's not my fault to handle. That got me wondering, if something similar exists for KM. There is a Process Priority Helper Tool in BTT, that you can install from the BTT settings, which makes sure, that BTT Keystrokes and Triggers always have priority in the Mac OS system to secure a more stable execution. So maybe this really could be on logic's side, like you explained. it sometimes gets lost and selects a totally different plugin, not even from the same category, not even having the same starting letters. Thank you! Yeah, maybe i really have to incorporate action delays between the steps:įor a macro that inserts plugin "xyz" (selecting it from custom category "abc") using the arrow keys, as well as the starting letters from the category and plugin names (for example "E" for "EQ", then "P" for "Pro Q", then "st" for stereo, then the return key), it works great when there is not much going on in Logic atm, like a new project.īut "in the workflow" with a bit more going on in logic, while playback and having some plugins windows open etc. The solution is usually to build more headroom into the delays/pauses, and in some case, to actually build in some checking the UI is in the right state before proceding (eg, waiting until a dialog box is shown before clicking "Ok", rather than just hoping the dialog will always be displayed in under 0.5 seconds etc).įor more specific troubleshooting, you'd need to let us know exactly what you are doing, in order to have an idea what might be happening. If you tune a macro to be as fast as possible, then it can become unreliable as things happen on your computer that causes that step to "misfire". You have to factor in those things in your macro programming. For example, clicking on the preset menu on a plugin header will display the menu, including it's list of presets - that list is scanned before the menu is shown, and so if you only have 50 presets listed there, the menu is displayed quickly - but if you have 100,000 presets, the menu takes longer to be shown. I don't know what's happening in your specific case, but there are actions where a variable amount of time can happen between events.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |