Content-Type: text/plain; charset=ISO-8859-1
On Sat, Mar 20, 2010 at 9:06 AM, alex stone wrote:
> I'm not sure the gist of the thread has been adhered to, but as
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
You understand what I mean?
Content-Type: text/html; charset=ISO-8859-1
On Sat, Mar 20, 2010 at 9:06 AM, alex st=
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
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 =
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=3D16
channels =3D0-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"=
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 alw=
ays be the best choice. If you implement another technology/ format you als=
o have to think about the environment. Commercial companies can't i=
mplement always the best technology, cause it isn't always the best cho=
ice in a business model.
But this is also true for an community imo. The decision whether you sh=
ould implement another technology should also depend in some way by your en=
vironment, 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 plug=
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 i=
sn'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 protoco=
ls like vendors are. But I also don't like to see different apps not su=
pporting the different plugin formats (ladspa, dssi, lv2), Jack versions, c=
ontroller formats etc.
You understand what I mean?\r