Re: [LAD] automation on Linux (modular approach)

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <ralf.mardorf@...>
Cc: <linux-audio-dev@...>
Date: Monday, March 22, 2010 - 9:21 pm

--_412babcc-059a-4942-932f-95324755d331_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> > It doesn't mean the synth will not sound good=2C there are just some=20

=2C=20
=20

The Matrix 1000 users also complained of the quantisation of the mod matrix
for this beast=2C admittedly only when being used for very wide/wild modula=
tion
where again the steps could be heard (*). Perhaps this is getting off the p=
oint: if
work is going to be done on a CV proposal (which is admittedly debatable) t=
hen
quantising to some level at which people have been known to complain of in =
the
past is not a good starting point.

The nice thing about the tuxfamily proposal is that CV is completely 'analo=
guous'
by which I mean analogous to the native sampling parameters. That is badly
phrased=2C I am likely to get hit on for saying it but it does not suffer f=
rom any worse=20
quantisation than the underlying audio signal. The analogue monsters took a=
lot=20
of flac when they started quantising their parameters and the tux design wo=
uld=20
avoid such issues.

Another reason this is getting off the point is that defining a separate CV=
port in
Jack would obfuscate the issue=2C probably. The people discussing ambient c=
ontrol
would want CV at the native rate and that can be delivered now anyway over
audio ports - the only question is how the application uses the data on tho=
se ports.
If a new port type is defined then it will carry some quantised representat=
ion of this
data and then if any app talked about supporting CV you would not know whic=
h
type was being supported. I don't think the overhead in jack would be that =
high=20
for distributing native/audio CV and if people wanted to quantise down to f=
ractions
of the sample rate or resolution because that is how their apps work then t=
his could=20
still be applied as an interface into the native data. The reverse is natur=
ally not true.

Nick.
* The Matrix-1000 (and related 6 and 12) are amongst the best synths ever=
=2C don't
misunderstand my critisism. When they were first released several of the ha=
rdware
magazines refered to them as the most over the top analogue synths imaginab=
le.
If anything=2C a new implementation of CV should take into account the smal=
l number
of complaints that were made against it and parameter quantisation is one o=
f them.
I still want to build an emulator for one of these however I need to finish=
the EMS
Synthi first as the Oberheim mod matrix was loosely based on its patch pin =
panel.
=20
_________________________________________________________________
Hotmail: Free=2C trusted and rich email service.
https://signup.live.com/signup.aspx?id=3D60969=

--_412babcc-059a-4942-932f-95324755d331_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

&gt=3B &gt=3B It doesn't mean the synth will not sound good=2C there are ju=
st some &gt=3B &gt=3B things that it&gt=3B &gt=3B will not be able =
to do.&gt=3B &gt=3B&gt=3B &gt=3B Regards=2C nick.&gt=3B &gt=
=3B Indeed a B3 emulated by an Oberheim Matrix-1000 might be no good choice=
=2C &gt=3B OTOH because of the automation=2C you won't have any synth w=
ith a good B3 &gt=3B emulation to change 20 parameters during a song=2C=
while for any &gt=3B "synthetic" sound e.g. from an Oberheim Matrix-10=
00 you might wish to &gt=3B change a lot of parameters during a song an=
d changing filter parameters &gt=3B for "synthetic" sounds 128 steps ar=
e enough.&gt=3B The Matrix 1000 users also complained of the qu=
antisation of the mod matrixfor this beast=2C admittedly only when bein=
g used for very wide/wild modulationwhere again the steps could be hear=
d (*). Perhaps this is getting off the point: ifwork is going to be don=
e on a CV proposal (which is admittedly debatable) thenquantising to so=
me level at which people have been known to complain of in thepast is n=
ot a good starting point.The nice thing about the tuxfamily proposa=
l is that CV is completely 'analoguous'by which I mean analogous to the=
native sampling parameters. That is badlyphrased=2C I am likely to get=
hit on for saying it but it does not suffer from any worse quantisatio=
n than the underlying audio signal. The analogue monsters took a lot of=
flac when they started quantising their parameters and the tux design woul=
d avoid such issues.Another reason this is getting off the poin=
t is that defining a separate CV port inJack would obfuscate the issue=
=2C probably. The people discussing ambient controlwould want CV at the=
native rate and that can be delivered now anyway overaudio ports - the=
only question is how the application uses the data on those ports.If a=
new port type is defined then it will carry some quantised representation =
of thisdata and then if any app talked about supporting CV you would no=
t know whichtype was being supported. I don't think the overhead in jac=
k would be that high for distributing native/audio CV and if people wan=
ted to quantise down to fractionsof the sample rate or resolution becau=
se that is how their apps work then this could still be applied as an i=
nterface into the native data. The reverse is naturally not true.Ni=
ck.* The Matrix-1000 (and related 6 and 12) are amongst the best synths=
ever=2C don'tmisunderstand my critisism. When they were first released=
several of the hardwaremagazines refered to them as the most over the =
top analogue synths imaginable.If anything=2C a new implementation of C=
V should take into account the small numberof complaints that were made=
against it and parameter quantisation is one of them.I still want to b=
uild an emulator for one of these however I need to finish the EMSSynth=
i first as the Oberheim mod matrix was loosely based on its patch pin panel=
. Hotmail: Free=2C trusted and rich email servic=
e. Get it now.
=

--_412babcc-059a-4942-932f-95324755d331_--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] automation on Linux (modular approach), alex stone, (Fri Mar 19, 9:09 am)
Re: [LAD] automation on Linux (modular approach), rosea grammostola, (Fri Mar 19, 9:47 am)
Re: [LAD] automation on Linux (modular approach), alex stone, (Fri Mar 19, 9:57 am)
Re: [LAD] automation on Linux (modular approach), rosea grammostola, (Fri Mar 19, 10:07 am)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Fri Mar 19, 11:53 am)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Fri Mar 19, 7:22 pm)
Re: [LAD] automation on Linux (modular approach), Tim E. Real, (Fri Mar 19, 7:22 pm)
Re: [LAD] automation on Linux (modular approach), Paul Davis, (Fri Mar 19, 8:00 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Fri Mar 19, 9:47 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Fri Mar 19, 9:32 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Fri Mar 19, 9:54 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:05 pm)
Re: [LAD] automation on Linux (modular approach), Tim E. Real, (Sat Mar 20, 1:30 am)
Re: [LAD] automation on Linux (modular approach), alex stone, (Sat Mar 20, 8:06 am)
Re: [LAD] automation on Linux (modular approach), rosea grammostola, (Sat Mar 20, 10:36 am)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:00 pm)
Re: [LAD] automation on Linux (modular approach), Louigi Verona, (Sat Mar 20, 9:43 am)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:00 pm)
Re: [LAD] automation on Linux (modular approach), Gene Heskett, (Sat Mar 20, 4:45 pm)
Re: [LAD] automation on Linux (modular approach), Paul Davis, (Sat Mar 20, 8:19 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:00 pm)
Re: [LAD] automation on Linux (modular approach), Gene Heskett, (Sun Mar 21, 12:05 am)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:05 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:05 pm)
Re: [LAD] automation on Linux (modular approach), Louigi Verona, (Sat Mar 20, 7:48 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 2:56 pm)
Re: [LAD] automation on Linux (modular approach), Louigi Verona, (Mon Mar 22, 2:50 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:00 pm)
Re: [LAD] automation on Linux (modular approach), Harry Van Haaren, (Mon Mar 22, 4:04 pm)
Re: [LAD] automation on Linux (modular approach), Louigi Verona, (Mon Mar 22, 3:02 pm)
Re: [LAD] automation on Linux (modular approach), Louigi Verona, (Mon Mar 22, 6:37 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 6:51 pm)
Re: [LAD] automation on Linux (modular approach), James Morris, (Tue Mar 23, 1:44 am)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Tue Mar 23, 6:13 pm)
Re: [LAD] automation on Linux (modular approach), Gene Heskett, (Tue Mar 23, 6:59 pm)
Re: [LAD] automation on Linux (modular approach), James Morris, (Thu Mar 25, 12:10 pm)
Re: [LAD] automation on Linux (modular approach), rosea grammostola, (Thu Mar 25, 10:45 pm)
Re: [LAD] automation on Linux (modular approach), rosea grammostola, (Sun Mar 28, 6:56 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Tue Mar 23, 7:33 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:00 pm)
Re: [LAD] automation on Linux (modular approach), Nick Copeland, (Mon Mar 22, 3:48 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 4:36 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 4:44 pm)
Re: [LAD] automation on Linux (modular approach), Jens M Andreasen, (Mon Mar 22, 4:25 pm)
Re: [LAD] automation on Linux (modular approach), Nick Copeland, (Mon Mar 22, 5:22 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 5:53 pm)
Re: [LAD] automation on Linux (modular approach), Nick Copeland, (Mon Mar 22, 9:21 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 9:56 pm)
Re: [LAD] automation on Linux (modular approach), Nick Copeland, (Mon Mar 22, 10:43 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Tue Mar 23, 5:52 pm)
Re: [LAD] automation on Linux (modular approach), Nick Copeland, (Tue Mar 23, 8:06 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Tue Mar 23, 9:44 pm)
Re: [LAD] automation on Linux (modular approach), Nick Copeland, (Tue Mar 23, 8:58 pm)
Re: [LAD] automation on Linux (modular approach), Paul Davis, (Tue Mar 23, 10:05 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Tue Mar 23, 6:02 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:05 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Mon Mar 22, 3:06 pm)
Re: [LAD] automation on Linux (modular approach), Folderol, (Sat Mar 20, 11:19 am)
Re: [LAD] automation on Linux (modular approach), Arnold Krille, (Fri Mar 19, 8:06 pm)
Re: [LAD] automation on Linux (modular approach), Tim E. Real, (Fri Mar 19, 8:51 pm)
Re: [LAD] automation on Linux (modular approach), Paul Davis, (Fri Mar 19, 9:06 pm)
Re: [LAD] automation on Linux (modular approach), Philipp, (Fri Mar 19, 12:22 pm)
Re: [LAD] automation on Linux (modular approach), alex stone, (Fri Mar 19, 12:24 pm)
Re: [LAD] automation on Linux (modular approach), Philipp, (Fri Mar 19, 11:32 am)
Re: [LAD] automation on Linux (modular approach), rosea grammostola, (Fri Mar 19, 9:14 pm)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Fri Mar 19, 9:56 pm)
Re: [LAD] automation on Linux (modular approach), alex stone, (Fri Mar 19, 11:52 am)
Re: [LAD] automation on Linux (modular approach), Ralf Mardorf, (Fri Mar 19, 11:58 am)