no continuous cc messages from midiin and ctlin

    May 19 2013 | 4:46 pm
    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.

    • May 22 2013 | 11:04 am
      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!!!
    • May 22 2013 | 11:11 am
      Ah ah!
      I think I've just found a route around this, maybe it will work for you Wound?
    • May 22 2013 | 5:05 pm
      Hm, how do you use this on Windows?
    • May 22 2013 | 5:28 pm
      ahh well there in lies the problem....this external is only for osx :(
      I'm not sure of a windows compatible version sorry.
    • May 22 2013 | 5:35 pm
      just found this thread:
      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!
    • May 22 2013 | 7:45 pm
      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.
    • May 23 2013 | 7:41 am
      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?
    • May 23 2013 | 8:40 am
      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)
    • May 23 2013 | 9:25 am
      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?
    • May 23 2013 | 10:24 am
      Thanks wetterberg, I will try this later.
      But according to this : its mainly for recording automation data, but hopefully it will work for maxforlive too.
    • May 23 2013 | 6:26 pm
      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:
      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.
    • May 23 2013 | 7:15 pm