Not sure that this is necessarily a Duplex related question, or maybe it is…
I’ve been looking at the Nektar range of controllers (P4/6), and their way of integrating seems very tailored to specific DAWs, in that they manually map to an exposed API. They don’t use a wrapper host plugin to access the VST/AUs or the native plugins and transport. It occurred to me that Duplex has a lot of this core functionality in its applications.
Given that Renoise has a pretty open API, would it be possible to achieve the same level of integration that it does with say Reason or Bitwig? Can Renoise (and Duplex) expose the parameter name/values of devices on tracks, be they native devices like Hydra and manipulate the inputs/outputs, given that they might be dynamic, or a AUi/VSTi like Diva (which Nektar currently has mappings for)?
How gargantuan of a task would this be, or is it way out of scope for Duplex?
Not sure that this is necessarily a Duplex related question, or maybe it is…
Duplex definitely has the basics covered - mixer, effects (which would include instr. automation) and such. This is part of the core ‘ensemble’, and works across a wide range of controllers.
The big question - with regard to the nektar range of controllers - is, whether they are making use of some proprietary method for updating the screen or not.
Because otherwise, it seems that they play “nice”, with a standard MIDI specification and all.
The big question - with regard to the nektar range of controllers - is, whether they are making use of some proprietary method for updating the screen or not.
Because otherwise, it seems that they play “nice”, with a standard MIDI specification and all.
This was my thought too, and to that end, I emailed the support to see if they have an open api for the devices…no response as yet. I’m guessing that as Reaper’s API is C++, then they would be interfacing with some proprietary code embedded in the controller? That wouldn’t bode too well for Renoise integration would it?
As an aside, I was thinking of creating an Automap style layout for my Launch Control for visual readout of which ever device is selected in the track. Parameter name/values would update in in the layout panel and changing ‘pages’ of parameters would update the layout too. Would it be best to add code for the additional functionality in the lua file in the root of the directory containing the Configurations and Controlmaps?
Also, is there a reason why the *Instr Automation meta device only shows a max of 35 parameters?
Just to follow up, I got an interesting response from their support: they’d looked at the Renoise API on Github, and it sounded like something could be done - as in they’re keen to cover as many integrations as they can. So no promises, but this might be added in the future. Sounds good to me
Picking this topic up after having purchased the newish Panorama T6, and my initial attempt into creating a duplex controller mapping for the T6 has hit a slight obstacle.
Basically the T6 doesn’t respond to incoming CC to change the lcd display of values, only via sysex, of which the spec isn’t publicly available. Off the controls themselves (encoders, faders, buttons and pads), only the buttons and pads issue any kind of visual feedback. So I guess for now a closed spec is a blocker for this now.
With this in mind is there any point in making a map in Duplex, beyond making a standard midi map?
I was thinking that an Effects layout could be useful with the currently selected device parameters displayed and with pagination. It also uses MCU protocol which sort of works, sort of doesn’t: the Play/Stop work, Rec toggles on but won’t toggle off edit mode, RW/FF buttons don’t emit CC or Note values, only sysex as far as I remember.
So I guess for now a closed spec is a blocker for this now.
That’s a bummer. I don’t get why equipment manufacturers still think this is a good idea (closed specs)
It also uses MCU protocol which sort of works, sort of doesn’t
Well, at least there’s nothing “magical” going on here.
You could easily recreate this configuration manually - that would also give you more finegrained control over playback/transport options, etc.
Hopefully quick thing, where does one initialise the Duplex view with the device values? Currently the labels only get updated when the controls are focussed and changed. Odd that param_names labels get initialised on load however, not param_values. I need to brute force update them.
The MCU transport events are sysex - I assume that this is what you mean I’d want to intercept to roll my own? It’s only the Record (Toggle edit) control which is giving the issue.This is the string sent by record from the T6:
You mean, the on-screen control surface or the controller itself - or both?
I mean the on-screen gui as per the screenshot.
So far we are not able to update the actual controller, as we don’t know the sysex to update the LCD (although that has got me thinking that maybe it is possible to reverse engineer the sysex from one of the Reaper integration files - wherever they live - for example?).
You mean, the on-screen control surface or the controller itself - or both?
Hm, let me take a quick look. I believe Duplex should ignore the message you posted (it’s “MMC Pause”, which is not implemented)
Sorry @Danoise I was confusing MMC and MCU. MMC of course is a totally separate protocol and uses sysex for transport commands. MCU is using note data for its transport. When I switch the keymap to assigning to the corresponding notes then the all is good. Record/edit works fine.
The Panorama controllers are pretty confusing beasts at first, but appear to use no less than 4 separate ports to send their data for each of the modes: transport mcu note data will send on port 2, so as not to interfere with actual note data on port 1 for example. Duplex will handle this fine I think - I can set up a Port 2 config as a separate device that runs alongside, so the transport will work what ever mode it’s in.
Btw did you get a chance to look at why the parameter value labels don’t initialise when changing pages or devices?
Btw did you get a chance to look at why the parameter value labels don’t initialise when changing pages or devices?
Just following this up, but…
I did some snooping around in the Effect.lua app file and came across this little nugget commented out. I uncommented it and now I have param_values rendering in the UI labels. Sweet!
Is there a reason it is commented out though? and editing it here is likely to break when I update the tool in the future. Can this method be overridden in my controller class?
