@iAladdin Actually it is quite disturbing that drivers are not adequately discussed OPENLY. HOW IS DRIVER DEVELOPMENT NICHE!?! I/O is how we enable our machines to process the ACTUAL world. Who is deciding what we are to process? Why? Why are general developers made to feel as though they are a security threat? Hackers are not evil. On top of that, we PAID to play.
Everything I posted here is still valid and has not been adequately addressed. There is a deliberate DIGITAL DIVIDE. Of course, some manufacturers will get the ACTUAL APPLE API developer technical notes and real unadulterated documentation, with all the experiments and prototype code.
I would like NOT to be treated as a predator, just because I want to know how to leverage the true ability of my hardware. And I would like to share my solutions through my own ad-hoc distribution if not through the Apple App Store.
lleathers
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
@Polyphonic -- Albeit I am still livid about Apple's attitude about I/O driver development documentation, I do truly appreciate your constructive response as to what is acutely germane. Right now I am trying to create simple scripts that read live traffic between the audio hardware and MacOS X as I am tweaking the external controller knobs. I am trying to determine how to access features of now unsupported NI audio controllers for (1) my own personal use and (2) for resale of interesting audio controllers in second hand market. To illustrate, Native Instruments is notorious for "orphaning" really compelling tech, ie, KORE. I'd like to breathe life back into some of these audio platforms for electronic musicians on Big Sur. I would like to create new drivers that alacritously comply with the new secure archetype whereby driver code is moved out of the kernel. I still cannot fully appreciate what code is required to control hardware that is not standards compliant. I'd have to purchase old Apples on ebay, get old Xcode, and read the transcript of the communication and correlate with the kernel extension code. I already got one audio controller to partially work.
Could you suggest "a hacking workflow" for general feature discovery in external devices, particularly audio and midi, connected by USB/Thunderbolt and Bluetooth, using Big Sur?