18 Feb
2010
18 Feb
'10
5:54 a.m.
As a power user who's modestly (just kidding) keen on saving time,
using great workflow, and avoiding as much of the drudgery of editing
work over and over again to get an end result as is possible, i've had
the privilege and pleasure of testing and working with a data protocol
called CV, or control voltage, in these last 2 weeks.
Non-Daw, and it's new buddy Non-Mixer, enable me to write function
data in ND control sequences, or "lanes" at will. From my POV it's
like turbo automation, and i'm still surprised and delighted at how
easy and FAST it is to work with. Without the multiple complexity that
is midi, in a simple 1:1 format, this is a very clever way to handle
automated data between apps, imho.
I ask Devs who are building up or modifying their linux audio and
video apps, if they could cast a brief eye over this protocol, and at
least spare a thought for the opportunities it offers to stream direct
data from one app to another. It seems to be an ideal solution for a
modular framework, without a lot of complexity involved. Best of all,
it uses jack ports to do the routing work, so there's no additional
work devs have to do, when trying to stream data across apps. I know
some of you will be familiar with this protocol, so this quick note
could be considered a reminder. :)
Non-Daw, and Non-Mixer are CV capable, and i can enthusiastically
testify to the system working very well indeed.
I guess you could call this a quick heads up for a community interapp
opportunity, and given the recent resurgence of the Session discussion
(woohoo), i'm thinking the CV protocol might be complementary as a
component in such a framework, from a user's perspective.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
18 Feb
18 Feb
6:13 a.m.
On 02/18/2010 10:54 AM, alex stone wrote:
As a power user who's modestly (just kidding) keen
on saving time,
using great workflow, and avoiding as much of the drudgery of editing
work over and over again to get an end result as is possible, i've had
the privilege and pleasure of testing and working with a data protocol
called CV, or control voltage, in these last 2 weeks.
funny to call CV a "protocol" - it's been around since the 60s, and just
describes the fact that a given processing unit reacts to an incoming
voltage rather than a knob.
at first, i wasn't quite sure if you're joking... but yes, it's very
convenient, just totally not new :)
much like a "one midi command per wire, running status on" architecture.
compared to ardour's automation tracks (which are somewhat difficult to
use), what does non-mixer do that's better?
comparing midi and cv is apples and oranges imho.
6:30 a.m.
Hello,
That's true, this isn't new at all. but it has been lost for some
times in the audio world in favor of midi, mainly afaik because too
much cables just drives people crazy :)
But actually, implementing it perfectly it jack apps may cost a lot if
your control rate is the same as the audio rate (for example computing
a filter coefs 96000 times per second). I think a new type of 'audio'
port having only a sample per period could be a simple and handy
solution to this (one of the problem may be when you connect more than
one cv to a port, mixing CV isn't necessarily the thing we want to do)
Anyway, CV is still, even after 50 year, a really nice way of
controlling audio parameters, and would be kind of a good solution for
mapping lv2 control ports to jack ports.
Regards,
Lta.
2010/2/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
On 02/18/2010 10:54 AM, alex stone wrote:
--
BALLET Julien
Head of LabFree, Free software laboratory of Epitech
Phone : 01 53 14 59 32 || 06 17 32 86 93.
Mail : <j.ballet(a)freelab.epitech.eu> -- <elthariel(a)gmail.com>
Web : http://www.labfree.org/
As a power user who's modestly (just kidding)
keen on saving time,
using great workflow, and avoiding as much of the drudgery of editing
work over and over again to get an end result as is possible, i've had
the privilege and pleasure of testing and working with a data protocol
called CV, or control voltage, in these last 2 weeks.
funny to call CV a "protocol" - it's been around since the 60s, and just
describes the fact that a given processing unit reacts to an incoming
voltage rather than a knob.
at first, i wasn't quite sure if you're joking... but yes, it's very
convenient, just totally not new :)
much like a "one midi command per wire, running status on" architecture.
compared to ardour's automation tracks (which are somewhat difficult to
use), what does non-mixer do that's better?
comparing midi and cv is apples and oranges imho.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
6:39 a.m.
2010/2/18 Julien 'Lta' BALLET <elthariel(a)gmail.com>om>:
Hello,
That's true, this isn't new at all. but it has been lost for some
times in the audio world in favor of midi, mainly afaik because too
much cables just drives people crazy :)
But actually, implementing it perfectly it jack apps may cost a lot if
your control rate is the same as the audio rate (for example computing
a filter coefs 96000 times per second). I think a new type of 'audio'
port having only a sample per period could be a simple and handy
solution to this (one of the problem may be when you connect more than
one cv to a port, mixing CV isn't necessarily the thing we want to do)
Anyway, CV is still, even after 50 year, a really nice way of
controlling audio parameters, and would be kind of a good solution for
mapping lv2 control ports to jack ports.
Regards,
Lta.
2010/2/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
Yes, good point in here about patching, Julien. It took me a little
while to build a template, but once it was done, jack_snapshot does
the heavy lifting so i don't have to.
I'm using a lot of CV ports to handle a big orchestral setup, though i
don't seem to notice additional overhead.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On 02/18/2010 10:54 AM, alex stone wrote:
--
BALLET Julien
Head of LabFree, Free software laboratory of Epitech
Phone : 01 53 14 59 32 || 06 17 32 86 93.
Mail : <j.ballet(a)freelab.epitech.eu> -- <elthariel(a)gmail.com>
Web : http://www.labfree.org/
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
As a power user who's modestly (just kidding)
keen on saving time,
using great workflow, and avoiding as much of the drudgery of editing
work over and over again to get an end result as is possible, i've had
the privilege and pleasure of testing and working with a data protocol
called CV, or control voltage, in these last 2 weeks.
funny to call CV a "protocol" - it's been around since the 60s, and just
describes the fact that a given processing unit reacts to an incoming
voltage rather than a knob.
at first, i wasn't quite sure if you're joking... but yes, it's very
convenient, just totally not new :)
much like a "one midi command per wire, running status on" architecture.
compared to ardour's automation tracks (which are somewhat difficult to
use), what does non-mixer do that's better?
comparing midi and cv is apples and oranges imho.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
9:39 a.m.
> But actually, implementing it perfectly it jack
apps may cost a lot if
> your control rate is the same as the audio rate (for example computing
> a filter coefs 96000 times per second). I think a new type of 'audio'
> port having only a sample per period could be a simple and handy
> solution to this (one of the problem may be when you connect more than
> one cv to a port, mixing CV isn't necessarily the thing we want to do)
>
> Anyway, CV is still, even after 50 year, a really nice way of
> controlling audio parameters, and would be kind of a good solution for
> mapping lv2 control ports to jack ports.
I think you need to recognise that using a CV for everything might be nice but
is indeed a bit of an overhead and is also not really how the old analogue
beasts really worked. They had continuous controls that did apply the V/oct
that mix/max in with the modulating signals, on top of that they also had some
non-continuous controls such as waveform selectors that did not function
in this way - they typically switched between different circuit outputs. CV
really doesn't lend itself to such a use - MIDI is a far better choice for the
many discrete controls of a synth.
Bristol internally uses both representations after making consideration of a
pure CV type signalling. MIDI CC are used for non-continuous controls and
full sample buffers are used for modulation signalling: LFO/Osc/Env outputs
are fed into buffers that are mixed to modulating inputs: the filter sweep is a
buffer of samples and it does recalculate filter coefs for every sample - it eats
GOBS of CPU but avoids the 'ritzing' you would hear if it were only calculated
per buffer period. At the moment there is no external access to these buffers
but that would be a pretty cool capability, especially with something like the
ARP 2600 - let it feed some different signals into the cabling system.
nick
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
6:52 a.m.
On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien 'Lta' BALLET wrote:
Hello,
That's true, this isn't new at all. but it has been lost for some
times in the audio world in favor of midi, mainly afaik because too
much cables just drives people crazy :)
But actually, implementing it perfectly it jack apps may cost a lot if
your control rate is the same as the audio rate (for example computing
a filter coefs 96000 times per second). I think a new type of 'audio'
port having only a sample per period could be a simple and handy
dunno. but i think timestamped events are better.
maybe we should just specify some 32bit/float midi replacement ?
iE somthing that can be translated down to midi.
but still has float values.
an event consisting of uint32_t and a float
could encode all sorts of stuff.
2^24 float CC
21 octaves with 1/65536 tones. noteon noteoff with float velocity.
still got 253 eventtypes free....
all in a nice 8byte per event thingy.
of course it would be discussed to death :(
solution to this (one of the problem may be when you
connect more than
one cv to a port, mixing CV isn't necessarily the thing we want to do)
Anyway, CV is still, even after 50 year, a really nice way of
controlling audio parameters, and would be kind of a good solution for
mapping lv2 control ports to jack ports.
Regards,
Lta.
2010/2/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
--
torben Hohn
On 02/18/2010 10:54 AM, alex stone wrote:
--
BALLET Julien
Head of LabFree, Free software laboratory of Epitech
Phone : 01 53 14 59 32 || 06 17 32 86 93.
Mail : <j.ballet(a)freelab.epitech.eu> -- <elthariel(a)gmail.com>
Web : http://www.labfree.org/
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev As a power user who's modestly (just kidding)
keen on saving time,
using great workflow, and avoiding as much of the drudgery of editing
work over and over again to get an end result as is possible, i've had
the privilege and pleasure of testing and working with a data protocol
called CV, or control voltage, in these last 2 weeks.
funny to call CV a "protocol" - it's been around since the 60s, and just
describes the fact that a given processing unit reacts to an incoming
voltage rather than a knob.
at first, i wasn't quite sure if you're joking... but yes, it's very
convenient, just totally not new :)
much like a "one midi command per wire, running status on" architecture.
compared to ardour's automation tracks (which are somewhat difficult to
use), what does non-mixer do that's better?
comparing midi and cv is apples and oranges imho.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:36 p.m.
On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien 'Lta' BALLET wrote:
But actually, implementing it perfectly it jack apps
may cost a lot if
your control rate is the same as the audio rate (for example computing
a filter coefs 96000 times per second).
You don't *have* to do it that way. As an example, AMS
uses audio-rate control signals, but the VCF and other
modules I wrote for it years ago just use one sample per
period (the last one in the buffer), calculate filter
parameters from these, and interpolate the final params
linearly at sample rate (which is cheap on CPU). You can't
do this with all filter types, it's one reason to avoid
e.g. biquads.
I think a new type of 'audio'
port having only a sample per period could be a simple and handy
solution to this (one of the problem may be when you connect more than
one cv to a port, mixing CV isn't necessarily the thing we want to do)
Mixing can still be handy if you have 'logarithmic' controls.
A reduced-rate port type in Jack (e.g. Fs/16 or Fs/64) would
be very useful IMHO. I've also been thinking of writing a
multichannel 'automation recorder' using such rates to capture
and playback 'control voltages'. There have been many times
when I'd wanted such a thing.
A reduced sample rate means less bandwidth. It doesn't mean
that controls can't be 'sample accurate'. You could even
extract 'sub-sample-accurate' discrete events from them,
it's just a matter of interpretation.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
12:43 p.m.
On Thu, Feb 18, 2010 at 11:32 AM, <fons(a)kokkinizita.net> wrote:
On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien
'Lta' BALLET wrote:
this just needs a minor re-use of the existing midi port type.
drobilla always felt that it was questionable that we called this
stuff "midi" at all, because 95% of the infrastructure is about
handling sample accurate events, and is utterly agnostic about the
contents.
I think a new type of 'audio'
port having only a sample per period could be a simple and handy
solution to this (one of the problem may be when you connect more than
one cv to a port, mixing CV isn't necessarily the thing we want to do)
Mixing can still be handy if you have 'logarithmic' controls.
A reduced-rate port type in Jack (e.g. Fs/16 or Fs/64) would
be very useful IMHO. I've also been thinking of writing a
multichannel 'automation recorder' using such rates to capture
and playback 'control voltages'. There have been many times
when I'd wanted such a thing.
A reduced sample rate means less bandwidth. It doesn't mean
that controls can't be 'sample accurate'. You could even
extract 'sub-sample-accurate' discrete events from them,
it's just a matter of interpretation.
1:13 p.m.
On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote:
On Thu, Feb 18, 2010 at 11:32 AM,
<fons(a)kokkinizita.net> wrote:
We may not be talking of the same thing. This is not about
'generic events' but about reduced-bandwidth continuous
signals, represented as floating point samples. So I'd say
that all it takes is a shorter version of the standard
_audio_ buffer.
The last paragraph in my previous post just hinted at the
possibility that even such low-bandwidth 'analog' signals
can represent discrete events with infinite timing accuracy,
and in a way that would e.g. survive operations such as
mixing or resampling.
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
A reduced sample rate means less bandwidth. It
doesn't mean
that controls can't be 'sample accurate'. You could even
extract 'sub-sample-accurate' discrete events from them,
it's just a matter of interpretation.
this just needs a minor re-use of the existing midi port type.
drobilla always felt that it was questionable that we called this
stuff "midi" at all, because 95% of the infrastructure is about
handling sample accurate events, and is utterly agnostic about the
contents.
1:32 p.m.
So it's feasible to create another type of port, (CV/Fs), without
crippling something else in jack, or damaging the current API?
If so, surely that would enhance further Jack's capabilities, and open
it up to more options for devs and users alike. Even outside my
current setup, and as a user, i can see this as an efficiency
improver for the likes of automation in Ardour, increased control over
synths, etc..
We have audio and midi. A "data" port seems a natural addition,
particularly for modular setups, but as a generic model as well.
Thanks for the input.
Alex.
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
1:38 p.m.
On Thu, Feb 18, 2010 at 12:32 PM, alex stone <compose59(a)gmail.com> wrote:
So it's feasible to create another type of port,
(CV/Fs), without
crippling something else in jack, or damaging the current API?
If so, surely that would enhance further Jack's capabilities, and open
it up to more options for devs and users alike. Even outside my
current setup, and as a user, i can see this as an efficiency
improver for the likes of automation in Ardour, increased control over
synths, etc..
We have audio and midi. A "data" port seems a natural addition,
particularly for modular setups, but as a generic model as well.
there seems to be some confusion.
there are 2 kinds of data flows:
1) streaming - there is 1 value per unit of time
2) event-based - there are N values per unit of time where N is an
integer starting at zero
what are the units of time? for what we currently call "audio" data
flows, a unit of of time is the sample interval. audio data is defined
as 1 floating point value per sample interval.
the options to extend the types of data are, therefore:
a) defining a different time interval, and the data type that will
be provided for each such interval. this is effectively "reduced
sample rate streaming data"
b) defining another event based data flow, like MIDI, in which
events are discrete and (most often) sparse
i personally do not believe that there is much need for (a), but i'm
willing to be shown to be in error.
3:34 p.m.
On Thu, Feb 18, 2010 at 6:38 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Thu, Feb 18, 2010 at 12:32 PM, alex stone
<compose59(a)gmail.com> wrote:
Hello,
There are some interesting point of view in this thread:
- There's a potential problem with the complexity of a big synth using
this mapping (anyway, big synths are almost every time complex to map
to the control system, be it midi or anything else)
- Jack midi infrastructure's potential is maybe underestimated, and
using it we could implement something that could allow more than 8bits
messages. This may become necessary at some points (non-chromatic
frequency notes, precise control of parameters, etc.)
- The straight forward features of CV-like flow and their "physical'
property could be used in interesting ways by users and developpers
(kind of related example is reason)
It's interesting to note that all of these problematics have been
discussed and/or adressed in lv2, maybe this work can be used in jack
for the benefit of all ?
Regards,
--
BALLET Julien
Head of LabFree, Free software laboratory of Epitech
Phone : 01 53 14 59 32 || 06 17 32 86 93.
Mail : <j.ballet(a)freelab.epitech.eu> -- <elthariel(a)gmail.com>
Web : http://www.labfree.org/
So it's feasible to create another type of
port, (CV/Fs), without
crippling something else in jack, or damaging the current API?
If so, surely that would enhance further Jack's capabilities, and open
it up to more options for devs and users alike. Even outside my
current setup, and as a user, i can see this as an efficiency
improver for the likes of automation in Ardour, increased control over
synths, etc..
We have audio and midi. A "data" port seems a natural addition,
particularly for modular setups, but as a generic model as well.
there seems to be some confusion.
there are 2 kinds of data flows:
1) streaming - there is 1 value per unit of time
2) event-based - there are N values per unit of time where N is an
integer starting at zero
what are the units of time? for what we currently call "audio" data
flows, a unit of of time is the sample interval. audio data is defined
as 1 floating point value per sample interval.
the options to extend the types of data are, therefore:
a) defining a different time interval, and the data type that will
be provided for each such interval. this is effectively "reduced
sample rate streaming data"
b) defining another event based data flow, like MIDI, in which
events are discrete and (most often) sparse
i personally do not believe that there is much need for (a), but i'm
willing to be shown to be in error.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
19 Feb
19 Feb
9:59 a.m.
On 18 Feb 2010, at 17:32, alex stone wrote:
So it's feasible to create another type of port,
(CV/Fs), without
crippling something else in jack, or damaging the current API?
If so, surely that would enhance further Jack's capabilities, and open
it up to more options for devs and users alike.
A reduced rate CV port doesn't really make much possible that's not already
possible with a full buffer of values at the audio sampling rate.
Its an optimisation -- *perhaps* -- but thats not the same thing as a new capability.
If a receiving application, for example, wants to update its filter parameters at 1/16th
the full sampling rate it is perfectly capable of skipping 16-at-a-time along an
audio-rate buffer of values all by itself. Or 8-at-a-time. Or 32 or whatever divisor makes
most sense for *that* application, or was configured by the user of that application, or
whatever.
Meanwhile this same buffer can be routed at the same time to applications that would
prefer the full rate data.
10:32 a.m.
On Fri, Feb 19, 2010 at 01:59:34PM +0000, Simon Jenkins wrote:
On 18 Feb 2010, at 17:32, alex stone wrote:
True. The advantage is that if there is a 'standard' for
such control signals (e.g. 1/16) it becomes practical to
store them as well. Of course you could do that at audio
rate, but just imagine the consequences if you have e.g.
at least 4 control signals for each audio channel, as is
the case in the WFS system here. There is a huge difference
between having to store 48 audio files of an hour each,
(25 GB) and 240 of them (125 GB) - in particular if most
of that storage is wasted anyway. In a mixdown session
there can easily be much more than 4 automation tracks
for each audio one. Reducing the rate at least brings
this back to manageable levels.
So it's feasible to create another type of
port, (CV/Fs), without
crippling something else in jack, or damaging the current API?
If so, surely that would enhance further Jack's capabilities, and open
it up to more options for devs and users alike.
A reduced rate CV port doesn't really make much possible
that's not already possible with a full buffer of values
at the audio sampling rate. If a receiving application, for example, wants to
update
its filter parameters at 1/16th the full sampling rate it
is perfectly capable of skipping 16-at-a-time along an
audio-rate buffer of values all by itself. Or 8-at-a-time.
Or 32 or whatever divisor makes most sense for *that*
application, or was configured by the user of that
application, or whatever.
Meanwhile this same buffer can be routed at the same
time to applications that would prefer the full rate data.
All true, but you are confusing two quite separate issues:
*internal update rate* and *useful bandwidth*.
- The internal update rate of e.g. a filter or gain control
would always have to be audio rate, to avoid 'zipper' effects.
The filter could e.g. use linear interpolation over segments
of 16 samples, or 32, or 256. This is an implementation
detail of the DSP code.
- The useful bandwidth of control signals in audio is very
low. Even if the internal update rate is audio, there will
be no energy in the control signal above a few tens of Hz.
If you modulate a filter or gain stage with anything above
that bandwidth it is no longer just a filter or gain control
- you will be producing quite an obvious effect (e.g. vibrato).
That makes sense in synthesisers etc., but in any normal
audio processing it's something to be avoided.
So with the exception of synth modules etc., control signals
never need to be high rate, and if they are the DSP code would
have to filter out the HF parts. Actually 1/16 (3 kHz) would
be more than sufficient for use as envelopes etc. in a synth
as well, anything faster would just generate clicks.
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
10:56 a.m.
On 19 Feb 2010, at 14:30, Fons Adriaensen wrote:
I'm not confusing them, I just wasn't considering bandwidth as the variable we
were trying to optimise for. Maybe it is though.
On Fri, Feb 19, 2010 at 01:59:34PM +0000, Simon
Jenkins wrote:
Storage is a good point.
I'd been thinking mainly in terms of something like an (analog-style?) sequencer
generating the CV in which case you don't store its outputs, you just set it running
again.
But storage is a good point.
On 18 Feb 2010, at 17:32, alex stone wrote:
True. The advantage is that if there is a 'standard' for
such control signals (e.g. 1/16) it becomes practical to
store them as well. Of course you could do that at audio
rate, but just imagine the consequences if you have e.g.
at least 4 control signals for each audio channel, as is
the case in the WFS system here. There is a huge difference
between having to store 48 audio files of an hour each,
(25 GB) and 240 of them (125 GB) - in particular if most
of that storage is wasted anyway. In a mixdown session
there can easily be much more than 4 automation tracks
for each audio one. Reducing the rate at least brings
this back to manageable levels. So it's feasible to create another type of
port, (CV/Fs), without
crippling something else in jack, or damaging the current API?
If so, surely that would enhance further Jack's capabilities, and open
it up to more options for devs and users alike.
A reduced rate CV port doesn't really make much possible
that's not already possible with a full buffer of values
at the audio sampling rate. If a receiving application, for example, wants to
update
its filter parameters at 1/16th the full sampling rate it
is perfectly capable of skipping 16-at-a-time along an
audio-rate buffer of values all by itself. Or 8-at-a-time.
Or 32 or whatever divisor makes most sense for *that*
application, or was configured by the user of that
application, or whatever.
Meanwhile this same buffer can be routed at the same
time to applications that would prefer the full rate data.
All true, but you are confusing two quite separate issues:
*internal update rate* and *useful bandwidth*.
- The internal update rate of e.g. a filter or gain control
would always have to be audio rate, to avoid 'zipper' effects.
The filter could e.g. use linear interpolation over segments
of 16 samples, or 32, or 256. This is an implementation
detail of the DSP code.
- The useful bandwidth of control signals in audio is very
low. Even if the internal update rate is audio, there will
be no energy in the control signal above a few tens of Hz.
If you modulate a filter or gain stage with anything above
that bandwidth it is no longer just a filter or gain control
- you will be producing quite an obvious effect (e.g. vibrato).
That makes sense in synthesisers etc., but in any normal
audio processing it's something to be avoided.
So with the exception of synth modules etc., control signals
never need to be high rate,
So control signals don't need to be high rate, apart from the exceptions, which do.
;)
and if they are the DSP code would
have to filter out the HF parts. Actually 1/16 (3 kHz) would
be more than sufficient for use as envelopes etc. in a synth
as well, anything faster would just generate clicks.
If the user sends a 20khz sine wave into an application's "volume" port
that's either their mistake, or its exactly what they wanted to do.
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
11:31 a.m.
On Fri, Feb 19, 2010 at 02:55:51PM +0000, Simon Jenkins wrote:
If the user sends a 20khz sine wave into an
application's
"volume" port that's either their mistake, or its exactly
what they wanted to do.
If that is what they want to do they should use the right
tool, wich would be ring modulator in a synth. I'd expect
synths to use audio rate controls at least for some units,
even if in almost all cases 1/16 would be enough.
If a 'normal' audio app with a volume control (e.g. a mixer)
would actually accept a 20kHz sine wave as a control signal
then I'd consider it to be of extremely low quality and bad
design. The same app would happily add any noise present on
its controls to its signals and I wouldn't trust it for any
serious work. It's sort the software equivalent of using
cheap low-quality analog faders.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
12:30 p.m.
On 19 Feb 2010, at 15:29, Fons Adriaensen wrote:
On Fri, Feb 19, 2010 at 02:55:51PM +0000, Simon
Jenkins wrote:
Even a hypothetical app might not be so badly written as to cause noise to appear on the
outputs of upstream applications. And would 1/16 rate CV solve this if it did?
Look... *takes a step backwards*....
I'm not expecting a *normal* app to expose its volume control as a CV input at all.
Maybe some in this thread are.
I'm reading "CV input" as "invitation to modulate" and, yes,
sometimes it makes no sense to modulate at the full audio rate, but sometimes it does.
I'm just not sure a special and predetermined 1/16th or whatever control rate is worth
the effort (and might even be a performance hit in some cases) for the reasons I described
when I entered this thread.
Cheers
~ Simon
If the user sends a 20khz sine wave into an
application's
"volume" port that's either their mistake, or its exactly
what they wanted to do.
If that is what they want to do they should use the right
tool, wich would be ring modulator in a synth. I'd expect
synths to use audio rate controls at least for some units,
even if in almost all cases 1/16 would be enough.
If a 'normal' audio app with a volume control (e.g. a mixer)
would actually accept a 20kHz sine wave as a control signal
then I'd consider it to be of extremely low quality and bad
design. The same app would happily add any noise present on
its controls to its signals and I wouldn't trust it for any
serious work. It's sort the software equivalent of using
cheap low-quality analog faders.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:40 p.m.
On Fri, Feb 19, 2010 at 11:30 AM, Simon Jenkins
<sjenkins(a)blueyonder.co.uk> wrote:
I'm reading "CV input" as
"invitation to modulate" and, yes, sometimes it makes no sense to modulate at
the full audio rate, but sometimes it does. I'm just not sure a special and
predetermined 1/16th or whatever control rate is worth the effort (and might even be a
performance hit in some cases) for the reasons I described when I entered this thread.
my feeling precisely. the storage issue is an interesting one, but not
clearly an imperative. i do think that a general purpose event data
type would be useful.
1:34 p.m.
On Fri, Feb 19, 2010 at 11:40:51AM -0500, Paul Davis wrote:
my feeling precisely. the storage issue is an
interesting one, but not
clearly an imperative. i do think that a general purpose event data
type would be useful.
1/16 (3 kHz) is actually overkill for normal audio control.
Digital mixers typically sample their physical controls at
lower rates. Psycho-acoustic arguments would require less
as well. Going up to 1/16 is motivated mainly by the fact
that 16 frames is more or less the shortest Jack period
that makes sense in practice, and you still have a control
sample in each period. A higher rate also makes it much
easier to upsample to audio rate if that would be required,
a simple 1-line lowpass filter is all you need.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
1:39 p.m.
On Fri, Feb 19, 2010 at 12:30 PM, <fons(a)kokkinizita.net> wrote:
On Fri, Feb 19, 2010 at 11:40:51AM -0500, Paul Davis
wrote:
that all makes sense, but if you had a single floating point event per
process cycle, you'd accomplish the same thing, and it would work no
matter what the process cycle size was, and could be used for denser
control values (i.e. more events per process cycle) when
appropriate/necessary/desirable.
my feeling precisely. the storage issue is an
interesting one, but not
clearly an imperative. i do think that a general purpose event data
type would be useful.
1/16 (3 kHz) is actually overkill for normal audio control.
Digital mixers typically sample their physical controls at
lower rates. Psycho-acoustic arguments would require less
as well. Going up to 1/16 is motivated mainly by the fact
that 16 frames is more or less the shortest Jack period
that makes sense in practice, and you still have a control
sample in each period. A higher rate also makes it much
easier to upsample to audio rate if that would be required,
a simple 1-line lowpass filter is all you need.
2:29 p.m.
On Fri, Feb 19, 2010 at 12:39:35PM -0500, Paul Davis wrote:
that all makes sense, but if you had a single floating
point event per
process cycle, you'd accomplish the same thing, and it would work no
matter what the process cycle size was,
Assuming that control changes can be synchronised to
Jack periods is one thing I've learned *not* to do.
It can be done if the source of the control data is
a GUI, or some other human interface and the timing
is not critical. In all other cases it is an invalid
assumption. And not all control is discrete events
which can be timestamped. In my recent applications
it almost never is.
and could be used for denser
control values (i.e. more events per process cycle) when
appropriate/necessary/desirable.
The Fs/16 stream is *not* meant as a data channel that
multiplexes different event types, or values for more
than one controller. It represents a *signal* in all
cases - exactly *one* value that is a function of time.
You could use it for events (e.g. as a trigger of an
envelope), but the number of events on a single parameter
that makes sense is limited by human hearing, and already
some orders of magnitude lower than what a 3 kHz stream
would allow. So 'denser control values' don't make any
sense here.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
2:34 p.m.
On 02/19/2010 05:40 PM, Paul Davis wrote:
On Fri, Feb 19, 2010 at 11:30 AM, Simon Jenkins
<sjenkins(a)blueyonder.co.uk> wrote:
goes to show that you shouldn't call automation data "CV", because it
gives people the wrong ideas (hell, even my mailer is getting confused
and thinks i should be attaching a file :-D)
there are synths, and there is parameter automation. using the latter
for amplitude modulation in the 20-20k band is just not a very good
idea, and should not influence a design discussion...
I'm reading "CV input" as
"invitation to modulate" and, yes,
sometimes it makes no sense to modulate at the full audio rate, but
sometimes it does. I'm just not sure a special and predetermined
1/16th or whatever control rate is worth the effort (and might even
be a performance hit in some cases) for the reasons I described
when I entered this thread.
my feeling precisely. the storage issue is an interesting one, but
not clearly an imperative. i do think that a general purpose event
data type would be useful.
3:44 p.m.
On 19 Feb 2010, at 18:37, Jörn Nettingsmeier wrote:
On 02/19/2010 05:40 PM, Paul Davis wrote:
This discussion is *about* using CV as automation data though. Does CV turn into
automation data when you downsample it?
On Fri, Feb 19, 2010 at 11:30 AM, Simon Jenkins
<sjenkins(a)blueyonder.co.uk> wrote:
goes to show that you shouldn't call automation data "CV", because it
gives people the wrong ideas (hell, even my mailer is getting confused
and thinks i should be attaching a file :-D)
there are synths, and there is parameter automation. using the latter
for amplitude modulation in the 20-20k band is just not a very good
idea, and should not influence a design discussion... I'm reading "CV input" as
"invitation to modulate" and, yes,
sometimes it makes no sense to modulate at the full audio rate, but
sometimes it does. I'm just not sure a special and predetermined
1/16th or whatever control rate is worth the effort (and might even
be a performance hit in some cases) for the reasons I described
when I entered this thread.
my feeling precisely. the storage issue is an interesting one, but
not clearly an imperative. i do think that a general purpose event
data type would be useful.
4:59 p.m.
On Fri, Feb 19, 2010 at 07:43:58PM +0000, Simon Jenkins wrote:
This discussion is *about* using CV as automation data
though.
Is it ?
Does CV turn into automation data when you downsample
it?
Do apples turn into oranges when you cook them ?
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
5:01 p.m.
On 19 Feb 2010, at 20:55, fons(a)kokkinizita.net wrote:
No
~ Simon
PS: FFS
On Fri, Feb 19, 2010 at 07:43:58PM +0000, Simon
Jenkins wrote:
Yes.
This discussion is *about* using CV as automation
data though.
Is it ? Does CV turn into automation data when you
downsample it?
Do apples turn into oranges when you cook them ? Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5:08 p.m.
On Sat, Feb 20, 2010 at 12:03 AM, <fons(a)kokkinizita.net> wrote:
On Fri, Feb 19, 2010 at 09:01:25PM +0000, Simon
Jenkins wrote:
Fons's Fashion Shop?
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
PS: FFS
FFS ? Care to explain this acronym ?
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5:39 p.m.
On 19 Feb 2010, at 21:03, fons(a)kokkinizita.net wrote:
On Fri, Feb 19, 2010 at 09:01:25PM +0000, Simon
Jenkins wrote:
In my world it stands for "come on, give me a break man!"
If it stands for anything harsher in yours then you have my sincere apologies.
Really.
PS: FFS
FFS ? Care to explain this acronym ?
Ciao,
8:20 p.m.
If the user
sends a 20khz sine wave into an application's
"volume" port that's either their mistake, or its exactly
what they wanted to do.
If that is what they want to do they should use the right
tool, wich would be ring modulator in a synth. I'd expect
synths to use audio rate controls at least for some units,
even if in almost all cases 1/16 would be enough.
If a 'normal' audio app with a volume control (e.g. a mixer)
would actually accept a 20kHz sine wave as a control signal
then I'd consider it to be of extremely low quality and bad
design. The same app would happily add any noise present on
its controls to its signals and I wouldn't trust it for any
serious work. It's sort the software equivalent of using
cheap low-quality analog faders.
18 Feb
18 Feb
10:50 p.m.
On Thu, Feb 18, 2010 at 06:09:42PM +0100, fons(a)kokkinizita.net wrote:
On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis
wrote:
could you define _shorter_
is that app specific. or would that be a single factor for the whole
jack graph ?
if we dont mandate that a jack period is always an integer multiple
of a period, we basically need some phase association.
so that apps can sort of know that CV sample 0 has the same time
as audio_sample[phase]
On Thu, Feb 18, 2010 at 11:32 AM,
<fons(a)kokkinizita.net> wrote:
We may not be talking of the same thing. This is not about
'generic events' but about reduced-bandwidth continuous
signals, represented as floating point samples. So I'd say
that all it takes is a shorter version of the standard
_audio_ buffer. A reduced sample rate means less bandwidth. It
doesn't mean
that controls can't be 'sample accurate'. You could even
extract 'sub-sample-accurate' discrete events from them,
it's just a matter of interpretation.
this just needs a minor re-use of the existing midi port type.
drobilla always felt that it was questionable that we called this
stuff "midi" at all, because 95% of the infrastructure is about
handling sample accurate events, and is utterly agnostic about the
contents.
The last paragraph in my previous post just hinted at the
possibility that even such low-bandwidth 'analog' signals
can represent discrete events with infinite timing accuracy,
and in a way that would e.g. survive operations such as
mixing or resampling.
hmm... its not completely obvious to me how it could survive
some arbitrary resampling.
i am thinking of:
x[0] = 0;
x[1] = 0.75;
x[N] = 1.0 | N>1
to encode an event to switch from 0 to 1 at t=0.666666
(this representation is not causal, so it would need to be shifted...
but this is what i have in mind)
i am a bit wary because this still seems a lot more expensive than
having timestamped float events. and i am not sure the ease of recording
this kind of data weighs it up again.
--
torben Hohn
19 Feb
19 Feb
8:50 a.m.
On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
On Thu, Feb 18, 2010 at 06:09:42PM +0100,
fons(a)kokkinizita.net wrote:
Apps using this may have a preference, but I see no difficulty
in defining the a fixed control/audio ratio of 1/16.
The intended use is to patch control signals, e.g. source
positions in a spatialisation system, or more classical
automation data such as gains and filter paramaters.
1/16 would provide a bandwidth of 1500 Hz (for a sample
rate of 48000) which is some overkill in many cases, but
otherwise good to have.
We may not be talking of the same thing. This is
not about
'generic events' but about reduced-bandwidth continuous
signals, represented as floating point samples. So I'd say
that all it takes is a shorter version of the standard
_audio_ buffer.
could you define _shorter_
is that app specific. or would that be a single factor for the whole
jack graph ? if we dont mandate that a jack period is always an
integer multiple
of a period, we basically need some phase association.
so that apps can sort of know that CV sample 0 has the same time
as audio_sample[phase]
With a ratio of 1/16 you can just define the first sample
of control buffer to coincide with the first sample of
the current audio period.
hmm... its not completely obvious to me how it could
survive
some arbitrary resampling.
i am thinking of:
x[0] = 0;
x[1] = 0.75;
x[N] = 1.0 | N>1
to encode an event to switch from 0 to 1 at t=0.666666
(this representation is not causal, so it would need to be shifted...
but this is what i have in mind)
You're close, see below.
i am a bit wary because this still seems a lot more
expensive than
having timestamped float events. and i am not sure the ease of recording
this kind of data weighs it up again.
It's not meant as a replacedment for generic timestamped events.
I just mentioned it to make the point that a lower sampling rate
does not limit timing precision.
If your 'perfect' control signal would be a digital one
using -1,+1 at e.g. audio rate, and the transitions
always have a minimal distance, then downsampling it
preserves all information. You can later upsample it
again, and the zero-crossings will be at the original
position.
Exactly the same thing can be done if the original
signal consists of singe-sample triggers (Dirac
impulses). In that case, the peaks of the resulting
waveform will be at the original positions.
Now suppose you have audio tracks at 48 kHz and
control tracks at 3 Khz, and you need to resample
the audio to 44.1 kHz. Resampling the control
tracks to the same ratio will again preserve all
information.
Using full-quality resampling algos for this is of
course just a wast of resources. You could just use
cubic interpolation. In that case each impulse or
transition would required four 'samples', and they
could even overlap a bit. So at 44.1 or 48kHz / 16
you could roughly have one transition or impulse
each millisecond, with 'infinite' resolution.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
9:05 a.m.
On Fri, Feb 19, 2010 at 3:48 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh
wrote:
An obvious question i guess, but is 1/16 a fine enough resolution for
a wide selection of use cases?
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On Thu, Feb 18, 2010 at 06:09:42PM +0100,
fons(a)kokkinizita.net wrote:
Apps using this may have a preference, but I see no difficulty
in defining the a fixed control/audio ratio of 1/16.
The intended use is to patch control signals, e.g. source
positions in a spatialisation system, or more classical
automation data such as gains and filter paramaters.
1/16 would provide a bandwidth of 1500 Hz (for a sample
rate of 48000) which is some overkill in many cases, but
otherwise good to have.
We may not be talking of the same thing. This is
not about
'generic events' but about reduced-bandwidth continuous
signals, represented as floating point samples. So I'd say
that all it takes is a shorter version of the standard
_audio_ buffer.
could you define _shorter_
is that app specific. or would that be a single factor for the whole
jack graph ? if we dont mandate that a jack period is always
an integer multiple
of a period, we basically need some phase association.
so that apps can sort of know that CV sample 0 has the same time
as audio_sample[phase]
With a ratio of 1/16 you can just define the first sample
of control buffer to coincide with the first sample of
the current audio period.
hmm... its not completely obvious to me how it
could survive
some arbitrary resampling.
i am thinking of:
x[0] = 0;
x[1] = 0.75;
x[N] = 1.0 | N>1
to encode an event to switch from 0 to 1 at t=0.666666
(this representation is not causal, so it would need to be shifted...
but this is what i have in mind)
You're close, see below.
i am a bit wary because this still seems a lot
more expensive than
having timestamped float events. and i am not sure the ease of recording
this kind of data weighs it up again.
It's not meant as a replacedment for generic timestamped events.
I just mentioned it to make the point that a lower sampling rate
does not limit timing precision.
If your 'perfect' control signal would be a digital one
using -1,+1 at e.g. audio rate, and the transitions
always have a minimal distance, then downsampling it
preserves all information. You can later upsample it
again, and the zero-crossings will be at the original
position.
Exactly the same thing can be done if the original
signal consists of singe-sample triggers (Dirac
impulses). In that case, the peaks of the resulting
waveform will be at the original positions.
Now suppose you have audio tracks at 48 kHz and
control tracks at 3 Khz, and you need to resample
the audio to 44.1 kHz. Resampling the control
tracks to the same ratio will again preserve all
information.
Using full-quality resampling algos for this is of
course just a wast of resources. You could just use
cubic interpolation. In that case each impulse or
transition would required four 'samples', and they
could even overlap a bit. So at 44.1 or 48kHz / 16
you could roughly have one transition or impulse
each millisecond, with 'infinite' resolution.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
9:20 a.m.
On Fri, Feb 19, 2010 at 4:05 PM, alex stone <compose59(a)gmail.com> wrote:
On Fri, Feb 19, 2010 at 3:48 PM, Fons Adriaensen
<fons(a)kokkinizita.net> wrote:
The use case i'm thinking of is a crescendo or decrescendo using gain
in a continuous stream of data. Will 1/16 reduce the......
"smoothness"?
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh
wrote:
An obvious question i guess, but is 1/16 a fine enough resolution for
a wide selection of use cases?
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On Thu, Feb 18, 2010 at 06:09:42PM +0100,
fons(a)kokkinizita.net wrote:
Apps using this may have a preference, but I see no difficulty
in defining the a fixed control/audio ratio of 1/16.
The intended use is to patch control signals, e.g. source
positions in a spatialisation system, or more classical
automation data such as gains and filter paramaters.
1/16 would provide a bandwidth of 1500 Hz (for a sample
rate of 48000) which is some overkill in many cases, but
otherwise good to have.
We may not be talking of the same thing. This is
not about
'generic events' but about reduced-bandwidth continuous
signals, represented as floating point samples. So I'd say
that all it takes is a shorter version of the standard
_audio_ buffer.
could you define _shorter_
is that app specific. or would that be a single factor for the whole
jack graph ? if we dont mandate that a jack period is always
an integer multiple
of a period, we basically need some phase association.
so that apps can sort of know that CV sample 0 has the same time
as audio_sample[phase]
With a ratio of 1/16 you can just define the first sample
of control buffer to coincide with the first sample of
the current audio period.
hmm... its not completely obvious to me how it
could survive
some arbitrary resampling.
i am thinking of:
x[0] = 0;
x[1] = 0.75;
x[N] = 1.0 | N>1
to encode an event to switch from 0 to 1 at t=0.666666
(this representation is not causal, so it would need to be shifted...
but this is what i have in mind)
You're close, see below.
i am a bit wary because this still seems a lot
more expensive than
having timestamped float events. and i am not sure the ease of recording
this kind of data weighs it up again.
It's not meant as a replacedment for generic timestamped events.
I just mentioned it to make the point that a lower sampling rate
does not limit timing precision.
If your 'perfect' control signal would be a digital one
using -1,+1 at e.g. audio rate, and the transitions
always have a minimal distance, then downsampling it
preserves all information. You can later upsample it
again, and the zero-crossings will be at the original
position.
Exactly the same thing can be done if the original
signal consists of singe-sample triggers (Dirac
impulses). In that case, the peaks of the resulting
waveform will be at the original positions.
Now suppose you have audio tracks at 48 kHz and
control tracks at 3 Khz, and you need to resample
the audio to 44.1 kHz. Resampling the control
tracks to the same ratio will again preserve all
information.
Using full-quality resampling algos for this is of
course just a wast of resources. You could just use
cubic interpolation. In that case each impulse or
transition would required four 'samples', and they
could even overlap a bit. So at 44.1 or 48kHz / 16
you could roughly have one transition or impulse
each millisecond, with 'infinite' resolution.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
9:31 a.m.
I'd also add here that the CV suggestion isn't a replacement for midi,
but a new, separate, port data type. So those who are happy with using
midi can continue to do so.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
9:48 a.m.
On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone wrote:
The use case i'm thinking of is a crescendo or
decrescendo using gain
in a continuous stream of data. Will 1/16 reduce the......
"smoothness"?
No, the DSP code has to perform smoothing anyway, no matter
what the source of the control data is. Does your GUI fader
provide smooth audio rate updates ? Of course not, you'd be
lucky if it updates 25 times per second.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
10:15 a.m.
On 19 Feb 2010, at 13:47, Fons Adriaensen wrote:
On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone
wrote:
If the receiving application is going to smooth the data back up to audio rate anyway then
what's the point? If the sender has already got audio-rate data then this is a big
*lose* efficiency wise, with the sender spending cycles decimating a buffer that's
going to be upsampled as soon as it arrives. Even if the sender hasn't got audio-rate
data, it might as well do the smoothing itself rather than push the cost into *all* the
apps that receive the data.
"control rate" optimisations make more sense when you're NOT going to smooth
the data, eg when you don't want to update your filter parameters every sample. In
this case (as I just said in another post) the receiver can skip down an audio buffer at
control rate jumps with no help from anybody.
The use case i'm thinking of is a crescendo
or decrescendo using gain
in a continuous stream of data. Will 1/16 reduce the......
"smoothness"?
No, the DSP code has to perform smoothing anyway, no matter
what the source of the control data is. Does your GUI fader
provide smooth audio rate updates ? Of course not, you'd be
lucky if it updates 25 times per second.
10:53 a.m.
On Fri, Feb 19, 2010 at 02:15:13PM +0000, Simon Jenkins wrote:
On 19 Feb 2010, at 13:47, Fons Adriaensen wrote:
(1) Again, they have to do that anyway. Midi doesn't provide audio
rate controls. OSC doesn't. A generic timestamped event format
wouldn't. GUI controls don't.
(2) In almost all algorithms, if you want any efficiency at all
the smoothing is *NOT* done on the control value itself, but on
internal parameters (e.g. filter coefficients) computed from the
control value at lower rate. Sending an audio rate control is
useless, most of the data has to be ignored or lowpass filtered
anyway. Even a simple gain control has to filter an audio rate
control - you want a gain control, not a ring modulator.
(3) This would even be the case for a 1/16 rate signal. The
difference is that the latter takes 1/16 of the work to generate
it, and it takes 1/16 of the space when recorded. If you have
hundreds of them that makes a very big difference.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex
stone wrote:
If the receiving application is going to smooth the data back
up to audio rate anyway then what's the point? If the sender
has already got audio-rate data then this is a big *lose*
efficiency wise, with the sender spending cycles decimating
a buffer that's going to be upsampled as soon as it arrives. The use case i'm thinking of is a crescendo
or decrescendo using gain
in a continuous stream of data. Will 1/16 reduce the......
"smoothness"?
No, the DSP code has to perform smoothing anyway, no matter
what the source of the control data is. Does your GUI fader
provide smooth audio rate updates ? Of course not, you'd be
lucky if it updates 25 times per second.
9:44 a.m.
On Fri, Feb 19, 2010 at 04:05:02PM +0300, alex stone wrote:
An obvious question i guess, but is 1/16 a fine enough
resolution for
a wide selection of use cases?
I don't know about any 'human interfaces' (faders, knobs,
mouses, touchscreens, acceleration sensors, whatever) that
can generate 1000Hz control signals.
Even a 'Mute' on a mixer would in the DSP code evaluate
to a controlled fade in/out of a few milliseconds.
Control signals may require exact timing (which this
form still provides), but they don't required high
bandwidth.
And as said, it's not meant to be a replacement for
generic control data, even if you could use it e.g.
for things like note on/off with infinte resolution.
The advantage of having 'analog' control signals
(by which I mean data interpreted as a sampled
waveform) is that they are easily patchable - the
receiver does not require knowledge of any specific
data encoding. It is this what makes control voltages
in real analog synths so versatile - there is no
discussion about what they mean - just a function of
time.
It would of course be possible to create an 'encoded'
data format that could represent arbitrary low-frequency
waveforms to be used for control. To be really useful
such a format should also permit to encode how fast a
value is moving, and maybe also the second derivative.
For example you could do this by specifying some form of
interpolation between arbitrarily spaced and timestamped
control points. Now imagine the complexity of just adding
two such streams. Or editing them.
Using just a stream of equally spaced samples is much
easier.
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
20 Feb
20 Feb
1:13 a.m.
On Fri, Feb 19, 2010 at 02:42:36PM +0100, Fons Adriaensen wrote:
On Fri, Feb 19, 2010 at 04:05:02PM +0300, alex stone
wrote:
gamer mouse :)
/me hides.
--
torben Hohn
An obvious question i guess, but is 1/16 a fine
enough resolution for
a wide selection of use cases?
I don't know about any 'human interfaces' (faders, knobs,
mouses, touchscreens, acceleration sensors, whatever) that
can generate 1000Hz control signals. 
6 Mar
6 Mar
1:10 p.m.
On Friday 19 February 2010 08:42:36 Fons Adriaensen wrote:
On Fri, Feb 19, 2010 at 04:05:02PM +0300, alex stone
wrote:
David Wessels multitouch interface, as developed by Adrian Freed.
sincerely,
Marije
An obvious question i guess, but is 1/16 a fine
enough resolution for
a wide selection of use cases?
I don't know about any 'human interfaces' (faders, knobs,
mouses, touchscreens, acceleration sensors, whatever) that
can generate 1000Hz control signals.
20 Feb
20 Feb
2:30 a.m.
On Fri, Feb 19, 2010 at 01:48:24PM +0100, Fons Adriaensen wrote:
not if the period is not a power of 2 :(
but maybe we should just go back to enforcing that again.
thanks for explanation :)
--
torben Hohn
On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh
wrote:
good point. ok. so this still leaves us with the problem of the phase
relation in case of non-power of 2 period sizes.
(i am not sure if this patch slipped into jack1 accidentally or on
purpose, but the alsa driver doesnt enforce power of 2 anymore)
but that kind of thing can be fixed easily.
jack_nframes_t jack_cv_get_phase( jack_client_t *client );
i am basically more in favour of timestamped events.
but your argumentation in this thread is pretty convincing.
and timestamped events come with a galore of other problems,
which i think are harder to tackle in a jack context.
- multiple interpolation schemes
- how to get the current value when port is connected, and didnt see an
event yet.
so what do people think ?
shall we just add CV port type ?
(this would sort of rule out timestamped control events, since there
should be only one control port type)
On Thu, Feb 18, 2010 at 06:09:42PM +0100,
fons(a)kokkinizita.net wrote:
Apps using this may have a preference, but I see no difficulty
in defining the a fixed control/audio ratio of 1/16.
The intended use is to patch control signals, e.g. source
positions in a spatialisation system, or more classical
automation data such as gains and filter paramaters.
1/16 would provide a bandwidth of 1500 Hz (for a sample
rate of 48000) which is some overkill in many cases, but
otherwise good to have. We may not be talking of the same thing. This is
not about
'generic events' but about reduced-bandwidth continuous
signals, represented as floating point samples. So I'd say
that all it takes is a shorter version of the standard
_audio_ buffer.
could you define _shorter_
is that app specific. or would that be a single factor for the whole
jack graph ? if we dont mandate that a jack period is always
an integer multiple
of a period, we basically need some phase association.
so that apps can sort of know that CV sample 0 has the same time
as audio_sample[phase]
With a ratio of 1/16 you can just define the first sample
of control buffer to coincide with the first sample of
the current audio period. hmm... its not completely obvious to me how it
could survive
some arbitrary resampling.
i am thinking of:
x[0] = 0;
x[1] = 0.75;
x[N] = 1.0 | N>1
to encode an event to switch from 0 to 1 at t=0.666666
(this representation is not causal, so it would need to be shifted...
but this is what i have in mind)
You're close, see below.
8:27 a.m.
On Sat, Feb 20, 2010 at 07:31:04AM +0100, torbenh wrote:
i am basically more in favour of timestamped events.
but your argumentation in this thread is pretty convincing.
and timestamped events come with a galore of other problems,
which i think are harder to tackle in a jack context.
I'll repeat once again ** Low rate control signals are
not meant to replace generic timestamped events which
are still needed. **
They provide a solution for some cases that are quite
difficult to handle with events, even if you don't
consider the Jack context, i.e. the variable data
size.
For example it would be quite hairy to use discrete
events to create a C1 continuous control signal -
C1 means no 'jumps' and no 'corners'. It can be done
but would require a level of complexity that breaks
the charms of the basic idea and would make most
potential users run away screaming. Just combining
(adding) two such streams with non-coincident events
would be a real nightmare.
With continuous control signals the burden of ensuring
it has the required qualities for a particular use (e.g.
any degree of continuity, or spectral limits) are on
the generator of the control signal. The receiver
would be safe to use it at its full bandwidth, but
doesn't have to do this - it could still cut corners
for efficiency if it wanted, and in most cases that
would actually happen as Fs/16 is overkill anyway.
The 1/16 rate is chosen because it ensures that even
with a period size of 16 (the practical limit IMHO)
all periods are still equal, and a factor of 16
reduction in stored data size makes it usable.
Having non-power-of-2 period sizes complicates the
picture. When and why was this allowed ? I'm pretty
sure it will break a lot of code (including some of
mine, including probably Aeolus and Jconvolver).
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
8:46 a.m.
On Sat, Feb 20, 2010 at 7:23 AM, <fons(a)kokkinizita.net> wrote:
For example it would be quite hairy to use discrete
events to create a C1 continuous control signal -
C1 means no 'jumps' and no 'corners'. It can be done
but would require a level of complexity that breaks
the charms of the basic idea and would make most
potential users run away screaming. Just combining
(adding) two such streams with non-coincident events
would be a real nightmare.
i don't think that anyone is suggesting that a continuous control
signal is a bad idea. the issue is whether its worth providing an
intermediate level of resolution between "audio rate" and "arbitrarily
timestamped events", since the latter case can be used to provide the
exact same level of data "density" as anything else.
Having non-power-of-2 period sizes complicates the
picture. When and why was this allowed ? I'm pretty
sure it will break a lot of code (including some of
mine, including probably Aeolus and Jconvolver).
USB devices function much better with periods based on the h/w period
size of 1msec.
18 Feb
18 Feb
6:32 a.m.
2010/2/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
On 02/18/2010 10:54 AM, alex stone wrote:
Yes, i'm sure it's not new, although implemented in a software
environment may well be...rejuvenating.
I'm struck by the elegant simplicity of it, and the ease of use, hence the mail.
Not sure about apples and oranges though. I've seen a few attempts at
using midi for automation, none of which were as easy to use.
I'm also not sure that "powerful" readily equates to a requirement for
added complexity. If a design is so easy to use that you're not aware
of it, then old or not, it must have something going for it.
Just my view or course.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
As a power user who's modestly (just kidding)
keen on saving time,
using great workflow, and avoiding as much of the drudgery of editing
work over and over again to get an end result as is possible, i've had
the privilege and pleasure of testing and working with a data protocol
called CV, or control voltage, in these last 2 weeks.
funny to call CV a "protocol" - it's been around since the 60s, and just
describes the fact that a given processing unit reacts to an incoming
voltage rather than a knob.
at first, i wasn't quite sure if you're joking... but yes, it's very
convenient, just totally not new :)
much like a "one midi command per wire, running status on" architecture.
compared to ardour's automation tracks (which are somewhat difficult to
use), what does non-mixer do that's better?
comparing midi and cv is apples and oranges imho.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
7:19 a.m.
I will clarify here that i'm talking about a user experience, before
the discussion gets into jousting with white papers.....
:)
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
7:26 a.m.
On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone wrote:
I will clarify here that i'm talking about a user
experience, before
the discussion gets into jousting with white papers.....
:)
hmm... i guess this was some thread hijack.
anyways. my papers are generally brown, because i spilled coffee over
them.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
7:33 a.m.
On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone wrote:
I will clarify here that i'm talking about a user
experience, before
the discussion gets into jousting with white papers.....
ok. so you basically say that midi channels are annoying ?
how about several CC controllers flowing through the same midi connection ?
you think thats bad too ?
i mean for complex synths this could quickly end up in 20 CV lines
controlling one voice.
:)
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
7:47 a.m.
On Thu, Feb 18, 2010 at 2:34 PM, torbenh <torbenh(a)gmx.de> wrote:
On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone
wrote:
We have midi for automation or controlling synths, plugins, etc,
because that's been the malnstream path for development. As far ease
of use, midi is inefficient is certain use cases.
I don't doubt that with great implementation, midi could do better
than it does, but i've yet to see that.
Again, this a personal user experience, based on all the previous
years of having to use midi for such tasks, and the refreshing change
to CV in a software format, that has saved me hours of time already,
and ongoing.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
I will clarify here that i'm talking about a
user experience, before
the discussion gets into jousting with white papers.....
ok. so you basically say that midi channels are annoying ?
how about several CC controllers flowing through the same midi connection ?
you think thats bad too ?
i mean for complex synths this could quickly end up in 20 CV lines
controlling one voice.
:)
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
7:38 a.m.
On 02/18/2010 12:18 PM, alex stone wrote:
I will clarify here that i'm talking about a user
experience, before
the discussion gets into jousting with white papers.....
that's what i was interested in, too. can you describe the advantages of
the non-mixer approach (which i haven't tried yet) to, say, ardour
automation?
8:15 a.m.
2010/2/18 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
On 02/18/2010 12:18 PM, alex stone wrote:
Wouldn't be a fair comparison, as my setup is modular, and Ardour's is
monolithic. However Ardour's automation always frustrated me for my
particular use case. That's down to pilot preference, so any
comparison would only be based on that.
Considering the CV approach to midi port setups, and their 16
channels, it might seem a lot more work to patch 1:1. But it isn't
(imho) when you take into account the separation of channels, and
multiple assignments neccessary when using a midi port as a data
stream (sorting out the CC's at either end, etc...). Given the volume
of ports, tracks, channels i'm using, for MY use case, a 1:1 data
route is a simpler, and faster setup, as in the case of ND and NM
communicating with each other.
And of course, 1:1 means i'm only building what i need, at the time.
No multiple channel ports.
I'm not weilding an army of synths like it seems most users are, so
using a single CV to a single function in a mixer strip, or multiple
CV lanes to components in a synth may not seem so attractive for those
users.
I'd also accept that my preference for a simple record as you go, and
tweak the parameters a bit along the way may not be the "normal" use
case for most users, who employ multiple plugins, synths, etc. CV fits
nicely in my user experience so far, and the lanes in Non-Daw are
visually "quick" to identify any anomalies, or where an audio region
needs a bit more editing. But then that's to do with the design of the
app, for MY use case, so only a part of the user experience, related
to using a CV framework.
I'm beginning to regret i ever posted about this, and will be more
selective with my enthusiasm in the future.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
I will clarify here that i'm talking about a
user experience, before
the discussion gets into jousting with white papers.....
that's what i was interested in, too. can you describe the advantages of
the non-mixer approach (which i haven't tried yet) to, say, ardour
automation?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5435
days inactive
5451
days old
linux-audio-dev@lists.linuxaudio.org
50 comments
10 participants
participants (10)
-
alex stone -
Fons Adriaensen -
fons＠kokkinizita.net
-
Julien 'Lta' BALLET -
Jörn Nettingsmeier -
nescivi -
Nick Copeland -
Paul Davis -
Simon Jenkins -
torbenh