25 Sep
2011
25 Sep
'11
10:52 a.m.
Hi everyone,
I'm porting the AMS internal modules to LV2 plugins to be used in Ingen.
Small problem is, AMS uses VC (even the output of the VCOs that
produce sound) when Ingen uses PCM...
So far, my research seems to lead that a simple multiplication by 16
of the VC output should convert it to PCM, and vice-versa.
That doesn't seem right though, as I would think the sample rate
should be involved in this conversion!
Would somebody have any ideas?
Thanks in advance guys,
Aurélien
25 Sep
25 Sep
12:10 p.m.
On Sun, Sep 25, 2011 at 09:52:23AM +0100, Aurélien Leblond wrote:
I'm porting the AMS internal modules to LV2
plugins to be used in Ingen.
Small problem is, AMS uses VC (even the output of the VCOs that
produce sound) when Ingen uses PCM...
?? You seem to be confusing some things.
AMS modules can have 3 types of ins/outs
1. Audio in/out ports. These are just blocks of samples, same
as e.g. Jack buffers. Some call this 'PCM' but that is a
misnomer.
2. Control in/out ports. These are technically identical to
audio ports (full sample rate), but the signals carried
on them are normally not meant to be audio. How they are
interpreted depends on the module and the particular port.
Frequency control inputs can be linear or log, in the latter
case that means 1/octave. Gain controls can be linear or log,
there is AFAIK no fixed conversion factor for the latter. For
example the VCA module uses 80dB/1 in exponential mode, but
other gain controls may be different.
Control ports are audio rate, but most modules/plugins subsample
some or most of them. They either just use the first value in a
block, or recompute internal paramters based on the last value
in a block and then interpolate them linearly.
Since control signals are (at least officially) at audio rate,
LADPSPA plugins designed to be used in AMS (e.g. mine) will
declare their control inputs as audio inputs.
3. Input ports corresponding to GUI widgets. These are control rate,
read once per block. They can be int or float. For continuous values
the sliders of built-in modules are always linear, any log/exp
conversion is done internally. For plugins this is different, as
a LADSPA can request the host to use a log/exp slider.
Ciao,
--
FA
3:53 p.m.
On 09/25/2011 05:10 AM, Fons Adriaensen wrote:
On Sun, Sep 25, 2011 at 09:52:23AM +0100, Aurélien
Leblond wrote:
[snip]
I'm porting the AMS internal modules to LV2
plugins to be used in Ingen.
Small problem is, AMS uses VC (even the output of the VCOs that
produce sound) when Ingen uses PCM...
?? You seem to be confusing some things.
2. Control in/out ports. These are technically identical to
audio ports (full sample rate), but the signals carried
on them are normally not meant to be audio. How they are
[snip]
3. Input ports corresponding to GUI widgets. These are control rate,
read once per block. They can be int or float. For continuous values
[snip]
And I think part of the confusion is that LV2 calls #3 a "control port",
and doesn't currently have anything like #2.
On 09/25/2011 03:52 AM, Aurélien Leblond wrote:
So far, my research seems to lead that a simple
multiplication by 16
of the VC output should convert it to PCM, and vice-versa.
That doesn't seem right though, as I would think the sample rate
should be involved in this conversion!
If your the same dude I met on IRC doing this exact same thing... you
misunderstood what was said about 16. I was saying that[1] I've heard
that sometimes people implement CV ports at 1/16th the audio sample
rate. However it's simpler to just stick with the audio sample rate.
Also, in old-style analog synths the CV signal correspends to 1
Volt/octave and has a range (0.0, +inf).[2] In contrast, floating point
audio has a range of [-1.0, 1.0]. There is no relationship between a
control voltage signal (e.g. the position of a fader) and a PCM audio
signal.
-gabriel
[1] ...based on my understanding of some discussions here
[2] http://en.wikipedia.org/wiki/CV/Gate
3:28 p.m.
1. Audio in/out ports. These are just blocks of
samples, same
as e.g. Jack buffers. Some call this 'PCM' but that is a
misnomer.
2. Control in/out ports. These are technically identical to
audio ports (full sample rate), but the signals carried
on them are normally not meant to be audio. How they are
interpreted depends on the module and the particular port.
Frequency control inputs can be linear or log, in the latter
case that means 1/octave. Gain controls can be linear or log,
there is AFAIK no fixed conversion factor for the latter. For
example the VCA module uses 80dB/1 in exponential mode, but
other gain controls may be different.
Control ports are audio rate, but most modules/plugins subsample
some or most of them. They either just use the first value in a
block, or recompute internal paramters based on the last value
in a block and then interpolate them linearly.
Since control signals are (at least officially) at audio rate,
LADPSPA plugins designed to be used in AMS (e.g. mine) will
declare their control inputs as audio inputs.
Thanks, I think it makes things way clearer!
What's confusing me so far is that I ported the VCO2 module, but with
exactly the same setup, the VCO2 LV2 in Ingen sounds out of tune
compared to the one in AMS. I thought it was due to some kind of
needed convertion, but maybe I'll go back to my code to double check I
didn't make any mistakes!
By the way, the LADSPA plugins you are referring to, I suppose these
are the MCP ones?
Are you planning onto porting them to LV2 ones?
Aurélien
4:39 p.m.
On Sun, Sep 25, 2011 at 02:28:08PM +0100, Aurélien Leblond wrote:
By the way, the LADSPA plugins you are referring to, I
suppose these
are the MCP ones?
The MCP and VCO ones.
Are you planning onto porting them to LV2 ones?
No, they are designed for use within AMS - so some control ports
(those that should become connectors and not widgets) are at audio
rate.
Ciao,
--
FA
5:07 p.m.
By the way,
the LADSPA plugins you are referring to, I suppose these
are the MCP ones?
The MCP and VCO ones.
Are you planning onto porting them to LV2 ones?
No, they are designed for use within AMS - so some control ports
(those that should become connectors and not widgets) are at audio
rate. 
5:18 p.m.
On 09/25/2011 05:07 PM, Aurélien Leblond wrote:
There's nothing stopping you from using plugins with audio-rate control
ports in Ingen. The reduced rate of ladspa and lv2 control ports is good
for saving performance in cases where you don't need updates at full rate.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
No, they are
designed for use within AMS - so some control ports
> (those that should become connectors and not widgets) are at audio
> rate.
Ah pity, they would have been great with Ingen... 
11:11 p.m.
On Sun, 2011-09-25 at 17:18 +0200, Thorsten Wilms wrote:
On 09/25/2011 05:07 PM, Aurélien Leblond wrote:
There's nothing stopping you from using plugins with audio-rate control
ports in Ingen. The reduced rate of ladspa and lv2 control ports is good
for saving performance in cases where you don't need updates at full rate.
Yes, but not having the control sliders show up / work, and having those
plugins not work in other hosts (which is the problem with the LADSPA
plugins that do this) really sucks.
This problem was always the most blatant LADSPA inadequacy for modulars
to me...
-dr
No, they
are designed for use within AMS - so some control ports
> (those that should become connectors and not widgets) are at audio
> rate.
Ah pity, they would have been great with Ingen...
26 Sep
26 Sep
12:02 a.m.
On Sun, Sep 25, 2011 at 05:11:13PM -0400, David Robillard wrote:
This problem was always the most blatant LADSPA
inadequacy for modulars
to me...
At least LADSPA allows to do this (to have control inputs that are
at audio rate). And if a LADSPA plugin designed to work in AMS
(such as the MCP ones) doesn't make much sense in an environment
that assumes that audio rate == audio signal, so be it. There is
no rule that says a plugin must be usable in all hosts.
In particular, synth plugins (VCOs, VCFs, etc.) are fundamentally
different from general audio processing ones (EQ, dynamics, etc.).
This doesn't exclude the possibility that some may be useful in
both contexts.
One of the reasons for this is that 'multichannel' is not the same
as 'polyphonic'. For a polyphonic plugin (typically found in a
synthesis environment), the only data shared between voices are
the values of GUI widgets. Everything else, internal state and
control inputs that are not mapped to a GUI widget but appear as
a patchable port, is 'per voice'. It even makes sense to mark
each voice as 'active' or not so you don't waste CPU cycles
on inactive ones, and to distribute the per voice processing
over multiple CPUs.
For a multichannel plugin (typically found in a general audio
processing environment, e.g. a mixer) this is not the case: for
example the gain factor used by a multichannel compressor does
not depend only on the input level of the channel it is applied
to, but either on all channels, or on a fixed single one (as for
Ambisonics, or when using a sidechain input).
Another typical feature of multichannel processors is that the
the CPU cycles required for the 'per channel' part are a tiny
fraction of what is required for the 'common' part (for example
calculating interpolated internal parameter trajectories). Which
also means you wouldn't distribute channels over multiple CPUs.
This means that you can't just replicate a single channel plugin
- either you have specific versions for each channel count (not
a practical solution), or the plugin system has to explicitly
support the separation of the 'common' and 'per channel' code.
Ciao,
--
FA
12:20 a.m.
On Sun, 2011-09-25 at 22:02 +0000, Fons Adriaensen wrote:
On Sun, Sep 25, 2011 at 05:11:13PM -0400, David
Robillard wrote:
Sure. LADSPA and (core) LV2 are identical in this respect. They have
exactly the same port types. It is really ugly and inconvenient to use
audio ports as control ports though.
This problem was always the most blatant LADSPA
inadequacy for modulars
to me...
At least LADSPA allows to do this (to have control inputs that are
at audio rate). And if a LADSPA plugin designed to work in AMS
(such as the MCP ones) doesn't make much sense in an environment
that assumes that audio rate == audio signal, so be it. There is
no rule that says a plugin must be usable in all hosts. In particular, synth plugins (VCOs, VCFs, etc.) are
fundamentally
different from general audio processing ones (EQ, dynamics, etc.).
This doesn't exclude the possibility that some may be useful in
both contexts.
Yes, but many, if not most, are usable in both contexts. Filters of any
variety are the best examples.
One of the reasons for this is that
'multichannel' is not the same
as 'polyphonic'. For a polyphonic plugin (typically found in a
synthesis environment), the only data shared between voices are
the values of GUI widgets. Everything else, internal state and
control inputs that are not mapped to a GUI widget but appear as
a patchable port, is 'per voice'. It even makes sense to mark
each voice as 'active' or not so you don't waste CPU cycles
on inactive ones, and to distribute the per voice processing
over multiple CPUs.
A tricky one no one has yet tackled (anywhere) AFAIK.
For a multichannel plugin (typically found in a
general audio
processing environment, e.g. a mixer) this is not the case: for
example the gain factor used by a multichannel compressor does
not depend only on the input level of the channel it is applied
to, but either on all channels, or on a fixed single one (as for
Ambisonics, or when using a sidechain input).
Port "groups" and "roles" (within those groups) describe all this
kind
of thing nicely. This is simple, purely metadata stuff.
Another typical feature of multichannel processors is
that the
the CPU cycles required for the 'per channel' part are a tiny
fraction of what is required for the 'common' part (for example
calculating interpolated internal parameter trajectories). Which
also means you wouldn't distribute channels over multiple CPUs.
This means that you can't just replicate a single channel plugin
- either you have specific versions for each channel count (not
a practical solution), or the plugin system has to explicitly
support the separation of the 'common' and 'per channel' code.
I think there is more overlap between these cases than this implies, or
at least can be. A polyphonic synth *could* have a very large portion
of the processing time be common shared data.
There is probably an elegant solution that can cover 'replication' in
all cases. Any solution would require pretty significant compatibility
breaks, though. Maybe some day. We are stuck with single-channel audio
inputs and outputs. When I think about this sort of thing, I wish we
just had more "message" like ports, so we could add things like multiple
channels without having to completely change what you actually connect a
port pointer to. It also makes the question of whether or not to
replicate this control or that no longer a compatibility issue. It makes
a lot of things simple, as consistent computational models tend to do...
(All that said, replication doesn't seem all that pressing to me at the
moment, at least relatively speaking. Nobody's work is being held back
for lack of it that I know of.)
-dr
11:08 a.m.
On Sun, Sep 25, 2011 at 06:20:22PM -0400, David Robillard wrote:
I'd contest the 'most'. Can you give any more examples ?
For filters, only 'static' ones (only GUI controls, same
processing on all channels or voices) could be used in
both contexts. Once any parameter becomes per voice and
'voltage controlled' the similarity ends.
And even the purely static ones you'd want to schedule
differently. On a mixer you typically have a lot of
channel strips, each of them in most cases a linear
chain of processing units. It makes sense to keep the
elements of such chains together and schedule them on
the same worker thread. In a polyphonic setting voices
are independent, typical patches are not linear, and
it makes much more sense to schedule per voice.
A universal plugin standard should support these
different modes, which means separating common and
per voice/channel parts. Even if it does I would not
expect any particular plugin to support both modes.
You can probably get a better plugin by designing it
for a specific application.
In particular,
synth plugins (VCOs, VCFs, etc.) are fundamentally
different from general audio processing ones (EQ, dynamics, etc.).
This doesn't exclude the possibility that some may be useful in
both contexts.
Yes, but many, if not most, are usable in both contexts. Filters of any
variety are the best examples. A tricky one no one has yet tackled (anywhere) AFAIK.
Because if you start to analyse these things (and
there are many more aspects to it) it becomes clear
that current plugin standards completely ignore all
of this, they get in the way rather than provide the
necessary hooks, and you better start from zero.
Just consider the following list:
- 'Voltage control'
- MIDI control
- OSC control
- Save/restore settings
- Automation
Traditionally a host will try to do any of them
using only the set of 'control ports' exposed by
a plugin, or by hooking into the GUI <-> DSP
communication if the plugin has its own GUI.
But the requirements for each of these are quite
different and usually in conflict.
There is much more to it than some metadata.
I think there is more overlap between these cases than
this implies, or
at least can be. A polyphonic synth *could* have a very large portion
of the processing time be common shared data.
As long as voices are independent there isn't much to share
except e.g. big lookup tables as used in some oscillators.
Even if the host replicates the plugin for each voice (which
it could do) you'd want the instances to share such data.
Which again requires some support from the plugin standard.
There is another thing missing in current synthesis hosts
(AMS, and AFAIK also Ingen): an explicit definition of the
point where a polyphonic patch mixes its voices into a single
audio signal. Some processing should be done after this point,
e.g. reverb and some other effects. So if you do this in a
plugin, it becomes 'polyphonic' at one side, and 'multichannel'
at the other. Some more metadata required...
Ciao,
--
FA
3:13 p.m.
On 26/09/11 05:08 AM, Fons Adriaensen wrote:
Right.
On Sun, Sep 25, 2011 at 06:20:22PM -0400, David
Robillard wrote:
I'd contest the 'most'. Can you give
any more examples ?
For filters, only 'static' ones (only GUI controls, same
processing on all channels or voices) could be used in
both contexts. Once any parameter becomes per voice and
'voltage controlled' the similarity ends.
I am not considering per voice at
all since we don't have that
technology anyway.
"Once any parameter becomes 'voltage controlled'..."
It's still a parameter a user might want to set manually if it's not
being "voltage controlled", and it's still a parameter that should be
presented sensibly in a non-modular host like a DAW or effects rack.
In
particular, synth plugins (VCOs, VCFs, etc.) are fundamentally
different from general audio processing ones (EQ, dynamics, etc.).
This doesn't exclude the possibility that some may be useful in
both contexts.
Yes, but many, if not most, are usable in both contexts. Filters of
any
variety are the best examples. Because if you start to analyse these things (and
there are many more aspects to it) it becomes clear
that current plugin standards completely ignore all
of this, they get in the way rather than provide the
necessary hooks, and you better start from zero.
Just consider the following list:
- 'Voltage control'
- MIDI control
- OSC control
- Save/restore settings
- Automation
Traditionally a host will try to do any of them
using only the set of 'control ports' exposed by
a plugin, or by hooking into the GUI<-> DSP
communication if the plugin has its own GUI.
But the requirements for each of these are quite
different and usually in conflict.
MIDI and OSC are more or less logistically
equivalent. There are only
really two fundamentally different things here with respect to how the
plugin itself works: control via messages (MIDI/OSC) and control via
signals (voltage control).
I think there
is more overlap between these cases than this implies, or
at least can be. A polyphonic synth *could* have a very large portion
of the processing time be common shared data.
As long as voices are independent
there isn't much to share
except e.g. big lookup tables as used in some oscillators.
Even if the host replicates the plugin for each voice (which
it could do) you'd want the instances to share such data.
Which again requires some support from the plugin standard. There is another thing missing in current synthesis
hosts
(AMS, and AFAIK also Ingen): an explicit definition of the
point where a polyphonic patch mixes its voices into a single
audio signal. Some processing should be done after this point,
e.g. reverb and some other effects. So if you do this in a
plugin, it becomes 'polyphonic' at one side, and 'multichannel'
at the other. Some more metadata required...
Ingen allows the user to set each module as either polyphonic or not.
Mixing down is done wherever necessary (i.e. wherever a poly output is
connected to a mono input). I think maybe this is a bit more fine
grained than is useful though, and have considered having a single
well-defined (internal) module that mixes down as you've described, or
maybe just not allowing poly and mono in a single patch at all... Making
sure things like reverb etc. are put after the polyphonic stuff is a
user decision in either case, though.
With respect to plugins, supporting poly/multichannel would inherently
be a per-port thing, i.e. specific port(s) would be labeled as
polyphonic, or multi-channel, so I don't think such a plugin would cause
any trouble.
-dr
Ciao,
25 Sep
25 Sep
11:50 p.m.
New subject: LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
Here is a quick extension for "CV Ports", i.e. audio ports with control
semantics:
http://lv2plug.in/ns/ext/cv-port/
-dr
26 Sep
26 Sep
12:22 p.m.
New subject: LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
2011/9/26 David Robillard <d(a)drobilla.net>et>:
Here is a quick extension for "CV Ports",
i.e. audio ports with control
semantics:
http://lv2plug.in/ns/ext/cv-port/
Argh.... sorry for not having followed the discussion when it took
place, but I have to say I really dislike this extension.
The problem is that it can easily go against the "graceful degrading
configuration" concept of LV2. E.g., suppose writing a varispeed
plugin that takes the amount of delay as a control input - you will
end up writing two versions, one using CV ports and another using
normal control ports, if you want to support both kinds of hosts.
IMO it could be better done like this: cv:CVPort to be a subclass of
lv2:ControlPort and a feature URI to be defined.
Stefano
3:27 p.m.
New subject: LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
On 26/09/11 06:22 AM, Stefano D'Angelo wrote:
2011/9/26 David Robillard<d(a)drobilla.net>et>:
Meh, no big deal, it's just a draft. Those big red letters aren't for
nothing. :)
Here is a quick extension for "CV
Ports", i.e. audio ports with control
semantics:
http://lv2plug.in/ns/ext/cv-port/
Argh.... sorry for not having followed the
discussion when it took
place, but I have to say I really dislike this extension. The problem is that it can easily go against the
"graceful degrading
configuration" concept of LV2. E.g., suppose writing a varispeed
plugin that takes the amount of delay as a control input - you will
end up writing two versions, one using CV ports and another using
normal control ports, if you want to support both kinds of hosts.
or just don't, and expect hosts to implement this trivial extension.
Backwards compatibility would be nice though...
IMO it could be better done like this: cv:CVPort to be
a subclass of
lv2:ControlPort and a feature URI to be defined.
I suppose this could work, since theoretically the port is still
connected to a buffer with a single float as lv2:ControlPort dictates.
Subclass is academic since most hosts don't care anyway, the port would
have to literally have both types listed. The only way for this to be
feasible is if the host supports said feature, it guarantees that such
ports will ALWAYS be connected to a full audio-rate buffer (otherwise
you need some mechanism to say which it's connected to and things get
too complex). This is slightly more complex, but not too bad, and only
complex for hosts that support CV... good idea.
<pedantry>
It's debatable whether or not this violates the spec:
"Hosts that do not support a specific port class MUST NOT instantiate
the plugin, unless that port has the connectionOptional property set"
This is ambiguous. We might want to reword that slightly in the next
revision to explicitly state that hosts can instantiate if they
understand *some subset* of the port types that describes a port type
they support, i.e. unknown additional types can be ignored. This implies
new port types can't modify the definition of others, which is good and
should be explicit anyway.
</pedantry>
-dr
9:46 p.m.
New subject: LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
2011/9/26 David Robillard <d(a)drobilla.net>et>:
<pedantry>
It's debatable whether or not this violates the spec:
"Hosts that do not support a specific port class MUST NOT instantiate the
plugin, unless that port has the connectionOptional property set"
This is ambiguous. We might want to reword that slightly in the next
revision to explicitly state that hosts can instantiate if they understand
*some subset* of the port types that describes a port type they support,
i.e. unknown additional types can be ignored. This implies new port types
can't modify the definition of others, which is good and should be explicit
anyway.
</pedantry>
<useless-rant>
This is IMO unfortunate of the LV2 spec, a host does not only have to
check for supported features, but also go through all ports and check
type and connectionOptional. We could just have features for port
types defined in extensions...
</useless-rant>
Stefano
10:37 p.m.
New subject: LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)
On Mon, 2011-09-26 at 09:27 -0400, David Robillard wrote:
Actually, on second thought, while I dislike making anything at all
complex for this ostensibly simple functionality, I think if a feature
is going to be involved anyway it might be best to allow the host to
explicitly specify which type each port is connected to. Since this is
intended for modular hosts, the host would typically inform the plugin
which based on what the port is connected to.
The feature would basically allow the plugin to expose an additional
function which the host could call to inform the plugin if the CV port
is connected to control or audio data.
The cost is complexity in the plugin, namely a CV supporting plugin
would have to keep a type flag around for all CV ports to know which it
is connected to (a simple macro or inline function can make the actual
reading simple). This incurs a minor branch cost (one per CV port per
cycle).
Thoughts?
-dr
On 26/09/11 06:22 AM, Stefano D'Angelo wrote:
[...]
IMO it could
be better done like this: cv:CVPort to be a subclass of
lv2:ControlPort and a feature URI to be defined.
[...]
The only way for this to be feasible is if the host supports said
feature, it guarantees that such ports will ALWAYS be connected to a
full audio-rate buffer (otherwise you need some mechanism to say which
it's connected to and things get too complex).
25 Sep
25 Sep
11:09 p.m.
On Sun, 2011-09-25 at 16:07 +0100, Aurélien Leblond wrote:
Ah pity, they would have been great with Ingen...
As mentioned earlier, LV2 needs / will soon get a CV port extension.
This is very simple (just need to define a type that's identical to an
audio port code-wise, but is to be used as a control and has
min/max/default predicates and such). Use
http://lv2plug.in/ns/ext/cv-port#CVPort as the port type, I guess.
That's pretty much it.
(We could talk about variable rates and whatever other fancy things all
day, but that makes things vastly more complicated for what seems to be
to be of very little benefit, particularly in this SIMD world of
plentiful RAM. KISS.)
-dr
By the way, the LADSPA plugins you are referring to, I
suppose these
are the MCP ones?
The MCP and VCO ones.
Are you planning onto porting them to LV2 ones?
No, they are designed for use within AMS - so some control ports
(those that should become connectors and not widgets) are at audio
rate.
11:01 p.m.
On Sun, 2011-09-25 at 14:28 +0100, Aurélien Leblond wrote:
The note builtin in Ingen uses Hz for frequency. Anything else is
completely insane :)
There is a converter plugin in 'omins' which I need to port to LV2 as
well one of these days...
-dr
1. Audio in/out
ports. These are just blocks of samples, same
as e.g. Jack buffers. Some call this 'PCM' but that is a
misnomer.
2. Control in/out ports. These are technically identical to
audio ports (full sample rate), but the signals carried
on them are normally not meant to be audio. How they are
interpreted depends on the module and the particular port.
Frequency control inputs can be linear or log, in the latter
case that means 1/octave. Gain controls can be linear or log,
there is AFAIK no fixed conversion factor for the latter. For
example the VCA module uses 80dB/1 in exponential mode, but
other gain controls may be different.
Control ports are audio rate, but most modules/plugins subsample
some or most of them. They either just use the first value in a
block, or recompute internal paramters based on the last value
in a block and then interpolate them linearly.
Since control signals are (at least officially) at audio rate,
LADPSPA plugins designed to be used in AMS (e.g. mine) will
declare their control inputs as audio inputs.
Thanks, I think it makes things way clearer!
What's confusing me so far is that I ported the VCO2 module, but with
exactly the same setup, the VCO2 LV2 in Ingen sounds out of tune
compared to the one in AMS. I thought it was due to some kind of
needed convertion, but maybe I'll go back to my code to double check I
didn't make any mistakes!
26 Sep
26 Sep
3:37 p.m.
On Sun, Sep 25, 2011 at 10:01 PM, David Robillard <d(a)drobilla.net> wrote:
On Sun, 2011-09-25 at 14:28 +0100, Aurélien Leblond
wrote:
The note builtin in Ingen uses Hz for frequency. Anything else is
completely insane :)
There is a converter plugin in 'omins' which I need to port to LV2 as
well one of these days...
Hi David,
Could you let me know where in Omins it is?
I can port this for you... One plugin to create won't kill me (and I
start to enjoy it anyway!)
Aurélien
1. Audio
in/out ports. These are just blocks of samples, same
as e.g. Jack buffers. Some call this 'PCM' but that is a
misnomer.
2. Control in/out ports. These are technically identical to
audio ports (full sample rate), but the signals carried
on them are normally not meant to be audio. How they are
interpreted depends on the module and the particular port.
Frequency control inputs can be linear or log, in the latter
case that means 1/octave. Gain controls can be linear or log,
there is AFAIK no fixed conversion factor for the latter. For
example the VCA module uses 80dB/1 in exponential mode, but
other gain controls may be different.
Control ports are audio rate, but most modules/plugins subsample
some or most of them. They either just use the first value in a
block, or recompute internal paramters based on the last value
in a block and then interpolate them linearly.
Since control signals are (at least officially) at audio rate,
LADPSPA plugins designed to be used in AMS (e.g. mine) will
declare their control inputs as audio inputs.
Thanks, I think it makes things way clearer!
What's confusing me so far is that I ported the VCO2 module, but with
exactly the same setup, the VCO2 LV2 in Ingen sounds out of tune
compared to the one in AMS. I thought it was due to some kind of
needed convertion, but maybe I'll go back to my code to double check I
didn't make any mistakes!
4:11 p.m.
On 09/26/2011 03:37 PM, Aurélien Leblond wrote:
Hi David,
Could you let me know where in Omins it is?
Well, not David, but:
http://svn.drobilla.net/lad/trunk/omins/src/hz_voct_4200.c
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
4:15 p.m.
Hi David,
Could you let me know where in Omins it is?
I can port this for you... One plugin to create won't kill me (and I
start to enjoy it anyway!)
Aurélien
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Just watch out, some of them are really crappy (cough, the ones coded
by me. cough.) ;)
Loki
4881
days inactive
4882
days old
linux-audio-dev@lists.linuxaudio.org
21 comments
7 participants
participants (7)
-
Aurélien Leblond -
David Robillard -
Fons Adriaensen -
Gabriel Beddingfield -
Loki Davison -
Stefano D'Angelo -
Thorsten Wilms