I am now back home for a while so I thought I would knock something up for Duplex for the Frontier Alphatrack.
After hacking around this morning I have the fader controlling volume, solo, pattern loop, block loop, next pattern, previous pattern, play, stop and record toggle working! This lua scripting is quite fast when you know the APIs!
However, I need to do two things to proceed:
I need to ‘hook’ into the Mixer / Transport and Effect applications. e.g. when I press the record button (which is mapped to the tranport application) I need to intercept this to enable / disable the LED as required. Another example is update all the controls when I select a different track.
The other thing is to send ‘raw’ midi messages to update the screen. I tried playing around with self:__send_message but this limits it to three bytes while I need to send more than this.
In a nutshell, while I can get messages in to Renoise, I need to pick up certain actions to push updates back out to the controller.
Any assistance with the above would be greatly welcomed!
This won’t help you, but as a side note, there’s a guy named Airman posting in the forums working on a tool that controls the Presonus Faderport. When I saw an image of the AlphaTrack, they kind of looked familiar…
The specs mention that the fader has 10-bit resolution - do you simply use it in some sort of 7-bit compatibility mode?
ATM Duplex is limited to 7-bit messages, which is also why the Faderport has spawned a separate project.
If I understand you correctly, the record LED indicator need a separate CC message? Judging from the image, it’s the small LED above the record button. It should be possible to create an additional mapping for that in the transport class, which could be called record_status or something…it would be a ‘non-interactive’ mapping that simply show if edit mode is enabled or not.
Precisely which controls are we talking about? Volume, DSP effect…? Can you explain how you’ve configured the device layout?
If the screen supports standard MIDI messages for display updates, it should definitely possible to control the screen. Does the Alphatrack come with detailed MIDI specs for doing this?
Instead of hacking the Duplex MIDI device class, it’s probably easier to modify the MIDI snippets to achieve this (sending raw messages and/or sysex should be enough?), and then integrate this into the device class.
Haven’t really looked into it yet. The motorized fader sends and recieves pitch bend messages. Simply assigning it to levels in the Mixer application works across the full range, although, like you said, probably not with full accuracy.
Most of the buttons and LEDs are fairly simple to control. Button presses are individual notes (full velocity when pressed). Enabling the LEDs is the same method (the same note as the associated button) full velocity to enable, anything else to disable.
I have written small wrapper functions to enable and disable the LEDs, which I have tested and are fully working.
However, for example, when I press the record button to enable edit_mode (through the transport application mappings) I would also like to call my wrapper function to enable the LED. Likewise, when leaving edit_mode to disable the LED. I would also like to keep the LED status up to date if this changes through another means (such as clicking the button on the screen). I could probably do this through polling the status but it doesn’t ‘feel’ the right way to do it.
At the moment:
the main five transport buttons at the bottom are assigned to the Transport application
loop and block loop (flip button) are also assigned to the Tranport application
the fader, solo, mute and track left/right are assigned to the Mixer application (mute doesn’t appear to work, but this might be my mistake somewhere)
the first encoder is assigned to pan in the Mixer application (issue with relative encoding here at the moment)
Here is a direct link to a PDF of the MIDI implementation. It appears to be very simple in theory, but I cannot see how to send the messages.
In the future I would like to be able to switch ‘modes’ with the device through the 5 mode buttons underneath the encoders.
Does anyone else have one of these devices and would be willing to help?
Once I have tidied up my code I’ll attach it to a post later today.
This should be working out-of-the-box, also bi-directionally. When edit-mode is enabled in Renoise, the button should light up on the controller, and vice-versa. I wonder if it has something to do with the device using note messages instead of the usual CC’s? The way it works with most devices is, that a lit button will output the “maximum” value, and an unlit button the “minimum” (as specified in the control-map). Can you turn on ‘dump MIDI’ from the Duplex menu, and verify that the Transport application is actually sending messages to the controller?
Yeah, relative messages is on the TODO list, so I guess for now you’re stuck with using the encoders for absolute messages only. Don’t worry about implementing that yourself, this is something Duplex is supposed to support. Just a question of getting there.
A couple more questions: when you use the controller to switch between tracks, will the fader output a different message? So you have multiple ‘virtual’ faders that you can toggle between? Does this also apply to the encoders, or do they have a fixed value?
Sure. It ‘kind-of’ works out of the box. I think this is due to a quirk with the way the LEDs work. Rather than having a note-on message (velocity = 127) to enable and note-off to disable (which is what ‘out-of-the-box’ behaviour is), it is note-on to enable (velocity = 127) and note-on to disable (velocity != 127).
Ok.
No, the fader just sends pitch bend messages (command E0) which look the same on the midi dump in the terminal.
I’m thinking that to fully support all the quirks and features of this device it might need to be a dedicated tool like the Faderport one.
I’m curious - it has to identify the active track somehow (via the MIDI channel perhaps). I mean, you’re not limited to controlling a single track, or?
Sure, as this seems like a very specialized piece of gear. Supporting every feature; the LCD display driver, 10-bit messages and relative encoders make it quite the mouthful
As Connor pointed out, you might want to talk to Airmann about his progress on the Faderport driver.
Well, the controller only has the physical interface to control a single channel / track. It looks like it is up to the software to manage which track is currently being ‘controlled’.
Indeed. After digging around the Duplex API I got frustrated (now passed) and started a new tool to have a play around with and I am progressing quicker than I thought I would. I think this will be the route to go down as I have a lot of hope for this little controller.
Guess mxb you could take advantage of my code and docu, because during the last 3 moths I’ve solved a lot of technical issues
for that class of controllers.
