MIDI Learn inverse

parityflux · Unread post by **parityflux** » 11 Apr 2015, 05:11

I'm trying to map a controller button to the mute button on a send to another rack. The send is the standard HH one where there's a gain slider, an M button, a pre button and an S button. I have it basically working but my hardware controller lights up when it is muted. I want it to light up when it is not muted. I tried to use the inverse function on the remote tab, but it doesn't seem to do anything at all. I don't think my controller will flip it either. It seems like "inverse" is what I need.

nay-seven · Unread post by **nay-seven** » 13 Apr 2015, 13:19

what kind of message is sending ?
note ON ?
have you try to change manually to note Off in the setting panel of the object ?

i will check that inverse feature

parityflux · Unread post by **parityflux** » 18 Apr 2015, 17:31

I tried manually changing it to NOTE OFF and it didn't work at all. I also tried learning NOTE OFF. I also tried several permutations of the mackie control and motorized (just wishful thinking). No go. I attached a screen shot with the MIDI messages traced.

The second message (out) is from my MIDI device patch in which I change all NOTE ON velocities from 64 to 127.

nay-seven · Unread post by **nay-seven** » 18 Apr 2015, 18:21

ok, so the inverse function is more for fader currently maybe it's can be changed

Waiting for this , I've try your question with a launchpad mini and here a solution:
you create your midi learn but don't use the motorized feature
you create this patch (with your pad as input and as output midi device in the rack)

of course you can filter the notes you want inverse before,
i've test with the LP and this way you can choose the color of your pad, here the velocity of 14 give me a red color

lgbtten · Unread post by **lgbtten** » 21 Apr 2015, 09:52

Im trying to assign the midi MODULATION wheel to this volume/level knob using "Learn MIDI CC automation". It does assign and work

-------------------------------------------
[sub]etui samsung galaxy s6[/sub] [sub]coque samsung galaxy s6[/sub]

parityflux · Unread post by **parityflux** » 22 Apr 2015, 06:12

nay-seven,
Sorry I didn't see this earlier. For some reason I did not get an email about the posting (I must have gotten unsubscribed somehow).

Thanks for the suggestion. It is closer. I had to removed the pipe that goes from the A=B Out to the Create. I used the out from the 0 to 1 instead to trigger the Create. It's not working in an inverse way though.

Unfortunately I have two MIDI devices going into this rack, and I was using MIDI busses to split them, but something isn't right with the MIDI busses. I can't connected to an existing one anymore. It's really weird. I'm on 2.0.067b right now. Maybe I'll update it to see if being able to create them by dragging out a pipe appears again.

It's funny, your post is actually helping me with me earlier issue regarding changing the button color via velocity:
http://www.sensomusic.com/forums/viewtopic.php?id=4819 Point #2

I have fantasies about programming a module to better handle the Livid CNTRLR.

parityflux · Unread post by **parityflux** » 22 Apr 2015, 06:43

Nevermind about the busses. I created a new one and was able to find it.

So, I'm at:

It's still not inverting. When the send's mute is on (red), the button lights up; I want to turn off the pad light when muted. Actually, wait, MIDI learn won't work on the button anymore, because my device gets sent right to a bus to keep it separate from my keyboard controller. Dang it. I might have to go back to splitting MIDI by channel. The MIDI inputs/outputs continually give me grief in this program. It's freakin' painful. I know there are solid reasons behind it, but it makes things rough.

ceasless · Unread post by **ceasless** » 22 Apr 2015, 10:27

Yes, it is still unclear to me as to why we cannot get a 'device' filter on the midi filter module.

shawnb · Unread post by **shawnb** » 22 Apr 2015, 20:48

I agree, device specificity is important. The workaround is to use buses.

shawnb · Unread post by **shawnb** » 22 Apr 2015, 20:57

I'm having a hard time following this evolving patch... The input MIDI stream didn't make sense to me, looks like you're using NOTEs. I think CCs would work with less hassle, if you could use them instead of NOTEs.

HOWEVER, if the signal coming out of the 'msg' outlet is truly 0 or 1, I would suggest using the logical NOT function ("not (A)", under Math | Logical), which would reverse the 0 & 1.

parityflux · Unread post by **parityflux** » 23 Apr 2015, 01:14

shawnb wrote:I agree, device specificity is important. The workaround is to use buses.

I prefer the bus method, but it seems to break the MIDI learn ability on the system-supplied send (see very first screen shot). Using just a bus (which I can see the activity on), the system-supplied mute on that send does not react, and will not learn.

parityflux · Unread post by **parityflux** » 23 Apr 2015, 01:17

shawnb wrote:I'm having a hard time following this evolving patch... The input MIDI stream didn't make sense to me, looks like you're using NOTEs. I think CCs would work with less hassle, if you could use them instead of NOTEs.

HOWEVER, if the signal coming out of the 'msg' outlet is truly 0 or 1, I would suggest using the logical NOT function ("not (A)", under Math | Logical), which would reverse the 0 & 1.

I may switch to CCs, I was just trying use what is default on the Livid controller. Notes seemed ideal for simple pad buttons with no velocity out, saving some CCs.

I will look at the logical NOT too. Thanks.

I'm going to start over in a new workspace and try to build a test case, without all of the distractions.

parityflux · Unread post by **parityflux** » 23 Apr 2015, 07:55

I'm tearing my hair out. Need to sleep. What is so incredibly frustrating is that if you add a couple of MIDI devices to the rack input, they appear to be split at that point: their own entities (this is good, very much liked, and expected). Then when you get into patches inside the rack, the MIDI is all mixed again (not good, don't like). This forces you to go through all kinds of manipulation to tear the stream apart again and force channel filtering and that kind of BS when it started separate in the first place. Devices are different, they do different things, they represent different entities, they should stay separate unless one physically pipes them together into a module. Drats.

I had the busses working fairly well (I thought), but the busses won't serve up data to the MIDI learn ##$%^. I've read all about the MIDI being mixed together, knew it ever since I bought the program in '13, but now, now it's really got me down. I'm now days behind schedule and tomorrow I'll have to decide what to live with and what to forget about.

Reboot.

shawnb · Unread post by **shawnb** » 23 Apr 2015, 18:51

parityflux wrote:
shawnb wrote:I agree, device specificity is important. The workaround is to use buses.
I prefer the bus method, but it seems to break the MIDI learn ability on the system-supplied send (see very first screen shot). Using just a bus (which I can see the activity on), the system-supplied mute on that send does not react, and will not learn.

Yes, MIDI learn does not work unless the little device patchlet routes the signal to "Midi to Usine".

I generally use buses, but where MIDI Learn is needed, I route to both the bus and the "Midi to Usine" module.

shawnb · Unread post by **shawnb** » 23 Apr 2015, 19:56

OK, think I have a solution. What you have observed is:
Note ON turns your light OFF
Note OFF turns your light ON

What you want is
Note OFF translated to Note ON - so your light goes OFF
Note ON translated to Note OFF - so your light goes ON

If so, keep it very simple:

/ MIDI Filter (Note ON) => Create MIDI (msg fixed at Note OFF) =>
MIDI input bus output bus
MIDI Filter (Note OFF) => Create MIDI (msg fixed at Note ON) => /

For both MIDI filters, connect the 'Pass' outlet to the corresponding Create MIDI inlet.
Also connect Chan, Code 1 & Code 2 to their corresponding inlets.

parityflux · Unread post by **parityflux** » 23 Apr 2015, 20:00

Thanks shawnb,

I appreciate your thoughts. I will work on this tonight (I'm GMT-7). I plan on working on it until it works.

-j

shawnb · Unread post by **shawnb** » 23 Apr 2015, 20:08

I think I wanna play my MIDI guitar thru this...

parityflux · Unread post by **parityflux** » 24 Apr 2015, 08:19

I'm abandoning the idea. I went back to busses, which I prefer, but I have to abandon the idea of inverse on the buttons, or even the idea of colorizing the pads. I'll just have to have pad lights on for the output send mute, and lights off when send is unmuted. That's just the way it is. I've spent two full evenings on it, running through many scenarios and I just can't get it to work like I envision.

It would really be great if the MIDI Learn, inverse property would work for pads (using NOTE ON/OFF) as well as with sliders, for which this functionality already exists. That would be intuitive from a user perspective IMO. It would have also saved my countless hours beating a dead horse, but I'll own that one.

Coloring the pads is another issue. I'm not sure on the best approach for that (moduling vs. fastscript vs. c+), but it is not an immediate need. The notion of being able to do that however is extremely empowering and motivating. The ability to send state information (via different colors) to the Livid CNTRLR is one of the reasons I bought it. Full of potential.

Time for me to move on and be creative and not stuck in left brain repetition cycles.

shawnb · Unread post by **shawnb** » 24 Apr 2015, 08:44

I concur.

Think of the light as telling you 'MUTE'...

Welcome to %s forums

MIDI Learn inverse

Who is online

Login • Register