SvenVirtual
Hi,
please take a little time to read my concern!
I have a wish which is a little bit hard to explain, but I try to point to the main point in a few words:
I have a hardware which has an encoder (i can turn it endless clockwise and opposite - this is the hardware behaviour), but it is sending not "encoder Midi Values" but "Slider values". This is a stupid conflict - i know, but i think it could be solved by software.
I found out that there are 2 types of encoders on a hardware controller but only one type is implemented in VDJ. The other type should be implemented too. Imagine you have two controllers (in my case the Numark Omni Control and the Behringer X-Touch Mini). Both have encoders which you can turn endless clockwise and oppisite direction. So from users point of view you may think "oh cool - there are encoders", so you try to give the same actions in the mapping.xml files. But then you recognize that it doesn't work (In my case i gave them the action "adjust_cbg" to move manually the beatgrid). On the omni Control hardware this function works fine as expected, but not on the Behringer X-Touch Mini controller.
WHY?
And now comes the main point what i figured out:
The encoders on the Numark Omni Control are sending midi Values greater 0x00 when turning clockwise and values "lower" than 0x00 when turning in other direction. Example: turn it constant clockwise the sended Midi values are 0x01, 0x01, 0x01... now turn it faster, the corresponding Midi-Values are 0x02,0x02,0x02 ... again faster: 0x03,0x03,0x03 ... and so on. the same in the other direction: at first slow you get the values 0x7f, 0x7f, 0x7f ... now faster : sended values are 0x7e,0x7e,0x7e... and so on. This is correct - everything is OK and good.
But now the Behringer X-Touch Mini:
Turn it constant (endless) clockwise you are getting 0x01, 0x02 , 0x03, 0x04, 0x05,... 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f,
Now turn it (endless) in other direction, you're getting the values 0x7f, 0x7e, 0x7d, 0x7c,... ,0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ...
Do you see the main problem? - We have an element , which has the behaviour of an encoder BUT send values like a slider! A stupid conflict.
So it never will be possible to assign actions like 'adjust_cbg' or 'jogwheel' or something like that to these encoders!
By the way - i tried the 'encoder', 'fullencoder'.. element with different attributes in the device.xml. But nothing is working.
From the view of a normal user without deeper technical knowledge you'll never understand why not getting such encoders to work in VDJ. You only see Encoders on the hardware so you want them to get work and become desperate why it is not wirking.
So in summary:
My wish is, that e.g. an additional attribute (for the 'fullencoder'-Element) or a new element-Definition would be great to get ecoders which are stupidly sending "slider values" to work in VDJ as an encoder like expected. I think this additional implementation-option would give additional benefit for VDJ because then it can handle also such hardware elements.
I hope i described it in an understandable way.
By the way: I made a support ticket and had a long discussion with the supporter, but I think he didn't understand the main point. If you're interested i can send the message history to geht further information.
please take a little time to read my concern!
I have a wish which is a little bit hard to explain, but I try to point to the main point in a few words:
I have a hardware which has an encoder (i can turn it endless clockwise and opposite - this is the hardware behaviour), but it is sending not "encoder Midi Values" but "Slider values". This is a stupid conflict - i know, but i think it could be solved by software.
I found out that there are 2 types of encoders on a hardware controller but only one type is implemented in VDJ. The other type should be implemented too. Imagine you have two controllers (in my case the Numark Omni Control and the Behringer X-Touch Mini). Both have encoders which you can turn endless clockwise and oppisite direction. So from users point of view you may think "oh cool - there are encoders", so you try to give the same actions in the mapping.xml files. But then you recognize that it doesn't work (In my case i gave them the action "adjust_cbg" to move manually the beatgrid). On the omni Control hardware this function works fine as expected, but not on the Behringer X-Touch Mini controller.
WHY?
And now comes the main point what i figured out:
The encoders on the Numark Omni Control are sending midi Values greater 0x00 when turning clockwise and values "lower" than 0x00 when turning in other direction. Example: turn it constant clockwise the sended Midi values are 0x01, 0x01, 0x01... now turn it faster, the corresponding Midi-Values are 0x02,0x02,0x02 ... again faster: 0x03,0x03,0x03 ... and so on. the same in the other direction: at first slow you get the values 0x7f, 0x7f, 0x7f ... now faster : sended values are 0x7e,0x7e,0x7e... and so on. This is correct - everything is OK and good.
But now the Behringer X-Touch Mini:
Turn it constant (endless) clockwise you are getting 0x01, 0x02 , 0x03, 0x04, 0x05,... 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f,
Now turn it (endless) in other direction, you're getting the values 0x7f, 0x7e, 0x7d, 0x7c,... ,0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ...
Do you see the main problem? - We have an element , which has the behaviour of an encoder BUT send values like a slider! A stupid conflict.
So it never will be possible to assign actions like 'adjust_cbg' or 'jogwheel' or something like that to these encoders!
By the way - i tried the 'encoder', 'fullencoder'.. element with different attributes in the device.xml. But nothing is working.
From the view of a normal user without deeper technical knowledge you'll never understand why not getting such encoders to work in VDJ. You only see Encoders on the hardware so you want them to get work and become desperate why it is not wirking.
So in summary:
My wish is, that e.g. an additional attribute (for the 'fullencoder'-Element) or a new element-Definition would be great to get ecoders which are stupidly sending "slider values" to work in VDJ as an encoder like expected. I think this additional implementation-option would give additional benefit for VDJ because then it can handle also such hardware elements.
I hope i described it in an understandable way.
By the way: I made a support ticket and had a long discussion with the supporter, but I think he didn't understand the main point. If you're interested i can send the message history to geht further information.
Mensajes Mon 14 Aug 17 @ 9:16 am
PhantomDeejay
While I do understand what you mean and what you want, technically it's not that easy to implement, mostly because the program can't guess what the user wants to do, and the data send by the controller don't really help in that direction.
As a first step please try to define it as a slider (that's what hardware manufacturer had in mind in first place) and use the following code:
param_equal 0 ? adjust_cbg -0.01 : param_equal 1 ? adjust_cbg +0.01 : adjust_cbg
If that does the trick, then you can use the above pattern on any similar sliders you may have.
If not, we will try to investigate if there's anything that can be done to support this slider as a proper encoder, but we can't guarantee success.
As a first step please try to define it as a slider (that's what hardware manufacturer had in mind in first place) and use the following code:
param_equal 0 ? adjust_cbg -0.01 : param_equal 1 ? adjust_cbg +0.01 : adjust_cbg
If that does the trick, then you can use the above pattern on any similar sliders you may have.
If not, we will try to investigate if there's anything that can be done to support this slider as a proper encoder, but we can't guarantee success.
Mensajes Mon 21 Aug 17 @ 11:29 am
SvenVirtual
Hi and thanks for the reply,
unfortunately the script doesn't work.
You wrote: ..." the program can't guess what the user wants to do,".. that is absolutely correct you're totally right - the program never will know this. BUT excatly at this point there is my written proposal or wish from my last message.
An extra flag / property/ attribute or something like that for the definition of an encoder or fullencoder element (for example) in the device.xml would be the way to give excatly this information to the program how it should interprete the incoming midi value. And with this information it should be an easy way to make this "hardware"-encoder in the program work as an encoder and not as a slider.
I'm a software engineer and also writing / wrote programs for lots of Midi controller. Also for such controller with this stupid behavior. So in my opinion all necessary information are given to implement:
So in short: i think the following things could/should be done:
1. Define an extra attribute or field for the encoder or fullencoder element so that this behaviour can be definined / added in devices.xml -> respectively give this information to vdj.
2. In Program logic implement something like (said in words): "
- If (received Midi Message is from an encoder with the "special behavior" from point one)
AND
(actual 'ReceivedMidiValue minus last 'ReceivedMidiValue' minus is greater THAN zero)
THEN assigned action value has to be increased.
- If (received Midi Message is from an encoder with the "special behavior" from point one)
AND
(actual 'ReceivedMidiValue minus last 'ReceivedMidiValue' minus is lower THAN zero)
THEN assigned action value has to be decreased.
I hope to gave a better understanding or presence of the problem because i think that in future it may be possible that more controllers are existing with such conflictive hardware <-> software behaviour
unfortunately the script doesn't work.
You wrote: ..." the program can't guess what the user wants to do,".. that is absolutely correct you're totally right - the program never will know this. BUT excatly at this point there is my written proposal or wish from my last message.
An extra flag / property/ attribute or something like that for the definition of an encoder or fullencoder element (for example) in the device.xml would be the way to give excatly this information to the program how it should interprete the incoming midi value. And with this information it should be an easy way to make this "hardware"-encoder in the program work as an encoder and not as a slider.
I'm a software engineer and also writing / wrote programs for lots of Midi controller. Also for such controller with this stupid behavior. So in my opinion all necessary information are given to implement:
So in short: i think the following things could/should be done:
1. Define an extra attribute or field for the encoder or fullencoder element so that this behaviour can be definined / added in devices.xml -> respectively give this information to vdj.
2. In Program logic implement something like (said in words): "
- If (received Midi Message is from an encoder with the "special behavior" from point one)
AND
(actual 'ReceivedMidiValue minus last 'ReceivedMidiValue' minus is greater THAN zero)
THEN assigned action value has to be increased.
- If (received Midi Message is from an encoder with the "special behavior" from point one)
AND
(actual 'ReceivedMidiValue minus last 'ReceivedMidiValue' minus is lower THAN zero)
THEN assigned action value has to be decreased.
I hope to gave a better understanding or presence of the problem because i think that in future it may be possible that more controllers are existing with such conflictive hardware <-> software behaviour
Mensajes Thu 24 Aug 17 @ 4:59 pm
Adion
<encoder> is for encoders that just send relative data, while <fullencoder> is for encoders that count up or down each time you move them.
So if fullencoder isn't working, it's probably useful to show the full definition of this element you tried to use, as well as the mapping that you tried to assign to it.
Edit: If, as you shown in the example, it is still limited to 0x00 and 0x7F and doesn't overflow, it will still be of very limited use as an endless encoder, since it's not possible to actually use it endlessly (you'd have to move it back to the center while disabling the action every time somehow)
Edit2: If it actually does repeat the '0' each time you move it left beyond the beginning, then it would indeed be possible to solve it in software.
It is indeed not supported in the definition currently, but you could work around it as follows:
Assign both an <slider> and <fullencoder> for this encoder, but give them different names.
In the mapping, for the fullencoder you can just use the mapping such as adjust_cbg normally. This will work as long as the values reported are in-between 0x0 and 0x7f
For the slider, map it like param_equal 0 ? adjust_cbg -0.01 : param_equal 1 ? adjust_cbg +0.01
The slider would then work in the cases where you have reached the limits of the encoder.
So if fullencoder isn't working, it's probably useful to show the full definition of this element you tried to use, as well as the mapping that you tried to assign to it.
Edit: If, as you shown in the example, it is still limited to 0x00 and 0x7F and doesn't overflow, it will still be of very limited use as an endless encoder, since it's not possible to actually use it endlessly (you'd have to move it back to the center while disabling the action every time somehow)
Edit2: If it actually does repeat the '0' each time you move it left beyond the beginning, then it would indeed be possible to solve it in software.
It is indeed not supported in the definition currently, but you could work around it as follows:
Assign both an <slider> and <fullencoder> for this encoder, but give them different names.
In the mapping, for the fullencoder you can just use the mapping such as adjust_cbg normally. This will work as long as the values reported are in-between 0x0 and 0x7f
For the slider, map it like param_equal 0 ? adjust_cbg -0.01 : param_equal 1 ? adjust_cbg +0.01
The slider would then work in the cases where you have reached the limits of the encoder.
Mensajes Thu 24 Aug 17 @ 5:42 pm
SvenVirtual
Hi adion,
thanks for the post and te solution. It is working. As you wrote: the main trick is to define it as a Slider AND an encoder. The proposed mappings are working very well.! Wow. Cool workaround solution. Thanks again! In this case i learned that an hardware emelent can be defined twice. Sorry I don't know it till now.
Meanwhile i programmed a solution (small .exe) which grabs the Midi-In Data, translates in this case the absolute values from this "SlidEncoder" into relative values and give these computed Midi Data then to VDJ. It is working also fine.
So at the end: There are two cool solutions for this problem. Thanks again.
As i wrote it in an earlier post it is a wish for future to extend the definition of the "device.xml" or so, so that such elements can be defined with on entry.
Thanks Sven :-)
thanks for the post and te solution. It is working. As you wrote: the main trick is to define it as a Slider AND an encoder. The proposed mappings are working very well.! Wow. Cool workaround solution. Thanks again! In this case i learned that an hardware emelent can be defined twice. Sorry I don't know it till now.
Meanwhile i programmed a solution (small .exe) which grabs the Midi-In Data, translates in this case the absolute values from this "SlidEncoder" into relative values and give these computed Midi Data then to VDJ. It is working also fine.
So at the end: There are two cool solutions for this problem. Thanks again.
As i wrote it in an earlier post it is a wish for future to extend the definition of the "device.xml" or so, so that such elements can be defined with on entry.
Thanks Sven :-)
Mensajes Wed 06 Sep 17 @ 11:55 am