25 Sep
2011
25 Sep
'11
7:14 p.m.
Hello, I've never used hardware that uses VC, but sometime ago I had an
idea, that probably many others have allready exploited (never heard of
it though).
If a control signal is exactly the same as an audio signal,
just very lower in frequency, one could apply all the usual audio
effects to control signal. You could for example turn a knob, have the
signal it generates pass through a delay, reverb or whatever, and then
have it control something (like the frequency of a synth).
This seems an interesting idea I'd like to play with - the problem is,
how can you do it in our linux-audio environment, where usually the
knob generates midi CC data? Is it possible with some tricks to convert
this to an audio signal (maybe way downsampled to not uselessly waste
CPU) pass it through rakarrack or ladspa plugins, reconvert it to midi
CC and have it control something?
A more general thought: what about implementing a new type of generic
"control" signal in JACK, and having existing audio apps accept these
signals in their input? If you come to think of it, there's really no
difference (other than sample rate) between a control signal and an
audio signal, so there's no reason why one shouldn't be able to do DSP
on control signals.
cheers,
renato
25 Sep
25 Sep
7:24 p.m.
On Sun, Sep 25, 2011 at 1:13 PM, Renato <rennabh(a)gmail.com> wrote:
A more general thought: what about implementing a new
type of generic
"control" signal in JACK, and having existing audio apps accept these
it has been discussed. it has not been implemented. there was some
opposition, and as you note, any control signal can be recast as an
audio signal. it would not be hard to add it, but clients would have
to support the new port type explicitly and it would confuse others.
7:45 p.m.
On Sun, Sep 25, 2011 at 01:24:36PM -0400, Paul Davis wrote:
On Sun, Sep 25, 2011 at 1:13 PM, Renato
<rennabh(a)gmail.com> wrote:
I don't buy that. Only clients that need the new port type would have
to support it. You could as well say that MIDI ports confuse pure
audio clients - it's just not true.
As to confusion, using audio type buffers for control signals - without
any way to identify those except maybe by name - would generate a lot
more of it. But since it's the only way, I'm already doing that in two
new apps. They both use audio channels as a bundle of 16 control signals.
Ciao,
--
FA
A more general thought: what about implementing a
new type of generic
"control" signal in JACK, and having existing audio apps accept these
it has been discussed. it has not been implemented. there was some
opposition, and as you note, any control signal can be recast as an
audio signal. it would not be hard to add it, but clients would have
to support the new port type explicitly and it would confuse others.
7:50 p.m.
On Sun, Sep 25, 2011 at 1:45 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
I don't buy that. Only clients that need the new
port type would have
to support it. You could as well say that MIDI ports confuse pure
audio clients - it's just not true.
some clients will look for PortIsPhysical. they do this with MIDI
already. they then try to connect to ports of the wrong type. JACK
prevents this. the clients remain disconnected.
sure, they shouldn't auto-connect in this way. but then, people
shouldn't kill each other either.
8:01 p.m.
On Sun, Sep 25, 2011 at 1:50 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sun, Sep 25, 2011 at 1:45 PM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
or PortIsTerminal or just "the first port on client Foo" ...
I don't buy that. Only clients that need the
new port type would have
to support it. You could as well say that MIDI ports confuse pure
audio clients - it's just not true.
some clients will look for PortIsPhysical. 
9:35 p.m.
On Sunday 25 September 2011 19:50:22 Paul Davis wrote:
That way you punish developers (and force them to use misleading and possibly
dangerous kludges) of certain apps for the mistakes done by other developers
in other apps.
I think destroying a subwoofer because someone wrongly connected a VC-port to
his main out is more ugly then telling some developer that its wrong to just
connect to the first hw-port regardless of its type.
Actually these apps would still not be allowed to connect if the want to
connect their audio-output to the first hw-vc-port the same as if they wanted
to connect to the first midi-port...
On Sun, Sep 25, 2011 at 1:45 PM, Fons Adriaensen
<fons(a)linuxaudio.org>
wrote:
I don't
buy that. Only clients that need the new port type would have
to support it. You could as well say that MIDI ports confuse pure
audio clients - it's just not true.
some clients will look for PortIsPhysical. they do this with MIDI
already. they then try to connect to ports of the wrong type. JACK
prevents this. the clients remain disconnected. sure, they shouldn't auto-connect in this way. but
then, people
shouldn't kill each other either.
I wanted to do a real-world example of forbidding cars, but that would
probably not be political correct.
Have a nice week,
Arnold
9:45 p.m.
hint: the patch to add a new port type to JACK will involve on the
same order of magnitude number of characters as have already been used
in this email thread.
10:41 p.m.
On Sun, Sep 25, 2011 at 03:45:31PM -0400, Paul Davis wrote:
hint: the patch to add a new port type to JACK will
involve on the
same order of magnitude number of characters as have already been used
in this email thread.
Indeed. But why should anyone submit a patch for an idea that
has already been rejected, in particular if the rejection was
motivated in a way that implicitly condones crappy programming
instead of criticizing it ? What sort of excellence can you
expect if things are decided in that way ? (1)
Don't take this personally, but I've had enough of this sort
of negative argumentation for some time. I do remember the LV2
discussions (2), the Jack session ones, and some others. And
the result is that I go my own way, even if that leads to a
loss of synergy and benefit for all.
(1) Mediocrity.
(2) The real gem in that case was a remark that representing
the sample rate as a ratio would lead to inefficiency as it
required a (1, one) division.
Ciao,
--
FA
10:44 p.m.
On Sun, Sep 25, 2011 at 4:41 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Sep 25, 2011 at 03:45:31PM -0400, Paul Davis
wrote:
it wasn't rejected.
hint: the patch to add a new port type to JACK
will involve on the
same order of magnitude number of characters as have already been used
in this email thread.
Indeed. But why should anyone submit a patch for an idea that
has already been rejected, in particular if the rejection was
motivated in a way that implicitly condones crappy programming
instead of criticizing it ? What sort of excellence can you
expect if things are decided in that way ? (1) Don't take this personally, but I've had
enough of this sort
of negative argumentation for some time. I do remember the LV2
discussions (2), the Jack session ones, and some others. And
the result is that I go my own way, even if that leads to a
loss of synergy and benefit for all.
fair enough.
26 Sep
26 Sep
6:08 p.m.
On Sun, Sep 25, 2011 at 4:41 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Sep 25, 2011 at 03:45:31PM -0400, Paul Davis
wrote:
this is a reminder of the closing post from the last thread about this
subject. it came from you. to me it can be summarized as "a complete
control API would include both lower sample rate control signals and
timestamped events", which if true leads to my point about there being
a lack of consenus about the right way to tackle the issue, and as
usually happens with a project like jack, a lack of consensus *AND*
and a lack of any working patch means that things don't change.
neither of the two ideas was rejected. the subject is basically still open.
------------------------
On Sat, Feb 20, 2010 at 07:31:04AM +0100, torbenh wrote:
hint: the patch to add a new port type to JACK
will involve on the
same order of magnitude number of characters as have already been used
in this email thread.
Indeed. But why should anyone submit a patch for an idea that
has already been rejected, in particular if the rejection was
motivated in a way that implicitly condones crappy programming
instead of criticizing it ? What sort of excellence can you
expect if things are decided in that way ? (1)
Don't take this personally, but I've had enough of this sort
of negative argumentation for some time. I do remember the LV2
discussions (2), the Jack session ones, and some others. And
the result is that I go my own way, even if that leads to a
loss of synergy and benefit for all.
(1) Mediocrity.
(2) The real gem in that case was a remark that representing
the sample rate as a ratio would lead to inefficiency as it
required a (1, one) division. 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).
5:19 p.m.
Ok, so appart from the discussion on the second point of my mail (maybe
it was better posted to LAD, sorry for that), what about the first:
This seems an interesting idea I'd like to play
with - the problem is,
how can you do it in our linux-audio environment, where usually the
knob generates midi CC data? Is it possible with some tricks to
convert this to an audio signal (maybe way downsampled to not
uselessly waste CPU) pass it through rakarrack or ladspa plugins,
reconvert it to midi CC and have it control something?
i.e. if there's some hacky way to do it in the current JACK system? I
guess this could easily be done with the help of the usual suspects (sc,
pd), and I'll look in to it when I have some time (in sc I think I only
need to understand how to make an Ugen from the incoming midi data, and
then just play it with .ar instead of .kr... I'm more clueless on
the final audio signal -> midi conversion)... other ideas with other
tools?
renato
8:05 p.m.
Renato wrote:
Ok, so appart from the discussion on the second point
of my mail (maybe
it was better posted to LAD, sorry for that), what about the first:
I'd think that the outboard hardware is what decides that turning knob X
to position Y generates a MIDI event. I'd think that if you want to use
the actual raw voltage/current value that knob X is actually outputting,
you'd have to do that at the hardware end, not the event-receiving end.
But I suppose you could arbitrarily define MIDI event value 0 or 1 as
the beginning, and the current knob value as the end, and
programmatically generate some kind of audio signal. Or something like that.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
This seems an interesting idea I'd like to
play with - the problem is,
how can you do it in our linux-audio environment, where usually the
knob generates midi CC data? Is it possible with some tricks to
convert this to an audio signal (maybe way downsampled to not
uselessly waste CPU) pass it through rakarrack or ladspa plugins,
reconvert it to midi CC and have it control something?
i.e. if there's some hacky way to do it in the current JACK system? I
guess this could easily be done with the help of the usual suspects (sc,
pd), and I'll look in to it when I have some time (in sc I think I only
need to understand how to make an Ugen from the incoming midi data, and
then just play it with .ar instead of .kr... I'm more clueless on
the final audio signal -> midi conversion)... other ideas with other
tools? 
27 Sep
27 Sep
8:18 a.m.
I hoe that I'm not totally out of context,
but wouldn't that introduce latency to the control signal (AD/DA
conversion)?
Why would it be preferable over MIDI in first place?
cheers
Moshe
On Sun, Sep 25, 2011 at 8:13 PM, Renato <rennabh(a)gmail.com> wrote:
Hello, I've never used hardware that uses VC, but
sometime ago I had an
idea, that probably many others have allready exploited (never heard of
it though).
If a control signal is exactly the same as an audio signal,
just very lower in frequency, one could apply all the usual audio
effects to control signal. You could for example turn a knob, have the
signal it generates pass through a delay, reverb or whatever, and then
have it control something (like the frequency of a synth).
This seems an interesting idea I'd like to play with - the problem is,
how can you do it in our linux-audio environment, where usually the
knob generates midi CC data? Is it possible with some tricks to convert
this to an audio signal (maybe way downsampled to not uselessly waste
CPU) pass it through rakarrack or ladspa plugins, reconvert it to midi
CC and have it control something?
A more general thought: what about implementing a new type of generic
"control" signal in JACK, and having existing audio apps accept these
signals in their input? If you come to think of it, there's really no
difference (other than sample rate) between a control signal and an
audio signal, so there's no reason why one shouldn't be able to do DSP
on control signals.
cheers,
renato
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
12:12 p.m.
On Tue, 27 Sep 2011 09:18:50 +0300
Moshe Werner <moshwe(a)gmail.com> wrote:
I hoe that I'm not totally out of context,
but wouldn't that introduce latency to the control signal (AD/DA
conversion)?
I guess yes, but since it's a control signal, it probably wouldn't be
noticeable
Why would it be preferable over MIDI in first place?
well the idea was to do DSP on the signal with the usual tools (ladspa,
lv2, rakarrack etc.) which you can't do directly on MIDI. I.e. you could
do things like filtering, distortion, delay, reverb etc. on the control
signal, which you can't on MIDI.
cheers
renato
10:14 p.m.
Ok didn't think that way, but definitely sounds interesting.
On Tue, Sep 27, 2011 at 1:10 PM, Renato <rennabh(a)gmail.com> wrote:
On Tue, 27 Sep 2011 09:18:50 +0300
Moshe Werner <moshwe(a)gmail.com> wrote:
I hoe that I'm not totally out of context,
but wouldn't that introduce latency to the control signal (AD/DA
conversion)?
I guess yes, but since it's a control signal, it probably wouldn't be
noticeable
Why would it be preferable over MIDI in first
place?
well the idea was to do DSP on the signal with the usual tools (ladspa,
lv2, rakarrack etc.) which you can't do directly on MIDI. I.e. you could
do things like filtering, distortion, delay, reverb etc. on the control
signal, which you can't on MIDI.
cheers
renato
4602
days inactive
4604
days old
linux-audio-user@lists.linuxaudio.org
14 comments
6 participants
participants (6)
-
Arnold Krille -
david -
Fons Adriaensen -
Moshe Werner -
Paul Davis -
Renato