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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <fons@...>, <linux-audio-dev@...>
Date: Tuesday, March 23, 2010 - 8:58 pm

--_6668615e-44ad-4ce5-8ed1-479659c8af80_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

fons wrote:

Agreed=2C and the MMA advises on a few of them such as the pan
mentioned in the last submit and the fact that the MMA only=20
advises on a few of them just highlights the limitation.

> The advantage of a defined rate (audio or sub-audio) 'CV'

Perhaps the only issue I have is the naming. What is being
proposed - another message format over another port type
in jack?

The existing tuxfamily definition uses a jack audio port to=20
carry samples that provide the control 'voltage'=2C in this case
as floats. This is a pretty cool method and a few people have
expressed interest in having it more generalised. A separate
port type could still be defined for quantised messages but then
somebody would have to write jcv2cvd to convert that back into
samplerate floats for the synths to work with.

What it comes down to is that the fully programable synths
(arp2600=2C moog modular=2C ms20=2C matrix=2C synthi) allowed=20
anything to connect to anything=2C that means the patching
has to support native formats=2C currently floats at the native
sampling rate. If you introduce another 'CV' based on sub-
sample 16 bit values then you introduce another special
case that needs to be catered for.

As such don't see how they could be reasonably used in=20
conjunction. Take the case of the ARP2600: all of it osc
can modulate all the other osc. At low frequency these could
be passed as your s/16 messages. What about at audible=20
frequency when you want to get FM type effects - is this CV
supposed to be changed depending on whether the signal
is LF or AF? If so=2C where is the cutover done? This kind of
modulation has to be carried in the native format.

Since audible frequencies are the only ones that will work
for FM and other effects then it is pretty much a done deal.
The data needs to be passed at the native rate between apps.

If some synths want to have quantised parameters that is fine=2C
but that really isn't CV and using such a name obfuscates
what is going on.

> Another limitation of MIDI is its handling of context=2C=20

This is also very true. It does raise the question of how much
data you want to carry in these f/16 messages - it now includes
timing information=2C note information=2C data information=2C some
arbitrary concept of channel=2C it may need to carry a MIDI
mapping of some type=2C probably also sequence numbers
for ordering=2C information on the source of the message=2C etc.
The amount of data being passed at a rate of f/16 will be very=20
close to f for continuous changes as these messages are going
to be much larger than a sample of type 'float'. They are also
going to be a lot more laborious to process. I still feel that the
CV should remain floats at native sample rate and apps that
want to quantise should just pull out every n'th sample.

> As far a I can see=2C any application dealing with control

Your initial interpretation of MIDI was just a way to get some
data from A to B. That is true=2C but wasn't a large part of the the=20
actual goal to find a way to digitise CV from A to B? Perhaps
it is time to get rid of the messages and get back to the original
issue of moving analogous signals around and recognise that
in the current digital world 'analogous' is floats/samplerate.

It is then up to the app to decide whether it wants to quantise=20
those values.

That doesn't actually respond to the point you are making here
though - MIDI should certainly not be used internally to an=20
application. Again=2C very correct. This does skirt around the
issue that applications need a midi interface=2C and that when
modulating audio data they need some form of audio interface
between the components. Proposing what appears to be an
enhancement to MIDI for the modulating interface just imposes
an extra level of complexity where an extra port is needed for
the 'new CV' data=2C the audio data needs to be mixed with the=20
'new CV' definition since it is not really reasonable to expect the=20
'new CV' definition be used to carry audio samples for internal
modulation paths. Unless the new CV really is an audio stream.

Nick.
=20
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=3D60969=

--_6668615e-44ad-4ce5-8ed1-479659c8af80_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

fons wrote:&gt=3B&nbsp=3B to send a stream of&gt=3B parameter updat=
es=2C and then it all depends on the receiver&gt=3B if this results in =
a 'staircase' or a smooth trajectory. Agreed=2C and the MMA advises=
on a few of them such as the panmentioned in the last submit and the f=
act that the MMA only advises on a few of them just highlights the limi=
tation.&gt=3B The advantage of a defined rate (audio or sub-audio) =
'CV'&gt=3B style data type is that at least that interpretation is&=
gt=3B defined - it is bandlimited by its sample rate and that&gt=3B mor=
e or less imposes the only valid way to interpret it.Perhaps the on=
ly issue I have is the naming. What is beingproposed - another message =
format over another port typein jack?The existing tuxfamily def=
inition uses a jack audio port to carry samples that provide the contro=
l 'voltage'=2C in this caseas floats. This is a pretty cool method and =
a few people haveexpressed interest in having it more generalised. A se=
parateport type could still be defined for quantised messages but then<=
br>somebody would have to write jcv2cvd to convert that back intosample=
rate floats for the synths to work with.What it comes down to is th=
at the fully programable synths(arp2600=2C moog modular=2C ms20=2C matr=
ix=2C synthi) allowed anything to connect to anything=2C that means the=
patchinghas to support native formats=2C currently floats at the nativ=
esampling rate. If you introduce another 'CV' based on sub-sample 1=
6 bit values then you introduce another specialcase that needs to be ca=
tered for.As such don't see how they could be reasonably used in conjunction. Take the case of the ARP2600: all of it osccan modulate =
all the other osc. At low frequency these couldbe passed as your s/16 m=
essages. What about at audible frequency when you want to get FM type e=
ffects - is this CVsupposed to be changed depending on whether the sign=
alis LF or AF? If so=2C where is the cutover done? This kind ofmodu=
lation has to be carried in the native format.Since audible frequen=
cies are the only ones that will workfor FM and other effects then it i=
s pretty much a done deal.The data needs to be passed at the native rat=
e between apps.If some synths want to have quantised parameters tha=
t is fine=2Cbut that really isn't CV and using such a name obfuscateswhat is going on.&gt=3B Another limitation of MIDI is its handlin=
g of context=2C &gt=3B the only way to do this is by using the channel =
number.&gt=3B There is no way to refer to anything higher level=2C to&gt=3B say e.g. this is a control message for note #12345 that&gt=3B =
started some time ago. This is also very true. It does raise the qu=
estion of how muchdata you want to carry in these f/16 messages - it no=
w includestiming information=2C note information=2C data information=2C=
somearbitrary concept of channel=2C it may need to carry a MIDImap=
ping of some type=2C probably also sequence numbersfor ordering=2C info=
rmation on the source of the message=2C etc.The amount of data being pa=
ssed at a rate of f/16 will be very close to f for continuous changes a=
s these messages are goingto be much larger than a sample of type 'floa=
t'. They are alsogoing to be a lot more laborious to process. I still f=
eel that theCV should remain floats at native sample rate and apps that=
want to quantise should just pull out every n'th sample.&gt=3B =
As far a I can see=2C any application dealing with control&gt=3B data s=
hould offer MIDI only as one possible I/O format=2C&gt=3B but certainly=
not use it internally=2C or be based on it.Your initial interpreta=
tion of MIDI was just a way to get somedata from A to B. That is true=
=2C but wasn't a large part of the the actual goal to find a way to dig=
itise CV from A to B? Perhapsit is time to get rid of the messages and =
get back to the originalissue of moving analogous signals around and re=
cognise thatin the current digital world 'analogous' is floats/samplera=
te.It is then up to the app to decide whether it wants to quantise =
those values.That doesn't actually respond to the point you are=
making herethough - MIDI should certainly not be used internally to an=
application. Again=2C very correct. This does skirt around theissu=
e that applications need a midi interface=2C and that whenmodulating au=
dio data they need some form of audio interfacebetween the components. =
Proposing what appears to be anenhancement to MIDI for the modulating i=
nterface just imposesan extra level of complexity where an extra port i=
s needed forthe 'new CV' data=2C the audio data needs to be mixed with =
the 'new CV' definition since it is not really reasonable to expect the=
'new CV' definition be used to carry audio samples for internalmod=
ulation paths. Unless the new CV really is an audio stream.Nick. Hotmail: Trusted email with powerful SPAM protecti=
on. Sign up now.
=

--_6668615e-44ad-4ce5-8ed1-479659c8af80_--

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)