> I think providing synchronous control events, with 'future' values (at
> least some distance L in the future) is the way to get that. Let's
> pretend that the Ultimate Plugin Interface (UPI) 1.0 exists, works this
> way, is stable and unmalleable, and all you have to work with to
> deliver
> your product (a plugin).
>
> >From the plugin author perspective: is there anything that is
> *impossible* to do correctly?
>
> -dr
I believe it simply impossible to reliable deliver 'future' parameter
values.
Even when the automation is pre-recorded. E.g. smoothly ramping up a
parameter over 1 second. You can't say to the plugin 'ramp this parameter
over 1 second' - because partway through the 'ramp' the user can reposition
the playback to another part of the song, or loop a section, or change the
tempo, or hit 'Stop'. Any attempt to predict the future like that leads to
kludgy hacks.
Now you can say to the plugin 'process 100 samples' while specifying the
parameter value at sample# 0 and also at sample# 99. That is how to specify
a precise ramp (or section of a longer ramp) without providing future
parameter values. Apologies if that's what you meant. (I classify 'future'
values in this example as being later than sample #99 ).
Best Regards,
Jeff
> From: Fons Adriaensen <fons(a)linuxaudio.org>
> Subject: Re: [LAD] Plugin buffer size restrictions
> On Mon, May 28, 2012 at 06:05:20PM +0300, Stefano D'Angelo wrote:
>
> > IMO it's easily said: if control rate < audio rate it's plugin's
> > responsibility, otherwise the host feeds upsampled/filtered control
> > signals at audio rate to the plugin and all problems evaporate...
>
> The don't evaporate, they explode.
>
> Take a filter plugin. Calculating the actual filter coefficients from
> the 'user' parameters (frequency, gain, etc..) can easily be
> 10..1000 times more complex than actually using those coefficients to
> process one sample. So you really don't want to do that at the audio
> sample rate.
True, But with synths at least, recalculating the filter at audio rate is
routine these days. Admittedly we are pre-calculating the full range of
coefficients in advance.
You do get *very* nice filter sweeps and blips at full audio-rate
modulation.
Best Regards,
Jeff
Hi!
I'm CC'ing this to LAD and jack-devel with reply-to set to jack-devel,
hope the listservers keep the header fields intact.
Though it reads jackd1 there, it also affects jackd2.
No action has been taken, yet, but I tend to agree with the bug report
and (temporarily) disable celt support in both packages.
The older celt versions are about to vanish, so neither Debian nor
Ubuntu will provide it within one year from now or so.
I haven't followed the Opus discussion recently, but it seems the CELT
support in both jackds needs to be replaced by Opus.
The Wheezy freeze is scheduled for "mid June", so removing CELT-0.7 is
likely to happen within the next weeks.
So as a warning to all users, it looks like Debian and Debian-based
distros are losing CELT support in netjack until somebody steps up and
ports the code to Opus.
Cheers
-------- Original Message --------
Subject: Bug#674651: Please disable celt support in jack
Resent-Date: Sat, 26 May 2012 12:36:50 +0000
Resent-From: Ron <ron(a)debian.org>
Resent-To: debian-bugs-dist(a)lists.debian.org
Resent-CC: Debian Multimedia Maintainers
<pkg-multimedia-maintainers(a)lists.alioth.debian.org>
Date: Sat, 26 May 2012 21:28:19 +0930
From: Ron <ron(a)debian.org>
Reply-To: Ron <ron(a)debian.org>, 674651(a)bugs.debian.org
To: Debian Bug Tracking System <submit(a)bugs.debian.org>
Package: jackd1
Version: 1:0.121.3+20120418git75e3e20b-1
Severity: normal
Hi,
We're planning on removing the celt package from Wheezy, since we now have
a stable release of Opus that people can really use. Please disable celt
in jack so that we can move ahead with doing that before the freeze.
If you can and wish to enable Opus support, that would be great, but for
now we're mostly concerned with not shipping an obsolete celt version for
another whole release cycle.
Thanks!
Ron
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers(a)lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-main…
> I assume that computing parameter trajectories basically means
> interpolating, and that inevitably introduces some latency.
That's a key point. Interpolating any sampled signal introduces latency.
> let the host pass a limited number of future parameter samples at each
> run() (could be negotiated at instantiation time), so that the plugin
> doesn't have to add latency to the audio streams in any case. Would be
> only supported by "offline hosts". If the block sizes are variable,
> future block sizes should be passed as well (argh?). But I don't know
> if this really makes sense or has downsides... ideas, folks?
I *really* hate this idea.
I play my MIDI keyboard into my DAW, perhaps while using my Mod-Wheel, or
artistically using the filter-cuttoff parameter...I hit record...stop..
Then I push 'offline render'.
You would say - shift all my parameter events earlier in time and render
the result to disk? It's going to sound different. The timing will be
wrong. A DAW is like a tape recorder. Playback or offline rendering should
result in an identical performance surely?.
Why are you selectively shifting some musical events in time but not
others, why not note-ons too?
You can't provide live MIDI playing 'in advance', you can't prove parameter
updates in advance, just like you can't provide live audio in advance. If
the plugin wants 'future' data to interpolate stuff, it needs to introduce
latency. A good host will compensate for latency if the plugin API supports
that.
Parameters aren't special, they don't require any different handling than
MIDI. What's the difference between a MIDI controller tweaking the filter
cuttoff, or directly tweaking the parameter? Nothing. They both need
smoothing, they both need interpolating, they both will have latency. Don't
overcomplicate it.
Jeff
Greetings:
The problem: When I build Kdenlive for my Arch 64 system it compiles
without problems and starts up okay. After that the sluggishness of its
response is almost unbearable. For example, I've timed up to 10 seconds
between a mouse click and the resulting action, e.g. right-click to Add
Clip, and everything stalls badly when the program is calculating audio
or video thumbnails. Response time gets better after running the program
for a while, but getting it going is rather frustrating.
I've already searched Google and asked about the problem on the Kdenlive
forum and got no useful replies, hence my request here. Some of you use
Arch systems, and some of you know Qt well enough that maybe you can
advise me on this problem. (I'm hoping for a relatively simple solution,
of course).
Incidentally, the problem occurs with Arch's packaged Kdenlive and the
binary I compile with the build script. I just upgraded both, the
problem is still there. Other large Qt apps don't have the problem, e.g.
QTractor. The problem is also absent with Kdenlive on my 32-bit machines.
Btw, video is an nVidia GeForce 7600 GS, with nVidia's driver.
Best,
dp
Maybe this is of interest to one or the other :D
Flo
-------- Original Message --------
Subject: [music-dsp] ANN: Book: The Art of VA Filter Design
Date: Fri, 25 May 2012 10:54:25 +0200
From: Vadim Zavalishin <vadim.zavalishin(a)native-instruments.de>
Reply-To: A discussion list for music-related DSP
<music-dsp(a)music.columbia.edu>
To: A discussion list for music-related DSP <music-dsp(a)music.columbia.edu>
Hi all
This is kind of a cross-announcement from KVRAudio, but since there are
probably a number of different people on this list, I thought I'd
announce it here as well. Get it here:
http://ay-kedi.narod2.ru/VAFilterDesign.pdfhttp://images-l3.native-instruments.com/fileadmin/ni_media/downloads/pdf/VA…http://www.discodsp.net/VAFilterDesign.pdf (thanks to "george" for
mirroring)
There is a discussion thread at
http://www.kvraudio.com/forum/viewtopic.php?t=350246
Regards,
Vadim
--
Vadim Zavalishin
Software Integration Architect | R&D
Tel +49-30-611035-0
Fax +49-30-611035-2600
NATIVE INSTRUMENTS GmbH
Schlesische Str. 29-30
10997 Berlin, Germany
http://www.native-instruments.com
Registergericht: Amtsgericht Charlottenburg
Registernummer: HRB 72458
UST.-ID.-Nr. DE 20 374 7747
Geschaeftsfuehrung: Daniel Haver (CEO), Mate Galic
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsphttp://music.columbia.edu/mailman/listinfo/music-dsp
Hi all,
I am trying to wrap my head around the OSC interface to FAUST and am trying
to get the noise.dsp from the examples to respond to OSC messages. I have
tried sending it things like "/hello" and "/1/slider1 s 'hello'" and
"/hello f 1.0" on port 5010 while listening on 5011 and 5012 to no avail. I
must be completely missing something here but what exactly am I supposed to
send when it says "a hello message" in the docs? Could someone just go
through all the simple steps of an OSC "hello world" in FAUST?
Kind Regards,
Kaspar
Hi all. Just returned from military services (mandatory period).
It is likely, that i was somehow unsubscribed from list.
In summary, proposed changes are joined in two parts:
1. A few advances for freewheel mode: waiting wheel and per client
free/waiting wheel mode.
2. Get support for any count of "rooms", as they are called in LADISH
therminology, but IMHO, a bit more flexible.
Waiting wheel.
Like freewheel, but doesn't speed up system. When performance is
enough, behave like without any mode (produce sound). And only when it
is not enough, automatically free wheel, until performance is enough
again.
Per client time wheel management.
Clients could be joined into groups, where they have own time flow and
may interact as they are not in free/waiting wheel mode (pass
sound/MIDI each to others).
Other proposals, in two words:
- Ability to change master client (for now it is audio card) on the fly.
- Attaching of audio devices as clients with ability to change driver
and its settings for each (i mean - for all devices; this feature
should go with previous item).
Now about sctucture.
Some components are plugins, which are like LADSPA / LV2 / Other kinds
of audio plugins, but are optimized for use only on JACK (in short,
they are JACK modules).
JACK components:
* single plugin shell (types: plugin host, jack / alsa app) - just to
load other plugins as audio applications, connecting them to other
audio systems, like alsa or other jack instance, like jack app.
* Patchbay (types: plugin host, plugin). Master instance should
be ran by already called plugin shell. Other instances may be loaded
as plugins (making more rooms), or as jack applications. Time wheel
mode changes affect all dependent clients, inluding other patchbays.
* JACK app interface (plugin)
* Adapter for other types of audio plugins (LADSPA, LV2, and
so on). As you can see, such jack implementation may be jack app
itself, and so - it is good to use existing work just as plugin host
(like AMS, Ingen, Jost).
Such jack structure should allow easy implementation of both multiroom
session managers, like LADISH (which is forced for now to implement it
by self) and even allow nested sessions: i'm thinking about universal
modular session manager, which could be used as user session manager,
but also allow nested desktop sessions, and could be expanded by
plugins, adding integration to various systems, like X11 (to manage
windows), jack / alsa (no comments needed) and so on.
It's not clear to me what is legal for an LV2 plugin to do with an input
control port. Once the input port has been read, is it acceptable to use
that location in memory as temporary storage in the "run" method? Is it
the host's responsibility to re-fill the value of the parameter before
every run call? Is it the plugin's responsibility to keep input-ports
bit-exactly the same?
What about transformations of the input which leave the value logically the
same? For example, normalizing boolean inputs the values 0 and 1?
The <http://lv2plug.in/ns/lv2core/#InputPort>
documentation<http://lv2plug.in/ns/lv2core/#Port>is silent on this
matter.
Jeremy