no continuous cc messages from midiin and ctlin

May 19, 2013 at 9:46am

no continuous cc messages from midiin and ctlin

I am working on a M4L patch that allows for dynamic precision control of any Live device parameter, that overcomes the limitations of 7-bit Midi on the one hand and the unhandy range of 16383 values with fixed precision rotary encoders in 14-bit mode on the other. But what I need is continuous input for relative CC message values and while Max standalone Midi driver seems to deliver that, Max 4 Live seems to filter them out, probably because it does not recognize that repeatedly sending the same message in relative mode means a change while in absolute mode it would not. This is true for “midiin” and “ctlin”

Example: Turning a controller slowly up from 0 gives you the following series of values:
Absolute: 1, 2, 3, 4, 5 ,6
Relative: 1, 1, 1, 1, 1, 1  (well, actual coding depends on implementation of relative values)

In Max “midiin” and “ctlin” do send each and every “1″. M4L on the other hand only sends the first “1″ and swallows the following ones, while I see on the Midi-Input-Signal in Live’s upper-right corner, that the messages are received. :(

Motivation: I’m using a Novation 49SL MkII controller keyboard. It’s rotary encoders can be set up to send CC messages realizing 14 bit absolute values using two CCs. One would expect babyskin smooth controller input with 14-bit – and in fact, you really get that. But the rotary encoder still only counts 1 up or 1 down approximately 50 times per revolution of the knob. That makes more than 327 turns to go from the lower end to the upper end of the parameter range. How would you need to move that cut-off from 50Hz to 10kHz? Get it? It’s no use.

What we really need is a high resolution controller with fixed upper and lower bounds. This seems to be a technical problem because of noise. It’s the domain of analog devices (Man, do I love my Monotron).

I wan’t to simulate that using dynamic relative CC input. That means turning the knob faster results in bigger relative values. The SL MkII realizes this in modes (DispType) “APOT” and “Rel2″. I have managed to decode the dynamic APOT messages in live and translate them to values of the kind 1,6,12,20,2,-1,-4, and so on. By accumulating the values and scaling the min and max range to the parameter range, I basically get what I want. But when I turn the knob at constant speed, Live swallows all equal CC messages in a series but the first one and nothing get’s accumulated. The controller sends all the time, Live receives, but nothing is output by “midiin” or “ctlin”. No message, no bang. Even a bang would be enough for a start.

Max stand-alone does it.

Does anyone know, how to work around this in M4L?

Cheers
Henning

EDIT: I am aware of the relative midi input modes in Live which are recognized when you activate Midi-Learn. But these do not increase the parameter precision. The accumulated input values stay in the range of 0-127 of a midi controller. That’s why I’m working on a patch that reads the relative values so I can use my own cumulation formula with arbitrary precision.

#249833
May 22, 2013 at 4:04am

Ahh so it wasn’t me going mad the other evening when testing a patch!

Yes I have just found out the same issues as you when using encoders, max for live does NOT see the continuous cc messages sent. Only the first ’1′ or ’127′ when turning the encoder either forwards or backwards respectively.

Do you know of a work around for this?

As at the moment when you turn my encoders quickly/hard they go to ’2′ or ’126′ which is how I’m getting max for live to see them.

Very annoying!!!

#250232
May 22, 2013 at 4:11am

Ah ah!

I think I’ve just found a route around this, maybe it will work for you Wound?

http://cycling74.com/toolbox/midi-inout-for-maxforlive/

Steve

#250233
May 22, 2013 at 10:05am

Hm, how do you use this on Windows?

#250272
May 22, 2013 at 10:28am

ahh well there in lies the problem….this external is only for osx :(

I’m not sure of a windows compatible version sorry.

#250273
May 22, 2013 at 10:35am

just found this thread:

http://cycling74.com/forums/topic/using-multiple-midi-devices/

at the bottom there is a link to two different java versions. I’m not on a PC but if it works for you please report back!

Thanks

#250274
May 22, 2013 at 12:45pm

if i understand the problem right, all you have to do is to regenerate the relative value yourself.

[pak 0 0]
|
[unpack 0 0]

for example should be already enough for your example above with the two incoming streams of controller values.

-110

#250300
May 23, 2013 at 12:41am

Roman,

I’m not sure if I understand you right. From what input can the relative value be regenerated? “Relative” means the change of an absolute value during a time step. So the relative value would have to be the difference of two consequtive absulte messages of the same CC. The problem is, that absolute values are bounded (0-127), so if I use the dynamic mode of my encoder, fast movements would be cut at the lower and uper end of the value range. This leads to jumps in the cumulated curve. Apart from that, this kind of calculation creates a lag in time. That is, why I would like to use the relative mode of my encoders.

Thanks for your replies. I still have to deepen the Java checks. Have not found the time, yet. Expect me to reply about this soon.

Any other ideas? Ableton folks? Cycling 74 folks?

Woung

#250385
May 23, 2013 at 1:40am

i thought the two types of data are coming in both in parallel.
in this case you could have been use every incoming absolute value to retrigger the last recognized relative value (because you know that if there is no value, it is because it is the same than the previous one)

#250390
May 23, 2013 at 2:25am

so it sounds like overly zealous midi filtering on Lives part; repeated values get stripped completely.

try doing an options.txt with the -ThinningAggressiveness=0.0 or something? That might be it?

#250393
May 23, 2013 at 3:24am

Thanks wetterberg, I will try this later.

But according to this : https://www.ableton.com/en/articles/optionstxt-file-live/
its mainly for recording automation data, but hopefully it will work for maxforlive too.

#250403
May 23, 2013 at 11:26am

I have tried the whole thing with ThinningAggressiveness set to 0.0, but unfortunately it did not help. I have recorded a tiny screencast showing the problem: http://www.youtube.com/watch?v=mA4WzevCqWc

I guess only Ableton Developers can fix this by allowing CC messages of the same value pass through their filters. Another “ctlrelin” patcher would be nice for the purpose, because maybe someone else relies on the filtering behavior.

Still no time to try the Java patchers thoroughly. At a first shot, the JMidi patchers could not connect to my Keyboard. It was shown in the drop down box, but no messages were received. I have Java installed, even the JDK (since I’m a software dev) but the patch did not do anything.

#250473
May 23, 2013 at 12:15pm
#250482

You must be logged in to reply to this topic.