New studiologic controllers are (IMHO) extremely interesting. I bought SL73 mkII and I like it a lot.
Only drawback is that in pure MIDI mode it is not possible to use buttons and pots. No CC mapping. There is a SL link mode that allow to drive their software app NumaPlayer. Cute but not what we really want …
Now I see that Camelot developers added a way to use all the hardware things on the controller to map their software. Obviously I am dreaming of a GigPerformer mapping. Full use of buttons, pots and display would make that controller the perfect choice for all of us.
Any way to try this chance? See the mentioned vid here below
GigPerformer is a “general purpose” application. In this case, there is low-level integration between hardware and software. On the other hand, audio modeling is in close collaboration with StudioLogic. GigPerformer uses standard MIDI (Sysex) and OSC protocols. If someone wants to make a hardware product that integrates GigPerformer functionality, they should use the OSC protocol, which is documented. For this reason, some of us extend the functionality of GP with Touch OSC or Open Stage Control without using specific hardware that does not currently exist.
In other words, Gig Perfomer is software, so the request should be made to a hardware manufacturer. I am developing a board that is similar to Mixface, managing DAW/MIDI configuration profiles. The only idea I have at the moment is to integrate OSC via WiFi to manage a specific profile for Gig Performer. But if OSC can be used to create UIs that run on inexpensive devices, via the web, etc., I wonder if it’s really worth the effort. .
There is also an SDK available that allows developers to create extensions (completely with user interfaces) in any language that supports C headers (e.g, C++, Python, Pascal, etc) that can be loaded into Gig Performer.
Ask StudioLogic for the protocol document for SL Link. They make reference to it, and mention that Camelot uses it, but I can’t find any actual documentation of the protocol.
The Novation SL MK3 and its “In Control” protocol was initially like this as well, where it existed and was clearly being made available to some developers, but was not public. A little of the same with the iCon P1-M/P1-Nano/V1-M controllers currently (where iCon won’t publicly release the full protocol).
I agree with dhj’s comment above, that this is something that can and probably should be managed through an extension. It doesn’t look like anything too complicated is going on and should be pretty easy to work with. (In contrast, the Ableton Push 3 is way more complicated when it comes to the screen displays, and the Native Instruments keyboard interfaces just don’t lend themselves well to this sort of thing.)
The first step would be finding out if they’ll make the protocol document available. Wouldn’t surprise me if they required signing a non-disclosure agreement at this point given that it’s probably still kind of beta test level.
I just wanted to clarify that it’s not a question of software or programming language, this is a hardware device that implements a protocol, and I don’t personally know what kind. At the moment, it offers a specific feature only for Camelot Audio Modeling, which works closely with Studio Logic… If the protocol is documented, I agree with Vindes and Dhj’s that it can be developed, for example, with an extension. But I think their goal is different. If you are a Camelot or SL user, you will be tempted to buy one or both. And i’m a user of Studiologic .. it’s just my opinion
I am going to ask to Studiologic then. If they agree I will share here. I think it would be a benefit for GigPerformer users, SL owners and also for Studiologic. Future is for open interfaces…
I have an SL88 Grand, but the prior version that doesn’t have this feature. I’m planning to buy another 88 key controller in the next few months. It’s probably going to be the SL88 GT anyway, but the ability to use SL Link would make it a no brainer if they make the protocol available. I’ve already written extensions for a few other controllers (see Github: WidnerM GigPerformer extensions) so this would also be on my list.
.