Hm, how is this “record” mapped to the button - e.g., have you been using the native Renoise MIDI mapping methods or the Duplex Transport application ?
Also, did you select the QuNeo in the native MIDI preferences while mapping the QuNeo device through Duplex as well?
Yes, I’m trying to understand your setup
If you want to use the QuNeo with Duplex, you need to deselect it from the native MIDI input, or you will have doubled messages.
Note that if you want to use native MIDI mappings, this is not a problem - just check the “pass unhandled messages” option in Duplex to allow this.
Check if you are using the Duplex system at all - perhaps you are simply seeing native MIDI notes being sent to Renoise ?
Renoise will obviously respond to MIDI notes but for Duplex to do so, you need an application to receive and interpret those notes.
Three options exist: The first is that Duplex isn’t the one sending those notes - it is in fact the QuNeo as a native device.
The second is that Duplex is simply passing on messages - this is equal to connecting the QuNeo as a native MIDI device.
The third option is to configure the Keyboard application in Duplex. For something like the QuNeo, this application will at least need the “key_grid” mapping in order to work.
If you haven’t assigned anything to them, they will appear static (just like the pads). Try to add something like the Effect application and see what happens?
(it could be argued that the controls should in fact move when they receive a message. However, currently you need to assign an application before you’ll see them move).
If nothing seems to happen, try enabling MIDI dump from the Duplex tool menu to see what messages the QuNeo is sending.
General device troubleshooting is described in the Duplex manual, chapter 4 (direct link)
The bottom line: you can always send me a PM describing how the device should work, and I’ll try to assist you.
Thanks danoise, that is immensely helpful. I did check “Pass unhandled MIDI messages to Renoise” but I did not have it enabled as a native MIDI device. After unchecking “Pass unhandled MIDI messages” the mixer and transport buttons are working normally and they do not send MIDI notes. Neither do the pads. I am going to attempt to map the pads to Track/Pattern 1-4 on/off commands in the Matrix and see if I can get them to respond correctly, but I may end up mapping these through the Keyboard and just straight up MIDI mapping them. I’ll also map the rotary encoders to some effects and see if they respond as well. Does that make sense? If I can’t get it to work I’ll PM you my configs but I think I’m getting the hang of it!
edit: just got the pads working with the Matrix (via Duplex)! Awesome! Right now, they trigger patterns on/off but I don’t see any corresponding LED feedback on the actual Quneo. I will change the MIDI mappings and see if that makes a difference.
Cool, it’s always tricky when you are mapping an unsupported device - I’m glad there’s progress
AFAIK, kazakore pointed out the QuNeo is in fact quite special in this regard, and does things a little differently from every other MIDI device out there!
I will need to add special support then, a bit like how the monome works (outgoing communication is formatted differently from incoming).
Ok that is interesting. Sometimes the transport button LEDs respond and sometimes they do not. If I use the mouse to press play, for instance, the play button turns green while the song is playing, and turns off again when I press stop. Using the buttons still works but the LEDs don’t respond. I think I am going to try to map the rotary encoders to the pattern sequence / track selection in order to navigate the matrix to select which patterns are off/on.
Yep, that is a bit weird. But the good thing is that it means that Duplex is able to update the basic LED state without further modifications.
The buttons you have assigned, do they have a toggling behavior of their own?
If this is the case, you basically have “pushbutton” (lit while held) and “togglebutton” (toggle when pressed), and you’ll need to set the corresponding button type in the control-map.
If not, the “button” should suffice (button with no internal state) - but then, it’s kind of weird that it doesn’t just work.
You’re right, the default is set to “button” but I did try “togglebutton” and “pushbutton.” The first two seem to function identically but “pushbutton” sends on while pressed and off when released, so that is not ideal behavior for play/stop/record
I assume the pads default “button” mode should also give LED feedback for patterns? Changing button toggling didn’t seem to do anything (pushbutton mode turns patterns on/off when the button is pressed and released, so also not ideal). Thanks again for all your help danoise!
edit: I do get the proper feedback while using the interface with the mouse. The values appear correctly on the controller when adjusted with the mouse. But when physically pressing buttons which send MIDI note on/off values, the LEDs turn off until the parameter is changed with the mouse again. Does that make sense?
Alright, I have gone as far as I can. Most of the controls are working the way they seem like they should, and others do not. I’ve uploaded my config in this zip file and I included the Quneo preset for the editor. If anyone could provide any help it would be greatly appreciated, thanks! 3709 QuNeo.zip
Yes, we now have a candidate for a good, basic layout
As a non-QuNeo owner, I can of course just see the virtual version of the device, but I’ve randomly
clicked the various buttons and pulled sliders. All applications seems to respond like they should.
I can see that local LED feedback is enabled for all controls. In a perfect world, something like Duplex would replace the need for this -
however, this will have to wait until Duplex has full support for the QuNeo and the special way it does things.
One thing we can do to make the whole experience more intelligible, is to provide the device with a colorspace:
try this modified version of your files (I basically added a device class that has a colorspace with 128 levels of green and red)
To have more than just “on/off” makes a big difference, especially when controlling something like the Matrix
I suspect that the virtual and physical versions look different from one another, is this what you mean?
Or (more serious) is there a functional difference, e.g. a button that doesn’t fire or do something else than it’s supposed to?
The dials/encoders don’t navigate through patterns and tracks. I can’t seem to get them to work at all, actually. Other than that the controls work minus proper LED feedback. The pads don’t give any LED feedback at all, but I’ll try your updated layout with colorspaces and see what the results are.
It might be due to the fact that there has not been assigned a “location” to those controls? At least, that is what I could conclude from the editor.
And, “location” seems to be just another name for CC message
Ah, but all you will gain from my modifications is a the virtual device that represents the final state, as it could look once the remote LED control is in place.
But it’s still better than nothing, even if it means having to look at the screen once in a while
They are assigned to Locations (MIDI CC#) 6 and 7. CC#7 does seem to control navigating the tracks but the control is not really usable so I will try mapping them to something else. So, I guess I am unclear as to what needs to happen for the remote LED control. Otherwise I think it is probably functioning about as well as it can at this point with Duplex. This colorspace layout sure does make the interface on screen more intelligible though, so thank you for that.
Not at all, it’s just that I needed to make the necessary modifications - perhaps you could give it a spin now?
What I did was to invent a special attribute in the control-map that tell Duplex that it needs to output two messages for the pads (one for the red and one for the green color).
Then, once a pad change it’s value, the note message being sent is picked up by the QuNeo “driver” class which will instead send the red/green update.
Also, I modified your QuNeo preset a bit, the pads are now identical to the values that the QuNeo will expect and local LED display is completely turned off *
Having this turned off might, or might not be desirable - but in general the LED feedback Duplex provides should be sufficient. However, it’s not
technically possible to light up surrounding LEDs in the rotaries, this seems to be something exclusive to local LED display.
So, in order to test this you need to download this special QuNeo test edition of Duplex and load the supplied preset (quneopreset_new)
I’ve not yet touched the Rotaries but I know they have two modes of operation and have read their Direction mode sounds to operate a little strange.
Location will give you a CC value depending on your location around the rotary (unorthodoxly with 0 being top right iirc.)
Direction will send out a CC value depending on if you have moved your finger clockwise or anti-clockwise. I haven’t tested this myself by recording the incoming MIDI data (which Duplex can do for you) but there was a thread on Keith McMillian’s website claiming that the CC value increments up to maximum when moving clockwise but then instantly jumps to zero on an anti-clockwise rotation. This seems quite bizarre behaviour to me! Should probably be confirmed and checked that it is also intended mode of operation and not due to be changed/fixed in a firmware update.
Will download and check out these files when I have the time
The pad LEDs do light up now while using the mouse, but I still can’t get the hardware to send and receive proper messages. Pressing a pad turns off its LED but does not control pattern on/off anymore, but everything seems to function on the Duplex interface. The transport and mute buttons also turn off LEDs once the hardware button is pressed, until it is changed via the mouse, or a track is soloed and then unsoloed. Using the rotary dials does update the LEDs and navigate through patterns/tracks, but not in a way that makes any sense to me yet It seems strange that the pads stopped working to control the pattern matrix.
So, basically it can work in either absolute or relative mode, which makes sense for a LED based controller.
In relative mode, the QuNeo seem to be transmitting what Renoise refer to as “Relative bin offset” (see MIDI mappings),
However, endless rotaries are not supported in Duplex so we need to focus on the “location”, where the rotaries should transmit an absolute value.
Kazakore mentioned this thing about values starting from the top right corner. Could this have anything to do with it?
Also, try controlling some straight-forward parameter like volume, panning where it’s easier to tell what is going on
That is strange. I just checked, using a simple pure-data patch to emulate the QuNeo and the application responded just fine.
Have you tried enabling the MIDI-dump feature in Duplex, confirming that the messages being received by Renoise match the values we’d expect?
The lower four pads should send note messages with a numeric note value from 0, 2, 4 & 6 (in the QuNeo editor, that would be C-2, D-2, E-2 and F#-2
So, for instance when pressing the lower-left pad, the incoming message should be MIDI 90 0 79 (90 is note-on, 0 is note number and 79 velocity)
Really? The description I read (and tried to portray to you) I didn’t think sounded like that at all. But that could be due to a confusion by either myself or the user who posted on their forum. I’ll try and remember to take a MIDI Dump of using the rotaries in Relative mode some time soon to confirm…
Shame. How would you have going clockwise to take you to the last send and then back to Track1 then? Plus you will always get stuck at 0 or 127
Is it just Duplex doesn’t support it or it’s hard to script correctly? Navigation with the rotaries is something I was considering coding (up/down with one and track or column with the other.)
The rotaries in the Lua API themselves don’t go further than the min and max value which are float values ranging from 0.0 to 1.0.
You could however scale offsets going from 0.001 to 0.999 to the range of 0 to 127 and whenever the value on the rotary turns 1.0, the rotary is put back to position 0.001 and when the rotary hits 0.0, it is changed to 0.999. (The object range is based on float values so there are acutally a lot of decimals that go behind the comma)
There are always tricks to make something turn “infinite”. It just depends on what scaling model you apply and what you actually use on the scale that you translate the numbers to.
It’s mostly a matter of representation. The viewbuilder API doesn’t have such a control for us to script, so it’s not possible to represent visually.
Once we have something like that, the standard modes (relative bin offset, etc.) would of course need to be supported.
Edit: OK, what vV says is correct - it’s not that bad a workaround to have a rotary which simply move slowly between min/max. I’ll see what I can come up with
Nice idea about column navigation, btw. A ColumnSelector to complement the TrackSelector ?
So0rry, for the initial paragraph, which you have responded to vV, I meant specifically within Duplex. I know there are lots of ways it could be done yourself within the API (although I am yet to do anything that actually uses a CC value myself) such as comparing against previously received number to know if it went up or down and then repeated 0s or 127s being treated the same as a decrement/increment (as long as the digital knob continues to send out min/max value on turning once it meets the end of the range.)
Although I do have to again admit I am hardly even a Duplex initiate and I am assuming Urbster1 was referring to control from within Duplex and not native when he was talking about the issues he had…
I went ahead with support for relative dials in Duplex,
it’s very beta and experimental so any feedback would be appreciated
(download: see this post for a more recent version)
The feature is simple to use - apart from figuring out how to set up your controller (can’t help you there),
you need to add a “mode” attribute to a control-map parameter:
mode=“rel_7_signed” - Increase at [065 - 127], decrease at [001 - 063].
mode=“rel_7_signed2” - Increase at [001 - 063], decrease at [065 - 127].
mode=“rel_7_offset” - Increase at [065 - 127], decrease at [063 - 000].
mode=“rel_7_twos_comp” - Increase at [001 - 64], decrease at [127 - 065].
I’ve used the “rel_7_signed2” mode on my Remote SLMKII, seems to work flawlessly, but other devices/modes are untested.
Note also that this feature is only effective with 7bit MIDI controllers, so far.
–
@urbster1: So, perhaps one of these four modes will work for the QuNeo?
Check out the new QuNeo preset, btw. The only difference from the previous one is that I’ve enabled local LED feedback for the pads
It seems strange that the pads stopped working to control the pattern matrix.
