Hello If you define a fader in an environment, you cannot automate it with "track automation", you have to use the control value of the fader, so why having faders ! ;-) Also the "track automation" cannot control sys-ex faders ! :-[ One thing that is missing is to be able to redefine the control name per synth ! that will be user friendly ! Will LC be able to control the Environment faders in version 6 ! ;-) the thriller of January :-) It's time that Sound Diver merges with Logic to be an ALL-IN-ONE Best Cyril

From: "Cyril Blanc" <blanc.cyril@...>: > If you define a fader in an environment, you cannot automate it with > "track automation", you have to use the control value of the fader, so I've got a work around for ya. Create the fader you wish to automate in the environment (Let's call it NewFader). Make sure that the Icon box is checked in the parameters window. (H to show/hide). Now, pick an audio fader you aren't using. Let's say AudioInst63. Add it to your arrange window. Goto the environment and find AudioInst64. Ctrl-click the white output triangle of the fader object to bring up a list of routing destinations. Select your NewFader. As long as the NewFader you created is set to receive In: Control, Channel: 1, and -1-: 7 then it will respond to any volume automation of AudioInst63. (For which you may use the normal read/touch/latch settings) The output settings of NewFader may still be anything you need them to be. Of course, if you need to do a live automation pass you will have to use the AudioInst63 fader to record your moves. Seems like you could then also assign AudioInst63 to your logic control and it would control your NewFader by proxy. hth, Sam

Thoughts from the mind of Sam Watson, 04-01-2003: >From: "Cyril Blanc" <blanc.cyril@...>: > >> If you define a fader in an environment, you cannot automate it with >> "track automation", you have to use the control value of the fader, so > >I've got a work around for ya. [complicated workaround deleted] I don't know what you guys are making a problem of, but afaik, you can simply automate a fader like you can every other object. Create a fader, have its In/Out set to e.g. control 12, check its icon and assign it to a track in Arrange. Enable "View > Track Automation". From the parameter popup (i.e. the popup that appears when clicking on the "Volume" parameter) pick "Midi control 0-63 > Ctrl 12". Draw automation curves, etc... This just works as expected -- and is track-based. And yes, the automation data written is Control data instead of Fader Events (as witnessed by looking at the Automation Event List for the track), but that's of no relevance whatsoever. -- Hendrik Jan Veenstra <h@...> Omega Art: http://www.omega-art.com

From: "Cyril Blanc" <blanc.cyril@...> > Thank very much for answering. No problem. It's good LUG karma! :) > The problem is that my faders has sys-ex in the IN and OUT, do you > have another trick ? ( I need sys-ex in IN/OUT to be able to receive a > setup from the box :-) ) I have wondered about this problem myself from time to time because of certain things I wish to do with my Yamaha 01V. I think I may have an answer: Two faders! FaderOne is set for Sysex In and CC#7 output and is cabled to FaderTwo. Fader Two is set for CC#7 In and Sysex Ouput. Add FaderTwo to the arrange window and automate it with CC#7. Your sysex parameters will then be output from automation. When Sysex parameters come into FaderOne and move it will output CC#7s which can be used to create automation. For further reading I found page 5-85 (Version 4.0) or the manual really useful. In fact, it mentions this two fader method! (Although I thought of the idea before I actually stumbled across it in the manual.) > What you propose can be done with one fader : > - set the in of the fader to ctrl 7 > - In the arrange window select your fader and select volume, you can > now automate it Yes, but I think that method results that neither Latch or Touch modes of automation working for that track. And if you use the (non-audio) fader in the environment then it generate object based automation instead of the newer track based automation. That is why I thought up the other workaround. Let me know if that two-fader sysex method works out! Sam

Sam Watson wrote: >----- Original Message ----- >From: "Cyril Blanc" <blanc.cyril@...> > > > >> The problem is that my faders has sys-ex in the IN and OUT, do you >>have another trick ? ( I need sys-ex in IN/OUT to be able to receive a >>setup from the box :-) ) >> >> > >I have wondered about this problem myself from time to time because of >certain things I wish to do with my Yamaha 01V. I think I may have an >answer: Two faders! FaderOne is set for Sysex In and CC#7 output and is >cabled to FaderTwo. Fader Two is set for CC#7 In and Sysex Ouput. > > Hello Very good idea, but it does not work with fader having values 0< or > 127 , I have a few of those ! Best Cyril

Hendrik Jan Veenstra wrote: >Thoughts from the mind of Sam Watson, 04-01-2003: > > > >>From: "Cyril Blanc" <blanc.cyril@...>: >> >> >> >>> If you define a fader in an environment, you cannot automate it with >>> "track automation", you have to use the control value of the fader, so >>> >>> >>I've got a work around for ya. >> >> >[complicated workaround deleted] > >I don't know what you guys are making a problem of, but afaik, you >can simply automate a fader like you can every other object. >Create a fader, have its In/Out set to e.g. control 12, check its >icon and assign it to a track in Arrange. Enable "View > Track >Automation". From the parameter popup (i.e. the popup that appears >when clicking on the "Volume" parameter) pick "Midi control 0-63 > Ctrl 12". Draw automation curves, etc... This just works as >expected -- and is track-based. > Hi Thanks for your answer ! Why : Midi control 0-63 > Ctrl 12". I have tried it does not send my sys-ex to the box ! (values can be > 127 and/or < 0) Emagic has to rewiew this ! Best Cyril

Thoughts from the mind of Cyril Blanc, 06-01-2003: >Hendrik Jan Veenstra wrote: > > >>From: "Cyril Blanc" <blanc.cyril@...>: > >>> If you define a fader in an environment, you cannot automate it with > >>> "track automation", you have to use the control value of the fader, so > > >>I don't know what you guys are making a problem of, but afaik, you > >can simply automate a fader like you can every other object. > >Thanks for your answer ! > >Why : >Midi control 0-63 > Ctrl 12". >I have tried it does not send my sys-ex to the box ! (values can be > >127 and/or < 0) Well, sorry, but then your 1st message was confusing to say the least. So you mean that when using 14-bit sysex faders, you have a problem using track automation, right? That's entirely different from your initial claim that "track automation with faders is impossible", since in general _that_ is untrue. It would be nice to provide a decent description of the problem you have, instead of writing overly generalised (and in this case thus false) statements. Such generalities only cause others to write posts that a) take up their time and b) aren't an answer to your problem. >Emagic has to rewiew this ! Well, maybe. But I think there are more urgent things to fix. And, to say a bit about your problem: never EVER try to automate a sysex fader. That's Bad Practice, and asking for trouble. See the sysex tutorials on my website for details. Instead, have the fader's In set to some CC and its Out to sysex. Cable another fader into it, with both In and Out set to the same CC. Now use _that_ fader for automation. So, using e.g. CC7, you have fader A cabled into fader B. Fader A is set to CC7 In and Out, and fader B is set to InÌ7, Out=sysex. Fader B is moved offscreen, and A is used for automation. Then: when you use values beyond the 0-127 range, you apparently use 14 bit faders. These send out their assigned CC plus CC+32 -- in the above example that would be CC7 and CC39, one being the MSB and the other the LSB. Now recording such faders is done as usual: just hit record and move the fader. I would guess that such recorded CC data can be converted to track based automation (TBA) as usual. Assign the track to the fader, and basta. However, editing (e.g. by means of Hyperdraw) of such data is hell, since the data comes in two parts, CC7 and CC39. That *is* an issue alright, but the same holds for object based automation (OBA) of such faders. Conclusion: recording/playback of 14 bit faders can be done both with OBA and with TBA. Hyperdraw-editing of recorded data is next to impossible, both with OBA and TBA. So all in all I don't quite see that there's any relevant difference between OBA and TBA in this respect. -- Hendrik Jan Veenstra <h@...> Omega Art: http://www.omega-art.com

>Thoughts from the mind of Cyril Blanc, 06-01-2003: >>Thanks for your answer ! >> >>Why : >>Midi control 0-63 > Ctrl 12". >>I have tried it does not send my sys-ex to the box ! (values can be > >>127 and/or < 0) Hendrik Jan Veenstra wrote: >Well, sorry, but then your 1st message was confusing to say the >least. So you mean that when using 14-bit sysex faders, you have a >problem using track automation, right? That's entirely different >from your initial claim that "track automation with faders is >impossible", since in general _that_ is untrue. > Hi Jimmy ;-) Thanks for your mail ! I did not say it was impossible, but it is full of non sense (that is not Logic :-P ): ;-) Logic is not Logic ;-) :-D - If you define a fader with a IN and an OUT, why do you have "in the track automation" to chose again a CTRL value - Why do you have sys-ex IN and OUT faders and you cannot automate them directly using or not using data on 2 byte - Same fight for NRPN ! - If you define an instrument why cant you label it's own Ctrl While I am at it : - I have reported that in Logic 5.x you cannot edit a map instrument imported from an 4.8 song more than a year ago, still not fixed ! I know ! Emagic have been working a lot on the audio, but do not forget that the power of Logic compared to Protools is the Midi and the Environment,. Protools adds more and more midi stuff in it's versions. Also Synth and "boxes" are obliged to use Sys-ex or NRPN because of the 7 bit limitation of Midi Thanks Cyril

Thoughts from the mind of Cyril Blanc, 08-01-2003: >- If you define a fader with a IN and an OUT, why do you have "in the >track automation" to chose again a CTRL value Suppose the fader is connected to an environment patch that can deal with multiple controllers. Only the fader's "own" controller (i.e. it's In) affects the fader itself, but all other controllers sent to the fader are passed on to whatever follows next. Therefore Logic should not limit you choice to just the fader's own controller. And so you have to manually pick the controller you want to use for automation. Makes perfect sense imo. >- Why do you have sys-ex IN and OUT faders and you cannot automate them >directly using or not using data on 2 byte This has nothing to do with sysex. The problem you're hinting at is that you can't conveniently hyperdraw data for 14-bit faders (be they sysex or control faders). Agreed -- a 14-bit edit curve in Hyperdraw would be very nice. In the meantime there are workaround though. Suppose your fader has a 0-1023 range, i.e. 8 times as "wide" as a normal 0-127 fader. Then use some controller (with 0-127 range) for hyperdrawing and assign the track to a small patch that converts 0-127 into 0-1023 (a bit tricky but very do-able) -- which effectively means that one value increase in your "automation controller" corresponds to 8 value steps on the fader. This way you lose resolution of course, but at least you can cover the full 1024-range with a single hyperedited controller. As for sysex faders in general: they suck, and if that's what you meant then I agree. Bytes past the 15th byte aren't recognized. Automation has to be done with a second cc-in/cc-out fader (as I said in my previous post), etc. Sysex handling in Logic in general is seriously limited. >- Same fight for NRPN ! Never used them, so can't comment. >- If you define an instrument why cant you label it's own Ctrl You mean custom assignment of controllers to instrument parameters? If you really need that, one transformer set to "Use Map" would take care of that. >I know ! Emagic have been working a lot on the audio, but do not forget >that the power of Logic compared to Protools is the Midi and the >Environment,. Agreed. It seems the MIDI side of Logic is getting neglected, which I too find rather worrying. The environment could do with a serious rewrite for example, sysex handling should be improved, and lots of other small and not-so-small things... -- Hendrik Jan Veenstra <h@...> Omega Art: http://www.omega-art.com

>Thoughts from the mind of Cyril Blanc, 08-01-2003: >>- If you define a fader with a IN and an OUT, why do you have "in the >>track automation" to chose again a CTRL value Hendrik Jan Veenstra wrote: >Suppose the fader is connected to an environment patch that can deal >with multiple controllers. Only the fader's "own" controller (i.e. >it's In) affects the fader itself, but all other controllers sent to >the fader are passed on to whatever follows next. Therefore Logic >should not limit you choice to just the fader's own controller. And >so you have to manually pick the controller you want to use for >automation. Makes perfect sense imo. I do not agree, if you take time to make a nice Environment it is to simplify your work. I am on a "box" that has 50 parameters, If I have to remember what CC correspond to What param ! it is hell If I could say somewhere in Logic the CTRL 54 = to xxxx CTRL 55 = to yyyy Also I need To have fader IN/OUT on the same fader as "the box" can send the CC > Suppose your fader has >a 0-1023 range, i.e. 8 times as "wide" as a normal 0-127 fader. Then >use some controller (with 0-127 range) for hyperdrawing and assign >the track to a small patch that converts 0-127 into 0-1023 (a bit >tricky but very do-able) -- This is a good idea, but if a control has a value from -2400 to +2400 there is a reason, and giving a step of 40 will not allow to trim the pitch Best Cyril

Thoughts from the mind of Cyril Blanc, 08-01-2003: > >Thoughts from the mind of Cyril Blanc, 08-01-2003: >>>- If you define a fader with a IN and an OUT, why do you have "in the >>>track automation" to chose again a CTRL value > >Hendrik Jan Veenstra wrote: >>Suppose the fader is connected to an environment patch that can deal >>with multiple controllers. Only the fader's "own" controller (i.e. >>it's In) affects the fader itself, but all other controllers sent to >>the fader are passed on to whatever follows next. Therefore Logic >>should not limit you choice to just the fader's own controller. And >>so you have to manually pick the controller you want to use for >>automation. Makes perfect sense imo. > >I do not agree, if you take time to make a nice Environment it is to >simplify your work. Well, I don't agree that the sun sets every night, but it still makes perfect sense :-). If, when automating a fader, Logic would limit your choices to *one*, namely the fader's own In-definition, lots of things would become completely impossible. Now _you_ may not need these "lots of things" but others do. Requiring that Emagic cripple a feature in Logic to cater for your specific needs isn't very realistic imo. >I am on a "box" that has 50 parameters, If I have to remember what CC >correspond to What param ! it is hell If you mean you have 50 environment faders (and not an external faderbox with 50 faders), then you should just organise things a bit more. Have the 50 faders send out controllers 1-50 for example, and lay them out in a 5x10 grid or so. You can cable each fader into a transformer that transforms the CC into the one you actually need. You could even have a second batch of 50 faders (text style, with the CC names filled in, set to work as a popup menu), where each fader determines the transformation that takes place. I.e. the text faders send out meta-127 and are cabled into the transformers. You could thus pick the 20th fader (which sends out CC20 -- easy to remember). Right below that fader is a small popup text fader: pick "modulation" from it. Now this 20th fader goes into a transformer which transforms incoming data (= CC20) into modulation (= CC1). When automating you don't have to remember that the 20th fader controls CC1: since the fader is set to CC20, it's simply "20th fader = CC20". The fact that this later is transformed into CC1 is separated from the fader numbering. Besides: if you assign a fader to a track, the parameter pane shows the setting for this fader -- including it's In and Out definition. So you don't even have to remember anything anyway: just select the proper track and look at the parameter pane. And: if you _are_ using a 50-fader external fader box, the same would apply. Let the faders sends out consecutive CCs (1-50 for example), and use popup text faders in Logic to remap the incoming controllers to whatever you like. >If I could say somewhere in Logic the CTRL 54 = to xxxx CTRL 55 = to yyyy > >Also I need To have fader IN/OUT on the same fader as "the box" can send >the CC ?? I don't understand what you mean... > > Suppose your fader has >>a 0-1023 range, i.e. 8 times as "wide" as a normal 0-127 fader. Then >>use some controller (with 0-127 range) for hyperdrawing and assign >>the track to a small patch that converts 0-127 into 0-1023 (a bit >>tricky but very do-able) -- > >This is a good idea, but if a control has a value from -2400 to +2400 >there is a reason, and giving a step of 40 will not allow to trim the pitch Yes, I already agreed with you that it's a pity that you can't conveniently hyperdraw data that exceeds the 7-bit range. Of course you could do something with "coarse/fine" parameters. One 7-bit fader that moves in 48 steps of 100 (requires some custom drawn (and thus tedious) transformer Maps), and one fader that moves in 100 steps of 1. And yes, you could have one fader set the MSB and the other the LSB -- very easy to set up, but very counter-intuitive as well, since it would require you to think in steps of 128, whereas steps of 100 is a lot easier on your mental CPU resources. Hence the idea to have step-100 and step-1 faders -- which is a lot more difficult to set up but easier in practical use. Then you could have 2 automation tracks, assigned to these 2 faders, one doing the coarse tuning and the other the fine tuning. And I know this isn't a proper solution. However, since there *is* no proper solution at the moment, I feel there's little use in just complaining and leaving it at that. For now the most productive approach (imo) is to try to find a workaround that sort-of works, within limits. Sure Emagic should fix this (although I doubt if they ever will), but as long as it's not fixed, you'd better try to find a way to live with it. -- Hendrik Jan Veenstra <h@...> Omega Art: http://www.omega-art.com