[Hi @bert @thetechnobear and friends - congrats on the new release and wishing the team well out at Superbooth!]
So I’ve had my SSP for *a little over two years now (wow, time has flown!) and while it has shown itself to be an amazing instrument, there is so much more ground that I can see it covering with some minor extensions. Doing a ton of thinking over this time about how I can better make use of the system and contribute back I’ve finally come up with what I hope is received as a straightforward, easy to implement, and valuable to the community at large feature request. A simple new functionality that I’d build useful things with immediately, contribute back, and would enable others to do the same.
Given that Percussa’s UI has been stable for quite some time, it seems ripe for extension via automation. I’d like to propose a small but powerful feature that would enable me and the community to extend, customize, and streamline SSP’s physical interface featureset externally while minimizing any effect on higher priority internal development efforts. I have a couple of other questions / wishlist items listed at the end but in essence I’m really just looking for a way to map every physical UI input to an external MIDI control[0][1] (I’m aware of the Macro functionality which does help in limited cases, but it’s not relevant to the scope of the proposed feature capability.) With full automation capability of all UI controls users could not only choose whatever high end physical interfaces are available to navigate the UI in realtime (Monome Arc as the encoders would be incredible, for example), but in some contexts[2] they could also extend/customize/streamline areas like the patch interface in novel/efficient/interesting ways that could also potentially inform/prototype the next generation of the UI itself.
Having programmatic access to all of the buttons and encoders would allow a user to write some valuable automation[3] of repetitive tasks, but not only that; new ways of interacting with the SSP in “flow” state could then materialize. “Jamming” on the SSP in the context of patch editing could become super efficient[4] in ways not conceivable right now. Granted, being able to interact with a complex patch in arbitrary ways on the fly is already possible–I get that this is kind of the heart of what the SSP is all about–but reducing friction in that dimension IMO would produce super interesting opportunities given the SSP’s inherent flexibility and capability around patching.
Again, I would agree that in a practical sense the UI already provides the functionality to build arbitrarily complex patches right now and so there is standing for pushback on a facility/feature-request like this within the scope of that specific automation use case. That is just one example of opportunity this feature can create though. My hope is that (a) connecting UI interface functions to external MIDI controls would be relatively trivial to implement so it would not materially cut into higher priority internal development efforts and (b) the majority of SSP users would agree that they’d significantly benefit from this in some form (mostly the tactile option aspect immediately) and (eventually) there would be valuable engagement in extending the SSP’s capabilities through UI automation.
It is clear to me that the community wants to see the SSP succeed in the long term as I genuinely do, and I strongly believe a cheap to implement feature like this would really pay for itself so many times over which makes it a no-brainer to implement in short order. If it’s really tough to implement, or for whatever reason the devs don’t expect it to ever see the light of day, then maybe [5] would take a few minutes to send out on the forum and we could quickly get some different type of traction on at least improving the patch builder interface that way? I just hope that this feature request is feasible, and that it resonates with the community, or better yet, that I am wrong about it not existing so we can start using it right away 
Appreciate the Percussa team’s time and thanks for your hard work creating such a deeply musical and uniqely capable system. Safe travels in/out of Superbooth and hope you all have a great time out there!
Footnotes:
-
Or I2C, or OSC, or whatever is best. I don’t personally care which protocol. Even something akin to Quartz/Carbon on MacOS would be great (and probably much more powerful, if anything similar is available within the SSP runtime.)
-
Does the SDK api have some kind of facility that could be used to do this already? Could someone just write a VST module that can turn encoders and push buttons which could then be connected with the MIDI module as normal? I don’t know how the internals work but on the surface maybe extending the api that way is the right approach to expose these systems to external developers.
-
Is there an API to read the value of what the is in focus on the cursor or an encoder (or an encoder if the shift button is held down, etc)?
-
Can I disable encoder and menu rollover behavior so that a naiive automation implementation without knowledge of the current value could simply roll the encoder a bunch or hit the button many times in the “down” direction to index itself to zero before proceeding to set an intended value?
-
What is the reasoning behind requiring the user to manually whitelist the input of a destination module after its connection from the source module has been defined in the source module’s output list? Could there be a user configuration to make that happen automatically (and conversely to automatically un-whitelist the input when disconnected) by default? Pardon if I’m getting the directional part of this wrong or something else (I haven’t had time to interact with the UI for a little while) but IIRC there is duplication of effort in this process by having to full-duplex a configuration step which conceptually should only require one relationship edge to be specified initially.
-
It would be enormously useful to get an official PBP file format specification. With such documentation it would seem straightforward to write an arbitrary patch editor which could (maybe) run in realtime in a VST or externally so users could prepare new patches or modify existing ones with all manner of edit facilities (imagine being able to write a boilerplate patch in YAML for instance, and manually or programmatically manipulate the object until it is ready to go with sufficiently interesting and new settings and patch i/o connections, check it into source control, allow it to be forked/shared/etc, at which point it can be translated back into PBP) outside the confines of the internal patch editing interface, then load a bunch of iterations that were efficiently created to cycle between and tweak inside of SSP from there. Does a complete specification exist internally that could easily be shared with the community? I’m not sure why this part of SSP would need to be proprietary or closed… Percussa could just give community devs a disclaimer that warns of no guarantees of compatibility between releases, could crash the system loaded as written in a corrupt fashion, etc.
) is really a poor way of achieving our aims , frankly - its an overly complex approach, that has too many limitations and will a be constant source of issues and headaches.