This post has been edited - there is no bug, the problem was host - related

Below the line follows the original content of the post
_____________________________________________________________________

First of all don't get me wrong - the added CC mapping features for "mutes" and the steps is a marvellous new addition and I perfectly understand that as such (new additions) various mishappenings can happen. So this post is not intended in any way to devalue these new features.....

Ok....so.....

m Tonic version 3.1 32 bit - windows 7 OS
host - Ableton Live (not important really)
controllers tested - Lemur (iOS), BCR2000, Korg Nano Kontrol

Steps to reproduce:

map a midi controller's button with LED feedback to one of the channel mute buttons or to one of the steps using CC command - midi message. Also take care to have working bi-directional feedback (this depends on the host)

we have two cases, according to how controllers send CC data from buttons:

case 1:
the controller's button is of "push button" nature (momentary) - it sends value 127 when pressed, 0 when released - the LED is lit when we press the button, switches off when we release it

expected behavior: the channel mute button lights up when we press the button, un-mutes when we release it.

what happens: the expected, no problem but this is not what we want - we could have that functionality with midi notes already - we want case2

case 2:
the controller's button is of "toggle - switch" nature - we press it, it sends 127 value and the LED switches on, we release it, nothing happens, we press it again, it sends a 0 value and the LED switches of

expected behavior: we press the button, the channel mute lights up, we release it nothing changes, we press it again, and the channel mute un-mutes

what happens: the expected, no problem

NOW.....switch presets until you "bump" into a preset where the mapped channel mute is already saved as muted. Expected bi-directional feedback works correctly - the LED on our controller lights up

we press the mute button on our controller to un-mute the channel

NOT expected behavior: the channel mute is not unmuted, while on our controller the LED lights up (so the 0 value has been sent) We press the button on our controller again - LED lights up and is now in "sync" with the mute button that had stayed muted. Now, when we press our controller button again, the channel mute is conrrectly unmuted
From that moment on, all the rest of button work correctly.

I spent all day today to make sure this is not user error - Im fairly knowledgeable with midi and this is indeed a bug so please bother to look at it at some point. The exact same problem also happens with the steps in the lane. Any button which is saved "pressed" correctly sends feedback to the connected controller but seems to respond only to a on value (127) and then to off value (0).

Analysing: for as long as the software receives 0 value the channel refuses to be unmuted. We have to send a 127 value and then send 0 again, which makes the channel mute button operational again.
On a discussion on another topic, we talked about the Launchpad, but the Launchpad sends note on-off messages not CC messages so the bug cannot be observed. ANY controller with CC buttons with "switch mode" will immediately expose the problem as long as you bother to also have bi-directional feedback working. I tried with 3 controllers today all capable of this functionality - Lemur, BCR 2000, Korg Nano Kontrol. This is not by any means a miscompatibility between controllers' modes. One could argue that the feature is only compatible with push buttons (127 when pressed, 0 when released) but this can already be achieved with midi notes for the mutes and for the steps it doesnt really make sense.

Again, thanks for this marvellous new additions which open great new possibilities - if you need any further technical details, testing, etc etc I can happily provide it

Thanks for your attention! ;)

This is so weird. I wish I could understand what is happening here. I can assure you that I have tested this, and did again today. Launchpad yes, but not with notes, with CC values (via Automap).

Microtonic listens to absolute CC values, so if the controller sends 0 that's always going to mean mute off. If it sends 127 that's always going to be mute on. The CC values Microtonic sends will not change any state inside Microtonic. So if we load a preset where mute changes, that will be a CC message out to the controller. Next CC message from the controller will be treated just like any other. E.g. < 64 is off, >= 64 is on.

I think you should be able to verify that Microtonic behaves no differently if you turn on and off "Knobs and buttons send MIDI CC" or even disconnect the MIDI out to your controller. Microtonic simply does not care or know what the MIDI controller has received, or which state it is in. All it cares about is the absolute CC value it receives from the controller. It is the MIDI controllers responsibility to handle messsages sent back from Microtonic, change its LED and internal state, so that the next CC value sent from the controller will be different from what Microtonic just sent.

Now I just checked this with my MPK mini (which I have at home), and it simply doesn't work with Microtonic. First, the CC pads send value 0 to 127 depending on velocity (even in toggle mode, which toggles from 0->vel->0 again!). You don't want that. But more importantly, MPK mini only uses MIDI input to change the button lights, it doesn't change internal state. In other words, if MPK mini send CC value 127 to Microtonic and Microtonic then sends CC value 0 to the MPK mini, the MPK mini turns off it's light correctly, but next press will still toggle from 127 to 0 (i.e. toggle from the last sent value, not from the last received value).

This won't ever work with Microtonic.

Are you 100% positive that this is not happening with your controllers as well? Cause that type of behavior is simply not supported (it would be very difficult to support correctly).

Could Live interfere? Did you try another host? I ran a simply VSTHost today at work and it worked fine.

Here is another fun way to test this. Two Microtonic's inside Live. Microtonic #2 receives MIDI from Microtonic #1 and Microtonic #1 receives MIDI from Microtonic #2. Both have the exact same MIDI configuration (CC's mapped for mutes, and first channel's pattern editor). Now, any changes to mutes (or pattern editor) in either is replicated in the other Microtonic. Also works when loading presets etc...

Here is the Live project: TwoMTsCCSynced Project.zip(69.3kB, 710 downloads)

Wow, thank you very much for your attention!

I understand what you are saying about the MPK and yes, it makes sense that such a thing wouldnt work. What has confused me the most is the fact that it does this only for the first button that I happen to press after loading a preset. All the next buttons of the same group work fine.

So, for example if I load a preset and 3 mute buttons have been saved "muted" - the first I try to control behaves as I described above. The next two will work correctly.

Then, if some steps were saved enabled, the first one I try to disable behaves as above, the next correctly. This really has me confused, more so that by your description Im sure you have understood what Im noticing and you cannot reproduce it.

I will keep on testing tomorrow to see if I miss anything obvious and will report back! The truth is I didnt try with a different host, and its possible that this maybe the culprit.

Thanks again!

- Softcore wrote:
Softcore, on 21 May 2013 - 02:41 AM, said:
I understand what you are saying about the MPK and yes, it makes sense that such a thing wouldnt work. What has confused me the most is the fact that it does this only for the first button that I happen to press after loading a preset. All the next buttons of the same group work fine.

That is strange indeed. I won't have time to get into the office today or tomorrow. I have loads of controllers there, so I'll do some more testing with Live later this week.

Ok! I made some further tests today and yes you were right, its not Microtonic's fault - once again, something is fishy with the way Ableton Live handles midi messages.....

In detail:

I used the same controllers, the same mappings and the same procedures on another host and I could not reproduce the problem

Furthermore, I did one more test. I disabled the bi-directional communication from Live TO mTonic, and left one "mute" button on my controller on. I then proceeded to change presets until I find one where the button IN mTonic was on - so, apparently it was in sync with my controller (even though no feedback is applied). Upon pressing my controller button, it repeateadly worked with no problems. This test, tells me that obviously, something fishy is going on when Ableton Live sends the feedback back into the controller - even though its LED is lit........something goes wrong with its internal state - OR there is some weird mumbo jumbo going on coupled with that "return to arrangement" button of Live that lights up.

Eithercase, I confirm mTonic works as intended on a different host - so I'll have to find a workaround for the issue. Thanks for checking this out, I will edit the topic title to "solved".

- Softcore wrote:
Softcore, on 21 May 2013 - 6:35 PM, said:
Eithercase, I confirm mTonic works as intended on a different host - so I'll have to find a workaround for the issue. Thanks for checking this out, I will edit the topic title to "solved".

Really happy to hear this, and I appreciate all the effort you made investigating this. I'm going to do some tests with Live myself and if I find something I have good connections with the developers at Ableton.

Ok an update on this!

Apparently, Ableton Live has a "hidden" function where it filters out incoming midi messages that do not actually "change" a value. This means that if a CC value is 0, Ableton Live will ignore all subsequent 0s of that value. So when a mute button (considered by default to be 0 as a default CC value) lights up from -bi-directional feedback straight from a plug in, Ableton Live still waits for a 127 to pick up that button.

There are 2 relevant options to change this behavior in a text file for Ableton Live:
-MidiEventThinning

-NoMidiEventFiltering

I tried both, but to no avail.....

Although I'll give it the benefit of doubt because Im tired right now, I'll have a look tomorrow.

Im posting this as a future reference for any other member having the same problems.

Here's a source of what Im saying:

https://forum.ableton.com/viewtopic.php?f=4&t=177825&start=15