[LAD] automation on Linux (modular approach)

Ralf Mardorf ralf.mardorf at alice-dsl.net
Mon Mar 22 12:51:47 UTC 2010


rosea grammostola wrote:
>
>
> On Sat, Mar 20, 2010 at 9:06 AM, alex stone <compose59 at gmail.com 
> <mailto:compose59 at gmail.com>> 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.
>
>
>
> The best technology might not always be the best choice. If you 
> implement another technology/ format you also have to think about the 
> environment.
> Commercial companies can't implement always the best technology, cause 
> it isn't always the best choice in a business model.
>
> But this is also true for an community imo. The decision whether you 
> should implement another technology should also depend in some way by 
> your environment, the community.
> At least from a user perspective.
>
> As a user I don't have much benefit from apps with the best 
> technologies if they don't support each other, don't support my 
> hardware or my plugins.
>
> I don't know much about CV control. Is it really better then midi? Is 
> it better for the Linux audio user, or do we have another format which 
> isn't supported well within the community?
> At least you have to ask, as a community, yourself these questions.
>
> I don't have the answers, I don't want to be limited to protocols like 
> vendors are. But I also don't like to see different apps not 
> supporting the different plugin formats (ladspa, dssi, lv2), Jack 
> versions, controller formats etc.
>
> You understand what I mean?
>
> \r

The best argument! Very good! Independent of what is the better choice. 
Who of the coders of the current Linux apps would like to add cv if 
people would ask for it?



More information about the Linux-audio-dev mailing list