[LAD] automation on Linux (modular approach)

Gene Heskett gene.heskett at verizon.net
Sat Mar 20 16:45:08 UTC 2010


On Saturday 20 March 2010, alex stone wrote:
>I'm not sure the gist of the thread has been adhered to, but as
>someone who has sidetracked the odd thread in my enthusiasm, i'm no
>saint either.
>
>Nevertheless, citing ardour as the ultimate answer doesn't address the
>intent of the thread, which as i understand it was a question
>concerning the continuity of data streaming across apps.
>And although Ardour is a fine app, it's automation can be frustrating
>to use, for me at least. I've had a taste of using an alternative, and
>it's a lot easier to use, in my particular use case.
>
>The weight of alternate responses seems to be geared toward a precise
>definition of the use of automation, for a particular use case, which
>is outside of the worklfow of some. That immediately narrows the
>options for users, and forces those of use who work in a different way
>into "this is the way it is, and you'll have to find a workaround."
>Hardly the stuff of building a modular setup, with linux infinitely
>variable in the opportunities it offers to bolt things together in a
>manner the user wishes to exploit.
>
>I've been hammering away at midi since it started, and in the process
>of recording with midi driven projects, i discovered the following:
>
>1.) Users do as much as they can in midi, before they record to audio.
>In the hands of an experienced user, a project can be "tuned" to a
>fairly decent result, before the recording to audio begins.
>
>2.) No matter how much a user does to fine tune the midi, and there
>are some fine midi charts out there, the user still has to edit the
>audio after it's recorded, to further tweak the result into a closer
>resemblance of human playing. This is successful to varying degrees,
>dependent on the skills of the user, and what level of excellence he
>or she wishes to strive for, but in the case of recording orchestral
>work, it's been my experience that sorting out the velocities in the
>midi chart, and then using automation for audio to emulate swells, and
>smooth volume transitions gives the best result, generally speaking.
>
>3.) Contrary to popular belief, midi is not the panacea for automation
>control. It's widespread adoption is more to do with the decisions
>taken by devs and companies in the commercial world, when midi finally
>got past the angst of commercial operators having to agree on
>something. As a protocol to render smooth automated lines, it too does
>its job with varying degrees of success. But it doesn't effectively
>render the smoothness associated with live playing. I know this as a
>former orchestral player, and have on many occasions had to render
>dozens of takes, simply to layer together enough audio to manipulate
>into some semblance of natural playing.
>
>4.) Midi is a multiplexed format. If the user wants to automate using
>one single data stream, then like it or not, he is using 1 port=16
>channels =0-127 bits of control data. In my recent tests, the CV data
>i wrote and used to automate a line gave a far smoother transition,
>from 0.0-1.0, and that was a single data stream. No extra channels, or
>the stepped result of using a defined data jump from 0 to 1 to 2 to 3,
>etc... On top of this, the user has to sort out which channel they're
>going to use, where they're going to send it, and which channel in
>which port they're going to attach it to.
>
>5.) It's also my experience that users i've communicated with over
>many years, who write from midi recorded into audio, are likely going
>to write automation for volume, and maybe a little pan from time to
>time. This is very much dependent on the use case, but it's fair to
>say that those who require as smooth a volume change as possible don't
>get it using midi, at least to a decent standard of excellence. Again,
>relying on those years of use, and a fair degree of objectivity, i was
>enthused by the smoothness of using a CV stream to render volume
>transitions. One of those long held wishes that has come to life, and
>saved me a stack of donkey work in the process.
>
>6.) Crossfading is neither here not there in a discussion about
>automation. It's the province of an app to provide an effective
>crossfade framework, something Ardour does well i might add.
>
>7.) For electronic music writers in particular, but also for the wider
>user base, manipulating an external synth (and we are discussing a
>modular setup, yes?) via CV lanes seems to be an opportunity waiting
>to happen. The user adds a lane, names it to the control he wants to
>manipulate, and goes to work, recording smooth automation lines and
>getting the weird and sometimes original result from the synth. That's
>it. Add a lane, port it to a control and name it for easy recognition
>in the project. Couldn't be easier. and there's no "steps" (0-127)
>when the control is changed.
>
>8.) I'm not wasting anymore valuable time on this,as it's clear any
>effort to do so would be futile in the face of the current status quo,
>and the intent to keep things as they are.
>
>Alex.
>
I agree with you in that midi was a lowest common denominator protocol, and 
its present framework is so restrictive that I long ago gave up on it.  Using 
8 bit words for control, and so limited a number of channels available on a 
single port, and a data speed so slow, made almost anything I did into a fast 
but discernible Floyd Cramer effect even though I was using 2 midi channels 
at the time.  MIDI was a stopgap, a huge selling point if you will, for all 
the $100 to $800 keyboards of the day, only recently have they become 
polyphonic enough to even explore midi fully.

It is now at least 15 years past due for a new, far faster, and more 
expressive protocol.  Something based on the TOS connector or similar 
relatively inexpensive hardware interface that can handle 100x midi's traffic 
on a single, daisy chain-able connection.  I'd suggest 1394B, but in a setup 
and tear down every night scenario, I don't see that as being as rugged as a 
plastic optical fiber.

If this is _that_ protocol (I came in late to this I think), then lets get 
going.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Windows NT: Only 16 megs needed to play Minesweeper! 



More information about the Linux-audio-dev mailing list