Novation SL-MK3 Extension

[Vindes]

Sorry, I had forgotten to save the updates there. The current release on the GitHub page is now updates for GP 4.7.

[OAkeys]

Thanks Vindes! You’re awesome

[amosdef]

@Vindes

The current release on the GitHub page is now updates for GP 4.7.

Have you tested this out on 4.8? Just ordered an SL61, and looking forward to using this extension with it on the current GP release if possible. If not, I’m happy to help with any testing of a new version

[amosdef]

Seems to be working on 4.8!

Does anyone who has this keyboard have a very fine scaling on the knobs? It’s taking 3 full rotations to go from values 0-127 and I’m not seeing any options to change that in the hardware. I vaguely remember this being an issue before, but was hoping they fixed it or added sensitivity settings to the firmware

[Vindes]

With the extension you can change the sensitivity (resolution) of the knobs with respect to adjusting widget values. It’s described at the bottom of page 4 of the powerpoint/pdf document on the GitHub page for the extension. I believe I put an example in the demo gigfile.

Now that you mention this, I recall that I had planned to make it so you could set a default knob resolution that would apply to all knobs unless you override it for a knob bank or an individual knob.

Right now I believe you can only set it on an individual knob basis by setting the “parameter widget” for the knob accordingly.

In short, if you have a knob widget named “sl_k_vol_3” you can set the resolution by creating a parameter widget named “sl_kp_vol_3” and putting the desired resolution in the caption after an “_” character. So if you want the knob name to read as “Volume” and the resolution to be 200 you’d set the caption to “Volume_200”. That number (200) is the number of knob “ticks” it takes to change a widget value from min to max (0 to 1). The default is currently 1000 I believe.

I’ll add the ability to override that default, but I’m out of town until next week so don’t hold your breath.

[amosdef]

Thank you! That is very helpful and worked perfectly! I’m already working on testing out my live gig file to add zone lights on the SL61 which is very helpful for complicated rackspaces. And the knobs are useable with the scaling set at 200. If you can add the default resolution, that would be perfect! I may find some parameters that I’d like a larger resolution, but probably not 1000 or whatever it is.

It’s a great extension and I’m looking forward to using it live. Thanks again for your help!

[Ali]

@Vindes Thank you soooo much for this extension! It is so helpful and works great! Together with the Novation SL61 it’s exactly what I was looking for my live rig! Cheers !

[npudar]

You found about it through the latest blog article?

[Vindes]

@amosdef

the knobs are useable with the scaling set at 200. If you can add the default resolution, that would be perfect!

I made a small update and now the knob resolution can be set using widgets in three ways:

• a global knob default resolution set in a widget named “sl_knobresolution”
• a per knob bank resolution with a bank “p” widget named like “sl_kp_groupname” (will override the default above)
• a per knob resolution using knob “p” widget named like “sl_kp_groupname_3” (will take precedence over both of the above)

The per knob “p” widget ones work as they did before. The widget caption should be set something like “Volume_200” where Volume will be the name that appears on the screen and 200 will be the resolution.

The per knob bank “p” widget will be used if the individual knob “p” widget doesn’t exist. The widget caption should be set something like “Mixer_Pans_200” where “Mixer_Pans” will display on the two left lines of the rightmost display (showing what the knob bank is) and 200 will be the default resolution for the bank.

For the global setting, create a widget named “sl_knobresolution” in the global rackspace (or individual rackspaces if you want different defaults per rackspace) and set the caption to the number of steps for the full range. Default is still 1000, but something like 200 would probably work well for most things.

The latest version of the extension, along with an updated demo Gigfile, is on the GitHub page linked in the first post of this thread.

[amosdef]

@Vindes

I made a small update and now the knob resolution can be set using widgets in three ways:

Very cool! I’ll download and test it out

[bhubauer]

Greetings Vindes. Well done! Very clever and pragmatic to use a simple naming convention to link to widgets to the hardware. I have some fairly complex Gig files but I see the obvious benefits to rework them to incorporate your extension.

As a touring musician I always have to have a fall back plan when a piece of hardware or software fails – Since I may have to swap in a different kind of controller at the last second in order to get through a gig, I’ve relied heavily on the “Rig Manager” to add indirection between the widgets and hardware. I only have to update the “Rig”, and all my Rackspaces will just work.

If I had to quickly swap out a controller at the last minute, I would have to go through every Rackspace and manually map EVERY widget to a controller – Have you put any thought into this scenario?

I’m thinking I might be able to still use Rig Manager, but not have a device associated with the Rig unless I need it. (I didn’t look to see what you would do if there was an “sl_” name AND a midi assignment.)

Any thoughts?

Oh, also, what if you have two different SL MKiii?

[Vindes]

@bhubauer

what if you have two different SL MKiii?

I didn’t anticipate having two different MK3’s connected at the same time being a likely scenario, so the existing code makes no provision for it. As the extension is now, you could make use of multiple MK3’s by running two different instances of GP. The two keyboards would have different MIDI port names, so you’d just have to define them appropriately in each Gigfile.

If you mean having a backup MK3 and using that if the primary one dies, that should just work.

@bhubauer

I may have to swap in a different kind of controller at the last second in order to get through a gig

I don’t use the Rig Manager at all, so I’d have to look more closely at how it interacts with the widgets to have a well informed view. That said, off the cuff I’m not seeing a reason that there would be a conflict.

The extension just responds to activity on the midi port you specify by name. If that midi port doesn’t exist in your current hardware setup the extension won’t do anything, meaning that it shouldn’t interfere if you have backup controls defined through the Rig Manager.

Let’s say you define an entry “Piano1Vol” in the rig manager and also have it named “sl_k_volumes_0” for the MK3 extension. It should respond to both. The extension gets notified if the widget moves and then reflects that on the MK3. It doesn’t care if it moved because you moved it by mouse, touch screen, or a different MIDI controller. I don’t think having the Rig Manager involved should impact that at all.

I would like to have the ability to swap from one extension (e.g., SL-MK3) to another (e.g., Mackie MCU) without having to rename widgets, but there’s a limit to how far I want to stretch those widget naming conventions.

[bhubauer]

Thanks for the explanations – I did play around with combining Rig Manager and your extension. It seems to work ok, but I’m not 100% sure your code isn’t seeing double messages… Looks promising anyway. If I was starting a new gig file from scratch I would definitely leverage your extension, but I need to decide how much rework I want to put into my existing ones…

Thanks for making it open source – I’m also a C++ developer so I plan to check out the code. If I come up with any improvements I’ll definitely send you a PR for your consideration.

[Vindes]

@bhubauer

I did play around with combining Rig Manager and your extension. It seems to work ok, but I’m not 100% sure your code isn’t seeing double messages…

Well, if you have a CC from the SL-MK3 controlling a widget in the Rig Manager, and that same widget getting picked up by the extension, then yes, you would get double movement with a knob.

What I meant was that if you have your SL-MK3 and the extension running, just leave those entries disconnected in the Rig Manager. You’d only want to go into Rig Manager and assign them if you didn’t have your SL-MK3 connected.

@bhubauer

I’m also a C++ developer so I plan to check out the code. If I come up with any improvements I’ll definitely send you a PR for your consideration.

My coding skills are pretty out of date. These extensions were the first thing I ever coded in C++ (or any object oriented language for that matter) so if it looks like it was cobbled together by a blind man it kind of was. You’ll probably also find quite a few functions in there that are never called. Some stuff that became deprecated, other stuff that was copied from a similar extension (MCU) that I wrote prior to the SL-MK3 extension and just copied the code base over. Just FYI.