Need Help Setting Up Duplex And Apc40

@satobox: the first thing I noticed from reading the manual is that the APC has something called “generic mode”, which is the default when turning the machine on.
This is probably NOT what you want, as the APC then has a lot of logic of it’s own. For example, some of the buttons can only be turned on one at the time:

Basically, the APC should be as “dumb” as possible, because then we can better control it :slight_smile:
From the descriptions, it seems that the most useful mode would be “mode 1”:

The APC needs to receive an initial message to set this mode, I’m sure there’s help somewhere on the internet on how to do this?

The manual is also very helpful in telling us which codes are needed to set the various colors, but to begin with, these should be enough:

Note velocity 0 = OFF
Note velocity 127 = GREEN

Once the rest is working we can look at it’s colorspace, which would be {2,2,0} - two levels of green and red, a bit like the launchpad.

It was (wrongly) put like that in the first version of the documentation. Nice that you discovered how to do it anyway :)

Maybe this description help us?
Quote from
_Framework Introduction to the Framework Classes Part 2

Also this page introduces APC40-map image. :) (note numbers need to be inputted 1 octave up in Renoise)

I updated the mockup again.(added APC40’s mapping and both bmp images)
Attachment 1485 not found.

Try the mockup. it’s not good enough yet (to be honest, it’s very strange behavior), but it should react in some parts. :rolleyes:
Place it here:
C:\Users\YourName\AppData\Roaming\Renoise\V2.6.0\Scripts\Tools\com.renoise.Duplex.xrnx\Duplex\Controllers

@satobox: here’s some code you can try adding to APC20.lua?

  
  
  
class "APC20" (MidiDevice)  
  
function APC20:__init(display_name, message_stream, port_in, port_out)  
 TRACE("APC20:__init", display_name, message_stream, port_in, port_out)  
  
 MidiDevice.__init(self, display_name, message_stream, port_in, port_out)  
  
 self.colorspace = {1, 1, 1}  
  
end  
  
--   
  
  
function APC20:point_to_value(pt,maximum,minimum,ceiling)  
 TRACE("APC20:point_to_value()",pt,maximum,minimum,ceiling)  
  
 local value  
  
 if (type(pt.val) == "boolean") then  
 -- buttons  
 local color = self:quantize_color(pt.color)  
 value = (color[1]==0xff) and maximum or minimum  
 else  
 -- faders  
 value = (pt.val * (1 / ceiling)) * maximum  
  
 end  
  
 return value  
  
end  
  
  

Edit: the “point_to_value” takes care of converting the RGB colors from the virtual control surface into the special codes that the device can display - this one is just monochrome, we need to come up with a more sophisticated version later on…

Hmmm, I tried your new code, but it seems that there is not big change… :unsure: (Ah, indeed the button looks has changed a bit)

First, maybe we should find the method to change to the “Ableton mode 1”.
Because the behavior of the “CLIP LAUNCH” buttons are somewhat strange by default.
If I press a CLIP LAUNCH button, a matrix slot will be in a mute state only for a moment, and it returns to the original state immediately. It is like an action as if I was pressing the button twice. So I cannot mute a matrix slot.
I want to confirm the difference in the action at the case of using the Ableton mode 1.

Can’t the signal for changing the mode be sent from APC20 class? I cannot find such mode change method on the hardware…

The xrnx code repository has a code snippet that you can use for sending the sysex message from within Renoise.
http://code.google.com/p/xrnx/source/browse/trunk/Snippets/Midi.lua?r=876

-- midi output   
  
  
local outputs = renoise.Midi.available_output_devices()  
  
if not table.is_empty(outputs) then  
 local device_name = outputs[1]  
 midi_device = renoise.Midi.create_output_device(device_name)  
  
 -- note on  
 midi_device:send {0x90, 0x10, 0x7F}  
 -- sysex (MMC start)  
 midi_device:send {0xF0, 0x7F, 0x00, 0x06, 0x02, 0xF7}  
  
 -- no longer need the device...  
 midi_device:close()   
end  
  

Basically, create a new document in the scripting console, paste the contents of the code snippet. Then replace the “output[1]” with the name of the APC midi port, and replace the message part of “sysex (MMC start)” with the code that the APC manual states should be used for entering mode 1

The sysex message structure works like this:

0xF0 - Enter sysex mode
… any number of data bytes inbetween the initial 0xF0 and the final 0xF7
0xF7 - Exit sysex mode

And yes, if this is working it can easily be integrated into the APC class…

Mmmm, sorry for a very noob question, but I’m quite poor at such task… :wacko:

According to the APC40 COMMUNICATIONS PROTOCOL pdf, page 8,
I cannot understand these Sysex values:

  • 9 PC application Software version major
  • 10 PC application Software version minor
  • 11 PC Application Software bug-fix level

So I ignore these value.

Is this OK??


– midi output

local outputs = renoise.Midi.available_output_devices()

if not table.is_empty(outputs) then
local device_name = Akai APC20
midi_device = renoise.Midi.create_output_device(device_name)

– note on
midi_device:send {0x90, 0x10, 0x7F}
– sysex (MMC start)
midi_device:send {0xF0, 0x47, 0x7F, 0x7B, 0x60, 0x00, 0x04, 0x41, 0xF7}

– no longer need the device…
midi_device:close()
end


And then, how can I transmit this code??? :unsure:

I believe this is all you need:

“0x41” is the mode, according to the manual (page 6). If the device is correctly set, the track select buttons should no longer act as “radio buttons”?

Sorry again :( , how should I treat this code?? Paste it into APC20.lua??

And make sure that the device name (Akai APC20) is correct. If you do enter this text into the console

rprint(renoise.Midi.available_output_devices())

…then you should get a list of the currently connected devices, so you can copy-paste from that.

Probably, for you, my reply will be irritated. But I’m not a programmer, so I am really confused about such task, sorry.

If I’m not wrong something, the result does not change at all. Radio buttons doesn’t change.

What I did is not wrong? :huh:
1486 apc20-mode1.png

Hmm, I get device configuration contains unknown application class: ‘Navigator’, when I try to open it with duplex.

No, don’t get me wrong - I’m just busy at work so I don’t always have time for a proper reply :slight_smile:

You forgot to tell me if you actually created a new file in the scripting console? Judging from the image, it doesn’t look like it.
You can create a new file by selecting “new” in the file menu. Paste the code from above, and save the file next to the “TestPad.lua” file.
Then, execute the code by hitting the small button in the corner -> “Execute”.

This should send the sysex code to the APC, which should enable the mode.

Notice that I wrote should two times? Because, I don’t have an APC and I only briefly scanned the manual. I’m just guessing how the APC might react to the “mode change”, the track select buttons should work differently then. I’m sure someone else who’s using the APC can confirm that this is how it’s supposed to work?

Satobox is using the bleeding-edge (0.95) version, which you can get here. The Navigator is part of that update.

OK I see. Thanks for your effort. Let’s go without haste. :)

Mmmm, I’ve tried this, but it seems nothing happen. Even if I hit the Execute button, nothing is displayed on the Terminal (I checked the “Dump MIDI” in Duplex). Is this correct?? I’m worry that I’m wrong at something fundamental…

And, I’ve tried to explain the problems by making movie. Though I talked very bad english in it :smashed: , maybe you can see easily that there are many problems on APC20.

http://reg.s63.xrea.com/gomi/APC20-problems.mp4

Hey,
Today I can confirm that I can send needed Sysex for changing APC20-mode, by using MIDI-OX.
Probably, we should send all Sysex values which are described in the APC40 COMMUNICATIONS PROTOCOL pdf.

  • 9 PC application Software version major
  • 10 PC application Software version minor
  • 11 PC Application Software bug-fix level

I specified those values as the trial, ie [8, 2, 1] = Ableton’s version number.
Seemingly, a version number will be OK even if it is not so exact.
So, I tried to send;

0xF0, 0x47, 0x7F, 0x7B, 0x60, 0x00, 0x04, 0x41, 0x08, 0x02, 0x01, 0xF7  

from MIDI-OX to APC20, then, bingo!!
I can confirm APC20 is changed to mode1. :yeah:

(Probably the values for APC40 are):

0xF0, 0x47, 0x7F, 0x73, 0x60, 0x00, 0x04, 0x41, 0x08, 0x02, 0x01, 0xF7  

But…, when I tried it in Renoise as well, I cannot sucsses it.
The action of APC20 becomes strange just as it connects with Renoise. :(
Yet I don’t know why…

##############################

And, maybe I should post another topic though,
I tried to send the Sysex from Renoise to MIDI-OX through MIDI Yoke, to confirm Renoise can send Sysex signal correctly.
Then the message appears on the Terminal;

  
*** std::logic_error: 'trying to open a non existing MIDI device.'  
*** stack traceback:  
*** [C]: in function 'create_output_device'  
*** test-sysex.lua:2: in main chunk  
  

test-sysex.lua is like this:

  
local device_name = "Out To MIDI Yoke: 1"  
midi_device = renoise.Midi.create_output_device(device_name)  
midi_device:send {0xF0, 0x47, 0x7F, 0x7B, 0x60, 0x00, 0x04, 0x41, 0x08, 0x02, 0x01, 0xF7}  
midi_device:close()  
  

Why I cannot open MIDI Yoke?? :unsure:

It’s a good idea to copy-paste those device names - I just checked, and the device name has two spaces before the “1”

Ohhh, thanx! I’ve confirmed that Renoise can send Sysex correctly.
I tried it with connecting Renoise to APC20 again, then surely APC20 reacts to it.

But the problem is, the APC’s behavior is quite different from when I tried it with MIDI-OX & APC20.
APC20 behaves still strangely like my video above.

Hmmm, it’s a mystery.
Doesn’t Duplex send something wrong signal to APC20? :huh:

I just watched the video, thanks.

The first thing I noticed is that it seems like buttons are never released. The Matrix acts like if every button you press is held indefinitely. This is definitely something that should be investigated.
Since I don’t have an APC, I’ll have to think about a good testing scenario for this - do you have a more recent control-map for the APC20/40 than the one you already shared?

Now I’ve adjusted both control-map to mode-1.
I confirmed that the transport buttons react, however, they behaved as always pushed twice.

Anyway here is the updated mockup.
1493 APC-mockup-05.zip

Ah, and additionally, can you embed the mode changing Sysex in APC20.lua?? :huh:

Thanks! Let me just investigate why the release events are not fired. I should read the whole APC manual as well, to learn why those codes are needed in the first place (ableton version number, wtf?). I’ll be back in a day or two