Before I struggle too much more with this I want to make sure that it’s possible to map the APC40 using Duplex. This is something Duplex is perfect for, right? If so, my next question is - what is the process of translating the Midi dump messages in the console to a format that I can use in the Duplex controller map XML files?
The midi dump for the first 4 buttons on the top row of the APC40 are:
MidiDevice: Akai APC40 received MIDI 90 35 7F
MidiDevice: Akai APC40 received MIDI 80 35 7F
MidiDevice: Akai APC40 received MIDI 91 35 7F
MidiDevice: Akai APC40 received MIDI 81 35 7F
MidiDevice: Akai APC40 received MIDI 92 35 7F
MidiDevice: Akai APC40 received MIDI 82 35 7F
MidiDevice: Akai APC40 received MIDI 93 35 7F
MidiDevice: Akai APC40 received MIDI 83 35 7F
How can I use these messages for Duplex? I’ve got a feeling that a lot of the troubles that I’m having are because I don’t understand the basics, which I’m still trying to dig through and learn from the snippets and other mapped controllers. If you could give me a nudge in the right direction with this, I’d appreciate it. Thanks in advance!
APC is tricky, because it’s buttons are organized in different channels, which is something Duplex currently does not support
We’ve been talking about this syntax for APC (and other devices that send on specific channels) :
“CC#18” <-- Normal CC message:
“CC#18|Ch2” <-- CC message on channel 2:
This way, the control-map could specify which channels to look for.
Does that make sense?
When I was hacking about, this is actually one of the syntaxes I guessed would work, so I think it makes sense for me. I’m bummed that I can’t set up my APC40 with Duplex… but with a little more practice I can still set it up using the Renoise API, correct? Is there a work-around that I can implement to still use Duplex with the APC40 in the meantime? Thanks so much for your help.
I’m afraid the lack of channels support is a showstopper ATM when it comes to Duplex support. The problem is, that when Duplex receives a message from the device, it tries to match it with one of the parameter values. But this will not work when the CC# is the same in multiple places (only with a different channel, which is not handled).
Btw: the new channel syntax should be fully optional - if you leave out the channel part, it should simply match “all channels”
+1 For channel support in Duplex .
I wanted to make Edirol M-16 DX support in Duplex, but there is the same problem with same CCs at different channels.
Bumping this topic, since this got mentioned both on tools.renoise.com as well as here:
The “pending” version of Duplex (v0.92) has full support for channels, which means that it should be possible to support both the APC40/20 and the Edirol M-16 DX. Someone might want to give it a shot, and write a control-map for either one of these devices?
Discussion of the upcoming release is located here
Here is a copy of the apc40.xml file I just put together for the layout. Not 100% yet as I am not sure how to;
Implement a horizontal slider (can I even?) for the crossfader
Get the actual button midi return codes that the controller sends to renoise
Some of the button numbers may be backwards
Sizes of most objects need tweaked
I cant test and fix until I figure out how to make .lua files that work but all 109 buttons, 10 sliders, and 17 knobs are in place and accounted for.
Fixed fader/slider naming and set crossfader orientation to horizontal.
Get the actual button midi return codes that the controller sends to Renoise and insert into map
Some of the buttons might display out of order
Sizes of some objects need to be tweaked
[quote=“spyderdyne, post:10, topic:29573”]
Fixed fader/slider naming and set crossfader orientation to horizontal.
Get the actual button midi return codes that the controller sends to Renoise and insert into map
Some of the buttons might display out of order
Sizes of some objects need to be tweaked
nice one spyderdyne, i’ve been checking this thread for quite some time to see if there’s been any progress with the APC… unfortunately i’m pretty helpless regarding the lua scripting. good luck!
Thanks. I will get back on this over the weekend. The .xml was pretty easy, but the midi settings in the .lua file should be a nice learning adventure since the APC40 has 8 freaking midi ports. Since I have a purely tech background I can figure some things out but honestly this is my first ever midi device so I don’t expect it to be too easy at first. If it works I will be sure to make a big deal about it of course.
I think I know how to get the midi return codes that are sent to Renoise from the controller, so it will be loads of fun to record all of those…
I think the devil still owes me a favor so hopefully we are a week or two away from this being a reality. Now if I can just figure out what Danoise is talking about…
Still not seeing how to get this data from Renoise for sure.
If I unplug all other midi devices, and set Renoise to MIDI DUMP, then start pressing buttons, the code displayed when I quit is the code for the specific buttons I dumped from right?
So if I push 6 buttons, is the code for the first one at the top or the bottom of the list of 6?
And I did read your release notes regarding the support regarding “button|channel” support. I think it is pretty straight forward but have not tried it out yet. Will be sure to post updates when I have them.
I am guessing that the APC transmit a note-on message when a button is pressed, and a note-off message when released (or perhaps a note-on with 0 as velocity)?
Edit: the first post by baze actually explains this!
Standard MIDI dictates that Note-on messages follow this pattern:
1st byte: 0x90 - 0x9F (channel number 1-16)
2nd byte: 0x00 - 0x7F (pitch)
3rd byte: 0x00 - 0x7F (velocity - 0 is interpreted as Note Off)
The idea is to make Duplex listen for specific combinations of these values, and this is where control-map values like “C#4|Ch2” come into the picture - much easier to work with than having a bunch of hexadecimal bytes. Note that the base octave for these values might need to be adjusted one upwards or downwards (it depends on the hardware)
Detecting button presses is the “easy part”, but it’s obviously an important step. Next one would be to send the right code for turning on the lights on the APC. This is a bit more tricky, as the APC has multiple colors to choose. We shouldn’t have to guess what those codes are - it’s information that should be present in the product manual somewhere?
Duplex has a concept called a color-space. Once the capabilities of the APC are clear (which MIDI codes control which color), it should be possible for me to write a simple device class for the APC that deal with colorspaces in a smart way - just like it’s done for the Launchpad and other devices
The APC is by far the most advanced controller yet to be supported by Duplex, so it’s not an easy task you have assigned to yourself. I recommend that we make this a collaborative effort: you keep the info flowing, create a working control-map, and I’ll take care of making the device class/configuration?
What do you mean by rectangle buttons? It’s possible to create the Duplex UIToggleButton in any size (spanning multiple physical buttons), but somehow I don’t think that’s what you want?
As for the Navigator, no problem - you simply specify “orientation = HORIZONTAL” as argument (see the monome128 mixer for an example)
OK, now I get it! Just like a screen is defined by it’s aspect (16:9, or 4:3), we could make something similar for buttons?
The small, rectangular buttons on the APC would then have something like a 2:1 aspect
Let me see if I I can squeeze this into the upcoming update
[Ooops, I have thrown away my previous post by mistake ]
Hey danoise…
APC20 has arrived here, but this seems not to be as easy as I thought before.
Indeed, it’s somewhat tricky.
[s]At first, when I tried to set APC20 to my mockup, a message like below appears.
I think this is due to my lack of knowledge about Duplex code.
Could you correct this?
*** .\Duplex/MidiDevice.lua:257: attempt to perform arithmetic on local 'octave_segment' (a string value)
*** stack traceback:
*** .\Duplex/MidiDevice.lua:257: in function 'extract_midi_note'
*** .\Duplex/Display.lua:248: in function 'set_parameter'
*** .\Duplex/Display.lua:189: in function 'update'
*** .\Duplex/Browser.lua:1596: in function 'on_idle'
*** .\Duplex/Browser.lua:134: in function 'on_idle'
*** main.lua:165: in function <163><br>
<br>```
[/s]<br>
[b][Edit][/b]<br>
Oh, this error message problem is solved. I inputted param values like "F-3|1". It should be "F-3|Ch1". <img src="https://files.renoise.com/forum/emoticons/default/wink.gif" class="bbc_emoticon" alt=";)"> <br>
[b][/Edit][/b]<br>
<br>
<br>
<br>
And I've updated the control-map in my mockup. I investigated and inputted note & CC numbers to it as much as possible.<br>
[s]But currently, the mockup does not react to signals from APC20 at all.[/s]<br>
[b][Edit][/b]<br>
I can see some reaction. But they are something wrong a bit. Hard to explain...(unexpected button blinks, etc) <img src="https://files.renoise.com/forum/emoticons/default/sad.gif" class="bbc_emoticon" alt=":("> <br>
Need more testing.<br>
[b][/Edit][/b]<br>
<br>
<br>
And I found the APC40's communication protocol pdf. (Well, actually there is no such detailed manual in APC20 <img src="https://files.renoise.com/forum/emoticons/default/wink.gif" class="bbc_emoticon" alt=";)"> )<br>
Although it is difficult to me, is it helpful to you?<br>
http://www.akaipro.com/extras/product/apc40/APC40_Communications_Protocol_rev_1.pdf</163>
If so, my next question is - what is the process of translating the Midi dump messages in the console to a format that I can use in the Duplex controller map XML files?
I’m bummed that I can’t set up my APC40 with Duplex… but with a little more practice I can still set it up using the Renoise API, correct? Is there a work-around that I can implement to still use Duplex with the APC40 in the meantime? Thanks so much for your help.
]