GMGM
Max Output Level: -81 dBFS
- Total Posts : 494
- Joined: 10/26/2007
- Location: Omaha, NE
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 16, 10 5:40 PM
(permalink)
Ok, sorry to post back late (been super busy at work and home the last few months). I watched it a little differently this time. I was in the Edit/Track view window the whole time, and did not ride the faders on the "Mixing Console" window. So, I armed the automation record so I could "record" some volume fades and test the curve setting. I set a different curve, and hit play. While it was playing/recording, the nodes were poppin all over the place (it looked like Brando's track #1 example). Lots of nodes, all over the place. I thought, "Awesome! Problem solved". Then I hit stop, and I watched Sonar erase all of my wonderful little nodes. It reduced them back to the same as my original post. So, clearly Sonar recognized all the little movements, and visually acknowledged them. But when I hit stop, it still performed a thinning of this automation data. I need to figure out a way to record a video representation of this. So, my frustration continues. All I want is the final result to look like Brando's #1 track example. Then I will decide which nodes to throw away. 
post edited by GMGM - August 16, 10 5:47 PM
DAW: SONAR Platinum PC: i7-2600 @ 3.40GHz, ASUS Motherboard, 16G RAM OS: Windows 10 Home 64-bit I/O: MOTU 8M / MOTU 8PRE / PreSonus DigimaxLT / M-Audio Oxygen 49
|
thomasabarnes
Max Output Level: -43 dBFS
- Total Posts : 3234
- Joined: 11/11/2003
- Location: Milwaukee, WI USA
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 16, 10 6:13 PM
(permalink)
Hey GMGM:
Maybe SONAR isn't installed healthily (to sort of speak). Did you try a full uninstall and re-install to see if that will fix the problem?
 "It's not a song till it touches your heart. It's not a song till it tears you apart!" Lyrics of Amy Grant. SONAR Platinum X64 (jBridge), Windows 10 Pro 64-Bit, Core i7 990X Extreme Edition Processor 3.46 GHz 6 Cores, Gigabyte EX58-UD5, Crucial Ballistix 24GB 1333MHz DDR3 @1333 MHz, TASCAM UH-7000, Behringer X-Touch, EVGA GTX 980TI Superclocked 6GB, 1TB Samsung EVO 850 SSD, 150GB, 320GB, 1TB 7200rpm HDDs
|
slartabartfast
Max Output Level: -22.5 dBFS
- Total Posts : 5289
- Joined: 10/30/2005
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 16, 10 7:02 PM
(permalink)
Then I hit stop, and I watched Sonar erase all of my wonderful little nodes. So how do you know that the data is gone just because the nodes are not visible on the display at your display resolution? If you increase the display resolution (zoom in) do you see more nodes. Does anyone know if the nodes on the display represent the actual (and exclusive) data points for automation recorded in Sonar? "Jump (Envelope Editing menu only) This choice causes the envelope to make a ninety degree jump between two nodes. SONAR displays jumps with a dotted line, meaning that there is automation data at the nodes where the dotted line begins and ends, but not where the dotted line itself is." That would seem to indicate that if there is no data between two nodes it will be graphed/displayed a dotted line rather than a solid line.
post edited by slartabartfast - August 16, 10 7:16 PM
|
GMGM
Max Output Level: -81 dBFS
- Total Posts : 494
- Joined: 10/26/2007
- Location: Omaha, NE
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 17, 10 11:10 AM
(permalink)
No, when I zoom into the waveform, there are no nodes to grab on to (just the few nodes that remain after the automation had been "thinned" out). And when I first discovered this, the playback didn't match (soundwise) what I heard when I was "recording: the automation.
My test the other night was just random mouse wiggles, so I won't tell you I heard a difference - since I wasn't really listening.
At the end of the day, I do not have the ability to perform (and retain) a "bell" shaped automation envelope, just spikey pyramids. And it seems that drawing them freehand is somewhat limited too in the amount of nodes it'll capture.
Here's a thought, something I haven't tried. My PC isn't exactly an I7 with 235 kajillion Gigs of RAM. And my interface isn't known for playing well with Sonar. Therefore, I tend to crank up my latency, and forget it. I monitor live inputs whenever possible. Live is good.
Is there any reason to believe that decreasing my latency buffers would influence automation as well?
I wouldn't think so, since I can watch it marking nodes during 'record'. I jsut want to turn off this 'thinning'. Are there any VST "automation plugins"? I'm guessing that always a host thing, but who knows. I'm pulling my hair out.
DAW: SONAR Platinum PC: i7-2600 @ 3.40GHz, ASUS Motherboard, 16G RAM OS: Windows 10 Home 64-bit I/O: MOTU 8M / MOTU 8PRE / PreSonus DigimaxLT / M-Audio Oxygen 49
|
rbowser
Max Output Level: -10 dBFS
- Total Posts : 6518
- Joined: 7/31/2005
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 17, 10 12:13 AM
(permalink)
GMGM - I think you're probably right that there's a limitation of your system interfering with automation and the nodes. But I think perhaps you're thinking there need to be more nodes than there really need to be. When recording automation in real time, or drawing it in with the Envelope Draw Tool set to Freehand, when you're first recording or drawing the automation, it's true that a lot more nodes are being displayed during the process than when you stop. There is some "thinning out" of the nodes, as you've described. But what I'm seeing is that the unnecessary nodes are being left out with No change in what the aural results are. In-between the nodes are connecting lines- and the program is accurately making them either Linear, Slow, or Fast, depending on the way they were recorded. Here's a short screen capture I just did, no sound, just showing an envelope being added to an audio clip in Sonar. Playback was exactly what I heard as I made the envelopes. In the first half of the clip, you'll see automation being recorded live via moving the track's volume fader. When I stop, you'll see the appropriate number of nodes are left, even though they are thinned out from what I saw during the recording process. You'll see me right click on one of the connecting lines - and you can see the line is a Slow curve, appropriate to that moment in the envelope. In the second half of the clip, I use the Envelope Draw Tool set to Freehand---Same results. I draw a curve, and its simplified when I'm through drawing, but the resulting envelope works perfectly. Is this different from what you're seeing when you work in Sonar with the nodes? Envelope Vid Capture Randy B.
Sonar X3e Studio Roland A-800 MIDI keyboard controller Alesis i|O2 interface Gigabyte Technology-AMD Phenom II @ 3 GHz 8 Gb RAM 6 Core Windows 7 Home Premium x64 with dual monitors
|
ston
Max Output Level: -71 dBFS
- Total Posts : 965
- Joined: 3/4/2008
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 18, 10 7:01 AM
(permalink)
I've been reading this thread with some interest and have a couple of questions:
Does Sonar capture the automation at the node points, then fills in-between the nodes with envelopes?
What's the between-node resolution? Is this a fixed period of time which the user cannot influence?
TIA :-)
|
rbowser
Max Output Level: -10 dBFS
- Total Posts : 6518
- Joined: 7/31/2005
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 18, 10 10:12 AM
(permalink)
ston
I've been reading this thread with some interest and have a couple of questions:
Does Sonar capture the automation at the node points, then fills in-between the nodes with envelopes?
What's the between-node resolution? Is this a fixed period of time which the user cannot influence?
TIA :-)
Good questions, Ston. Watching the video I posted in the post above yours could be a good visual answer. I can say that the lines between nodes aren't fixed in their length - the program creates nodes wherever it needs to, fills in with fast and slow lines. So the automation is a bit abstracted from the original - but it adapts automation extremely well I think. I Always get the playback I want. Randy B.
Sonar X3e Studio Roland A-800 MIDI keyboard controller Alesis i|O2 interface Gigabyte Technology-AMD Phenom II @ 3 GHz 8 Gb RAM 6 Core Windows 7 Home Premium x64 with dual monitors
|
John
Forum Host
- Total Posts : 30467
- Joined: 11/6/2003
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 18, 10 10:29 AM
(permalink)
I do believe that some CS's have a better control on this the others and a great more then a mouse. For example the Mackie Control has motorized 100mm touch-sensitive Penny & Giles faders with 10Bit resolution (1024 steps). This gives a 1/4 dB resolution on a track.
|
bitflipper
01100010 01101001 01110100 01100110 01101100 01101
- Total Posts : 26036
- Joined: 9/17/2006
- Location: Everett, WA USA
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 18, 10 10:47 AM
(permalink)
To those who say automation is sample accurate and those who disagree: you're both right!
You can manually plant nodes with great precision. All of my automation is done by hand - I never record automation - and I can easily use a volume envelope to notch out a single cycle if I want to. And yes, I could even put in thousands of nodes per second if I wanted to.
Recorded automation, however, is automatically "thinned", or decimated. The aud.ini variable is called AutomationDecimationMSec. It defaults to 50 milliseconds.
Bear in mind that your ears cannot hear volume changes less than 20-40ms in duration. And that's just for short transients like hi-hat hits. For relatively slow-moving audio such as a vocal track, the threshold is more like 100-150ms, so 50ms should be more than fine enough resolution for vocals.
And can you really move a fader by hand in less than 50 milliseconds?
Also note that you cannot discern the difference between slow, fast and linear automation curves when they are very short. Try it - audition each curve type in a blind test. I use straight lines for most automation changes less than a quarter-note in duration.
 All else is in doubt, so this is the truth I cling to. My Stuff
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 9/14/2007
- Location: Manitou Spgs, Colorado
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 18, 10 11:59 AM
(permalink)
Recorded automation, however, is automatically "thinned", or decimated. The aud.ini variable is called AutomationDecimationMSec. It defaults to 50 milliseconds. I experimented with this variable, and couldn't detect any effect one way or the other. Whether I set it at 10, 1000, or the default of 50, nodes are thinned to a typical interval of 150-300ms with intervals as high as 500ms or more when the rate of change is low, and intervals as short as 5ms when the rate of change is high. EDIT: And, yes, I did restart SONAR in between to be sure the parameter change was read. But I have to agree with the OP that the thinning algorithm works unpredictably/inaccurately, sometimes placing nodes very close together when not much is happening, and then completely flattening a quick move up and down, only preserving nodes on either side of it, even though the preview while recording clearly registered the move. Also the logic that SONAR applies to choosing fast and slow curves between nodes can be kind of ugly, constructing a string of fast and slow curves connecting a series of nodes that should really just be linear, or combining a slow curve up with a fast curve down so you get a pointy peak when the original move was really more like a hump, and would be better represented by the opposite combination. Whether all these inaccuracies are audible is debatable; I think they are in some circumstances (e.g. attempted surgical reduction of a loud transient), but in most of those circumstances, manual placement of automation nodes would probably be more appropriate anyway. For more typical kinds of mixing moves you would make by ear, I think the automation capture is reasonably accurate, even with the whacky thinning.
post edited by brundlefly - August 18, 10 12:01 AM
|
slartabartfast
Max Output Level: -22.5 dBFS
- Total Posts : 5289
- Joined: 10/30/2005
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 18, 10 1:08 PM
(permalink)
Whether I set it at 10, 1000, or the default of 50, nodes are thinned to a typical interval of 150-300ms with intervals as high as 500ms or more when the rate of change is low, and intervals as short as 5ms when the rate of change is high.
So are we then assuming that the only data recorded "live" is in fact represented by the nodes on the display after "thinning"? If so, then regardless of the shape of the line that appears on the display between the nodes, there would actually be a discrete jump with no intermediate values between the nodes. Or are we thinking that SONAR for some reason best fits that line to one of its curve algorithms and ignores the actual data? Or is the placement of the nodes (which represent pre-placed "handles" for editing) a separate operation than the recording of the automation data? And why is this not clearly documented somewhere?
|
GMGM
Max Output Level: -81 dBFS
- Total Posts : 494
- Joined: 10/26/2007
- Location: Omaha, NE
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 19, 10 1:19 PM
(permalink)
Several have commented that perhaps I don't need so many nodes, and yes you are definitely correct for probably 95% of the automation moves I will ever really need to make. But since I found this issue, it's really gotten under my skin. The more I pick at it, and the more you guys say it works fine for you, the more frustrated I get. Ha ha ha ha. The fact is, I should be able to record a bell curve in my automation, and keep it. I should be able to keep 10,000 nodes per second if I really want to (and my mouse/CS/computer are up to the challenge). Now, I can record a bell curve and hear it while I'm recording the automation, but as soon as I hit stop I have to watch Sonar toss out my "awesome" moves. And yes, it is audible. I guess I need to record a screen video of my own with audio. For now, I'll post this. If I could cuplicate what RBOWSER captured on his screen (the top image), I'd be much happier. But my reality looks more like the bottom (bottom image, red indicates the nodes that remained after thinning with yellow lines indicating the shape of the curve).  I'd buy a better control surface if that would solve my problem. But I don't think it will based on the fact that I can see many many many nodes being marked on screen during 'record'. A question relating to AUD.INI - by the way Bitflipper that exactly the piece of this puzzle I've been trying to find. I always assumed that aud.ini was written when Sonar does it's system configuration process. I assume the "decimation" they are referring to is what I would call the "sampling rate" of the mouse or control station. I will play around tonight and see what happens if I make that 1000 ms. I would expact to see one auomation node every 1 second as I record (and perhaps this will be followed by some amount of "thinning" after I hit stop). If that is correct, then there must also be a variable to control the "thinning" that happens after I hit stop, no? It REALLY hurts to say this, but this is one feature that Pro Tools does (or did) right. They let you determine how much thinning you wanted. I am not going back to Digi, so this is driving me bonkers.
DAW: SONAR Platinum PC: i7-2600 @ 3.40GHz, ASUS Motherboard, 16G RAM OS: Windows 10 Home 64-bit I/O: MOTU 8M / MOTU 8PRE / PreSonus DigimaxLT / M-Audio Oxygen 49
|
slartabartfast
Max Output Level: -22.5 dBFS
- Total Posts : 5289
- Joined: 10/30/2005
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 19, 10 3:08 PM
(permalink)
red indicates the nodes that remained after thinning with yellow lines indicating the shape of the curve Is the yellow line what actually shows on your display or is it just something you sketched in between the red nodes to illustrate what happens? It would be helpful if someone who is familiar with the source code would chime in and clarify this issue. I am not always sure what "tests" designed to tease out what the program is doing mean for certain. Speculation is even less reliable than testing.
|
bitflipper
01100010 01101001 01110100 01100110 01101100 01101
- Total Posts : 26036
- Joined: 9/17/2006
- Location: Everett, WA USA
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 19, 10 6:43 PM
(permalink)
Whether I set it at 10, 1000, or the default of 50, nodes are thinned to a typical interval of 150-300ms with intervals as high as 500ms or more when the rate of change is low, and intervals as short as 5ms when the rate of change is high. That's just quantization, isn't it? At a slow rate of change, it takes longer to reach the next quantization level. Redundant samples are naturally discarded for efficiency and don't generate nodes. Consequently, you end up with widely-spaced nodes for slow changes and closely-spaced nodes for rapid changes. The AutomationDecimationMs variable wouldn't affect that, since by it's name we can assume it's a temporal variable that has nothing to do with quantization resolution. More likely, it affects the sample rate, which would determine the fastest rate of change you could record. It wouldn't necessarily mean there were more or fewer nodes, only that very brief changes were ignored or slopes would be less steep, the same way sample rate affects audio. So I've just talked myself out of my earlier advice regarding that variable. Thanks, brundlefly. I do agree that what gets captured in automation recording is reasonably accurate 99.9% of the time. The other 0.1% either needs manual tweaking, or it's close enough and nobody will notice. Personally, recording automation drives me nuts. Too restrictive and too imprecise. Manual automation feels cumbersome at first but once you get the hang of it, it can actually be much faster than recording.
All else is in doubt, so this is the truth I cling to. My Stuff
|
bitflipper
01100010 01101001 01110100 01100110 01101100 01101
- Total Posts : 26036
- Joined: 9/17/2006
- Location: Everett, WA USA
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 19, 10 6:50 PM
(permalink)
GMGM, your problems could very well be caused by your control surface.
I'm speculating here, but we've all experienced mixer faders that were worn, dirty or just low-quality and we know what that does to audio passing through them. In fact, better mixers not only have smoother faders they also use VCAs with filtering on the control voltage - effectively doing the same thing as digital decimation to smooth the transitions.
I wonder if a too-coarse fader might not be responsible for wacky curves like your picture shows. That sharp drop doesn't look like something you put in on purpose. Unless you'd had way too much coffee.
Seriously, give manual automation another chance. If nothing else, the resulting curves are much nicer-looking.
All else is in doubt, so this is the truth I cling to. My Stuff
|
John
Forum Host
- Total Posts : 30467
- Joined: 11/6/2003
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 19, 10 7:06 PM
(permalink)
I thought GMGM was using a mouse?
|
thomasabarnes
Max Output Level: -43 dBFS
- Total Posts : 3234
- Joined: 11/11/2003
- Location: Milwaukee, WI USA
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 19, 10 7:44 PM
(permalink)
I wish Noel were here to comment on the AutomationDecimationMSec varible and why Pro Tools is able to have the envelope resolution the OP is wanting and SONAR seems to be unable to be set to give him the resolution he's wanting. It seems that bitflipper hit on something that may be what the OP is looking for, yet brundlefly says he tried changing the AutomationDecimationMSec varible number and he didn't see any change in the envelope resolution. Noel, ole good buddy, ole pal, where are you??!!!!
post edited by thomasabarnes - August 19, 10 7:49 PM
"It's not a song till it touches your heart. It's not a song till it tears you apart!" Lyrics of Amy Grant. SONAR Platinum X64 (jBridge), Windows 10 Pro 64-Bit, Core i7 990X Extreme Edition Processor 3.46 GHz 6 Cores, Gigabyte EX58-UD5, Crucial Ballistix 24GB 1333MHz DDR3 @1333 MHz, TASCAM UH-7000, Behringer X-Touch, EVGA GTX 980TI Superclocked 6GB, 1TB Samsung EVO 850 SSD, 150GB, 320GB, 1TB 7200rpm HDDs
|
thomasabarnes
Max Output Level: -43 dBFS
- Total Posts : 3234
- Joined: 11/11/2003
- Location: Milwaukee, WI USA
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 21, 10 9:51 AM
(permalink)
"It's not a song till it touches your heart. It's not a song till it tears you apart!" Lyrics of Amy Grant. SONAR Platinum X64 (jBridge), Windows 10 Pro 64-Bit, Core i7 990X Extreme Edition Processor 3.46 GHz 6 Cores, Gigabyte EX58-UD5, Crucial Ballistix 24GB 1333MHz DDR3 @1333 MHz, TASCAM UH-7000, Behringer X-Touch, EVGA GTX 980TI Superclocked 6GB, 1TB Samsung EVO 850 SSD, 150GB, 320GB, 1TB 7200rpm HDDs
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 9/14/2007
- Location: Manitou Spgs, Colorado
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 21, 10 12:02 AM
(permalink)
bitflipper
Whether I set it at 10, 1000, or the default of 50, nodes are thinned to a typical interval of 150-300ms with intervals as high as 500ms or more when the rate of change is low, and intervals as short as 5ms when the rate of change is high.
That's just quantization, isn't it?
At a slow rate of change, it takes longer to reach the next quantization level. Redundant samples are naturally discarded for efficiency and don't generate nodes. Consequently, you end up with widely-spaced nodes for slow changes and closely-spaced nodes for rapid changes.
The AutomationDecimationMs variable wouldn't affect that, since by it's name we can assume it's a temporal variable that has nothing to do with quantization resolution. More likely, it affects the sample rate, which would determine the fastest rate of change you could record. It wouldn't necessarily mean there were more or fewer nodes, only that very brief changes were ignored or slopes would be less steep, the same way sample rate affects audio.
So I've just talked myself out of my earlier advice regarding that variable. Thanks, brundlefly.
I do agree that what gets captured in automation recording is reasonably accurate 99.9% of the time. The other 0.1% either needs manual tweaking, or it's close enough and nobody will notice. Personally, recording automation drives me nuts. Too restrictive and too imprecise. Manual automation feels cumbersome at first but once you get the hang of it, it can actually be much faster than recording.
The problem is that the "quantization" after thinning is not consistent, either by time or amplitude. Sometimes the points are close together (both in level and time), and sometimes they're far apart, and there's no consistent correlation to how fast the control level was changing. The really disconcerting thing is that the preview data look good, and the density does correlate well to the rate of change. But that's not what you get after thinning. I have to say, though, that my recent experience seems different from past experiences. In the past, I don't remember there being a difference between the preview and the final result. At first I thought it might be due to input resolution, but I get the same result whether using a mouse, or my BCF2000. What I get now looks like the last screenshot posted by GMGM. I'll have to experiment some more with settings, because I don't think the change coincided with an upgrade or patch - I think it occurred pretty recently. de
|
rbowser
Max Output Level: -10 dBFS
- Total Posts : 6518
- Joined: 7/31/2005
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 21, 10 1:19 PM
(permalink)
It'll be interesting if you can track down what recent change in your system has caused problems, Brundle. It seems possible that if you discover something, it could help out GMGM.
I'm happy to say that I've never had any issues with nodes and envelopes, not of the sort GMGM is talking about. My video screen shot was taken on my laptop. Those nodes generated by both live recording and by drawing were perfectly acceptable. As always, the play back was exactly what I expected, exactly what I heard when I was doing the live version.
And I've never used anything but a mouse. I suspect it's true, what someone said on this thread, that it doesn't matter if you're using a mouse or a control surface.
In other words - something is clearly wrong somewhere for GMGM's results to be so grossly simplified and changed. Hope this is figured out!
Randy B.
Sonar X3e Studio Roland A-800 MIDI keyboard controller Alesis i|O2 interface Gigabyte Technology-AMD Phenom II @ 3 GHz 8 Gb RAM 6 Core Windows 7 Home Premium x64 with dual monitors
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 9/14/2007
- Location: Manitou Spgs, Colorado
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 21, 10 4:12 PM
(permalink)
It'll be interesting if you can track down what recent change in your system has caused problems, Brundle. I don't know; I think I was mis-remembering. I experimented a little more, and while the thinning can sometimes flatten small, quick moves of 2-3dB, and make weird curve choices betweee nodes as mentioned before, I don't ever get anything as grossly inaccurate as the screenshot that GMGM ginned up. The amount of thinning is comparable in terms of the number of nodes thrown out, but it doesn't ever throw away the min and max values of big moves in the extreme way he's depicting. What I get is perfectly serviceable with a little tweaking here an there.
|
rbowser
Max Output Level: -10 dBFS
- Total Posts : 6518
- Joined: 7/31/2005
- Status: offline
Re:Change Resolution of Automation (Recorded evnvelopes)?
August 21, 10 4:21 PM
(permalink)
brundlefly
It'll be interesting if you can track down what recent change in your system has caused problems, Brundle.
I don't know; I think I was mis-remembering. I experimented a little more, and while the thinning can sometimes flatten small, quick moves of 2-3dB, and make weird curve choices betweee nodes as mentioned before, I don't ever get anything as grossly inaccurate as the screenshot that GMGM ginned up. The amount of thinning is comparable in terms of the number of nodes thrown out, but it doesn't ever throw away the min and max values of big moves in the extreme way he's depicting. What I get is perfectly serviceable with a little tweaking here an there.
Ah, OK. Thanks for the investigative work, Brundle. You're always so good at doing that. What you're saying here describes my experience with nodes and envelopes exactly. Recording automation in real time yields me the most musical results, and hand-editing nodes as needed is never that big of a chore. I get what I want with a reasonable amount of effort - as seen in the vid I posted. Thanks. Randy B.
Sonar X3e Studio Roland A-800 MIDI keyboard controller Alesis i|O2 interface Gigabyte Technology-AMD Phenom II @ 3 GHz 8 Gb RAM 6 Core Windows 7 Home Premium x64 with dual monitors
|