Building a Learn Fader Function...

I have taken apart a few of the environments posted in the environments forum and I really like the idea of a Learn Fader button, but when I try to apply the idea that others have successfully implemented mine do not work.

 

I have include a screen shot as well as a simple working file if anyone can give me some clue as to why my auto off function is not working when I push a fader up. I had a thought that it was because midi information is arriving at the same time and it is choosing the original data over my transformed data, but not sure how to remedy this process. I have followed the signal path from others that have worked and I think I followed the same theory, but mine does not work...

 

any help would be appreciated... trying to dig into this environment thing can be frustrating when you don't know the little quirks...

 

thanks

 

Curtis

test 2.logic.zip

I realized after I posted this that I am just trying to figure out why the auto shutoff does not work... I never included the meta event transformers to set the fader channels or anything... I have figured this portion out (or at least I think I have)... sorry for not making that clear...

I think you must have tried to model your environment after a very early version of one of mine that appeared somewhere here on LPH. The delay line isn't necessary, etc. Anyway, I've attached a version for you to have a look at. This is just to get you to understand how capturing parameters works. Then we can modify it so that it's actually usable.

 

Here's the theory of operation:

 

• the various parameters and controls you find in a channel strip, whether they're part of the actual channel strip or a plugin's parameter controls, will output one of two types of events when moved: CC events (normal MIDI continuous controller events) or "fader" events (specific to Logic, where "fader" actually just means "a parameter of some kind". The parameter can be a fader, a knob, or a switch). The idea is to move a control and have the environment detect (learn) the CC or fader parameter number. From there, a dedicated environment control (fader, knob, etc.) will "assume" that same function.

 

Channel Strip Output

Volume = CC#7

Pan = CC#10

Mute = Fader 9

Solo = Fader 3

Send 1 = Fader 28

 

Note that all of the above output on MIDI channel 1. This is really important, because plugins will output on channels other than 1. Example: first insert effect will output on channel 2. Second insert, channel 3. And so on.

 

So it's not enough to just capture the CC or Fader event's number, but also the channel. We'll get to that eventually. For now, however, try out this environment. You'll see that it is able to learn the CC or Fader number of any parameter from the channel strip itself or any plugin. However, out of the box the fader will ONLY work to manipulate Send 1. If you create Send 2, Send 3, Send 4, etc., it will work with those as well.

 

Post back if you have questions.

test 2 ski.logic.zip

the c Press (resetter) did the trick, but why does that work and not converting a message to controller data like I had the first time to reset? once I get the fader # and data byte 1 setting properly i will re submit... thanks for the help...

just closed and re-opened and now it does not work... the cable switchers are set to respond to c-press 1:0 and the values are travelling through the monitor after the reseter but only changing the first cable switcher and not the second... what the heck? Is this a bug, or am I going crazy?

sorry for all the posts, but I just re cabled it and thats it, and now it works... I am only changing values on the compressor for my tests... there is no weird bugs that you guys have encountered is there?

 

thanks... I going to go insane with this thing... 123 serenity now... 123 serenity now....

When I saw that the environment you posted didn't work, I revisited one of my later versions and posted it. I didn't try and modify yours or even understand what you were trying to do too much. So the one I posted isn't going to work the same as yours. And since I wasn't sure that you understood how this is supposed to work I simplified my environment that it only worked under very basic conditions. Sort of as a tutorial-type of environment.

 

But the resetter works every time here. By chance do you have multiple songs open? If that's the case then it's possible that the resetter won't work correctly (or, rather, it won't appear to work correctly. Logic bugs having to do with multiple songs open).

 

Anyway...

 

I used CPressure to reset the capture switch so that it wouldn't get accidentally reset (or set) by something like CC#7, which yours did. I figured that CPressure wasn't likely to be generated by the channel strip or a plugin.

 

Works fine here. Like I said in my previous post, it will only work to convert the (fader) to control the sends. If you want to take it a step further and have it able to learn any plugin in any slot, that'll take more work. If you want to concentrate on just one slot, though, that's easy to do. Lemme know.

Wait...

 

Wait...

 

Ah, I see the problem with the resetter thing. Gimme a minute.

I did have multiple songs open, so that may be the case... I will let you know if there are any further problems... I also noticed that the cpress (resetter) was set to respond to all incoming data... if that is the case then would it convert note information to cpress data as well... I have limited it to only fader data, unless there was a reason for this... I want to try and built this from top to bottom myself (unfortunately its the only way I learn), but when I hit a wall that I can't explain (the bugs I mentioned above) I will let you know... thanks again for showing me the ropes when it comes to this stuff it is much appreciated...

 

Curtis

Crap... now it's not working on my system. Very weird. Thought this would be an easy fix, but I think it's a bug. Going to have to get back to you later on this.

Still not the best idea to have multiple songs open at once. But that aside, I'll get back to you later on this strange behavior.

I know... I thought I had the answer and then... nope... and then yup... and then nope... sorry for making life difficult.... I got the idea from a environment Steve H posted... I tried to emulate what he was doing with my own twists and then it doesn't work... if it helps I was working from the Para Sequencer by Steve H, it looked as though you helped on that one as well..

 

Curtis

No problem.

 

I made the capture function for Steve's Parasequencer. Must have been an early rev that you took that from. Either that or I forgot some of the finer points. In any case, I'll get back to you at some point if I can figure out why reset isn't working 100%.

OK, I figured it out.

 

What we have going on in the above scenarios is that a button controls the position of a cable switcher. When the button is on, the cable switcher is set to pass the parameter data to those parts of the environment which learn which parameter has been moved. Then we're trying to take whatever data that is and convert it to something which turns the button off. What we were hoping for was that in turning the button off that it will output a message which, in turn, sets the cable switcher back to zero.

 

However, this routine of:

 

button--->cable switcher--->data to turn off button--->reset cable switcher

 

...doesn't work. I think it might be due to a bug, but I'm not sure. Still, we know it doesn't work, so best to avoid it and try a different approach:

 

Eliminate the button entirely. Really, all it's doing is remote-controlling the cable switcher. You really could just click on the cable switcher directly, right? But it's not as cool-looking. AND, this whole scheme is causing a problem. So get rid of the button and change the apperarance of the cable switcher into a button!! This is done by selecting it and going to the Inspector. There you'll see a "style" parameter. Change this to "button". Voila! The appearance changes, but not the function. It's still a cable switcher!

 

One more thing...

 

The Feedback checkbox in the cable switcher needs to be enabled.

 

I've attached a revision. I know you like to figure this stuff out yourself, but I just couldn't help myself. It now recognizes not only the parameter (fader) but also the channel. So now you can select any parameter on any plugin (including an instrument plugin) and learn it.

 

I've also made a few other modifications.

 

If you want to see this work for yourself, temporarily change the cable switcher's appearance ("style") back to being a cable switcher.

test 2a ski.logic.zip

I will give it a look see... thanks so much... its weird though because the scheme that you mention above works fine in older environments posted here with no glitche problems... I am running Logic 9 at home and Logic 8 at work... it could just be a problem with one of the versions... something that apple might be interested in at any rate... thanks from the work around... will let you know if I encounter anything else...

 

Curtis

works great... thanks Ski... as always... another problem... another solution...