It might work for one application, but the next…? It would be more practical to make a simple, stateless control and then script the hell out of it. For example, although possible, it wouldn’t really make any sense to write a “grid” user interface component, because such a thing is too versatile to describe in generic terms. You can of course also choose roll your own user-interface components, but you would want to keep them really simple. Then, the device configuration acts as a “permanent mapping” between that part of the application and your controller. It’s a toggle-button, but it can also be made to respond to the whole set of press/hold/release events. In the context of an application class, this is all the code it takes to instantiate a standard toggle-button. but instead, let’s look at how a button is implemented into an application:Ĭ.group_name = "Some group in my device control-map" I could explain how the message is constructed, how it is abstracted from the hardware, etc. As an example, flipping through pages in the matrix on the Launchpad is really snappy. Although it obviously takes a few extra CPU cycles to compute this, it generally makes Duplex way more responsive on MIDI devices which would otherwise “suffocate” when they receive too many messages. For example, pre-optimization before the output stage means that a MIDI message which would tell a light to turn on doesn’t necessarily output anything if the light is already turned on. I’m sorry I can’t give you a more straightforward answer than that, but Duplex really is based on a number of abstractions. Simple question, complex answer: when lights are turned on and off in Duplex, this involves a lot of things. Can someone please point me to the code in Duplex that turns OFF/ON the lights on my Akai LPD8? I can’t seem to find it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |