25 Jan
2011
25 Jan
'11
5:50 p.m.
Version 1.2 of IR, an LV2 convolution reverb plugin has just been released.
This release is the result of many hours of stress-testing, and corrects some
small but unpleasant problems you may have run into while using an earlier
version. IR 1.2 is intended to be production quality software you can rely on.
Please do upgrade to this version.
Changes:
* fix ir.ttl typo: "doap:license" instead of "doap:licence"
* visual feedback of the progress of resampling operations
* resampling operations are interruptible; you can no longer crash
the plugin by deleting it while resampling a long impulse file
* correct GTK2 version requirement and check it in the Makefile:
at least GTK 2.16 is needed
Source code is available from the usual webpage:
http://factorial.hu/plugins/lv2/ir
I wist to thank everyone who provided me with valuable feedback.
Have fun,
Tom
25 Jan
25 Jan
5:52 p.m.
On Tue, Jan 25, 2011 at 11:50 AM, Tom Szilagyi <tomszilagyi(a)gmail.com> wrote:
Version 1.2 of IR, an LV2 convolution reverb plugin
has just been released.
This release is the result of many hours of stress-testing, and corrects some
small but unpleasant problems you may have run into while using an earlier
version. IR 1.2 is intended to be production quality software you can rely on.
Please do upgrade to this version.
Fantastic! IR is my favorite plugin right now!
--
Brett W. McCoy -- http://www.electricminstrel.com
------------------------------------------------------------------------
"In the rhythm of music a secret is hidden; If I were to divulge it,
it would overturn the world."
-- Jelaleddin Rumi
26 Jan
26 Jan
1:02 p.m.
On 01/25/2011 05:50 PM, Tom Szilagyi wrote:
Version 1.2 of IR, an LV2 convolution reverb plugin
has just been released.
This release is the result of many hours of stress-testing, and corrects some
small but unpleasant problems you may have run into while using an earlier
version. IR 1.2 is intended to be production quality software you can rely on.
Please do upgrade to this version.
Changes:
* fix ir.ttl typo: "doap:license" instead of "doap:licence"
* visual feedback of the progress of resampling operations
* resampling operations are interruptible; you can no longer crash
the plugin by deleting it while resampling a long impulse file
* correct GTK2 version requirement and check it in the Makefile:
at least GTK 2.16 is needed
Source code is available from the usual webpage:
http://factorial.hu/plugins/lv2/ir
since it's based on zita-convolver: did you also use the multi-threaded
partitioned convolution approach from jconvolver? if so, how does IR
behave in freewheeling mode?
i'm asking because jconvolver is known to have problems with the timing
of its non-jack helper threads in freewheeling mode, which has finally
bitten me a few days ago (haven't had problems with it before).
jconvolver is nice enough to halt the entire graph (at least with
tschack), so it's always obvious there was a problem.
i just want to make sure that *if* IR fails in freewheeling, it will
fail in some obvious way.
1:29 p.m.
2011/1/26 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
since it's based on zita-convolver: did you also use the multi-threaded
partitioned convolution approach from jconvolver?
Hi Jörn,
I'm not sure about the mentioned approach, since I'm not familiar with
the jconvolver source, only zita-convolver (and only from a user
p.o.v; haven't modified it). So I don't know that this multi-threaded
approach you mention is something jconvolver actually does, or is it
just the usual workings of zita-convolver (which I use in a really
simple manner).
I will look at the jconvolver source to educate myself about said
approach when I have a bit of free time.
if so, how does IR behave in freewheeling mode?
As usual: it works for me 10 out of 10 times (at least for what I do
and how I work), but YMMV. I must admit that I don't use freewheeling
that much, but some test passes with various projects (some simple and
some big) on two machines, one older single processor and one fairly
recent quad core (both 64 bit), indicated no problems. Of course this
means nothing at all in this case.
i'm asking because jconvolver is known to have problems with the timing of
its non-jack helper threads in freewheeling mode, which has finally bitten
me a few days ago (haven't had problems with it before). jconvolver is nice
enough to halt the entire graph (at least with tschack), so it's always
obvious there was a problem.
i just want to make sure that *if* IR fails in freewheeling, it will fail in
some obvious way.
That would be definitely nice but currently missing. I would say that
if there is a problem with jconvolver, IR most probably also has this
problem.
I tend to listen to what I commit, though, so I bounce in realtime.
Tom
1:41 p.m.
Am Mittwoch, den 26.01.2011, 13:29 +0100 schrieb Tom Szilagyi:
2011/1/26 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
It's zita-convolver who create the multi-threaded partitioned
convolution threads, in that sense jconvolver is a front-end like IR or
like we do in guitarix.
greats hermann
since it's based on zita-convolver: did you also use the multi-threaded
partitioned convolution approach from jconvolver?
Hi Jörn,
I'm not sure about the mentioned approach, since I'm not familiar with
the jconvolver source, only zita-convolver (and only from a user
p.o.v; haven't modified it). So I don't know that this multi-threaded
approach you mention is something jconvolver actually does, or is it
just the usual workings of zita-convolver (which I use in a really
simple manner).
I will look at the jconvolver source to educate myself about said
approach when I have a bit of free time.
if so, how does IR behave in freewheeling mode?
As usual: it works for me 10 out of 10 times (at least for what I do
and how I work), but YMMV. I must admit that I don't use freewheeling
that much, but some test passes with various projects (some simple and
some big) on two machines, one older single processor and one fairly
recent quad core (both 64 bit), indicated no problems. Of course this
means nothing at all in this case.
i'm asking because jconvolver is known to have problems with the timing of
its non-jack helper threads in freewheeling mode, which has finally bitten
me a few days ago (haven't had problems with it before). jconvolver is nice
enough to halt the entire graph (at least with tschack), so it's always
obvious there was a problem.
i just want to make sure that *if* IR fails in freewheeling, it will fail in
some obvious way.
That would be definitely nice but currently missing. I would say that
if there is a problem with jconvolver, IR most probably also has this
problem.
I tend to listen to what I commit, though, so I bounce in realtime.
Tom
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev 
27 Jan
27 Jan
5:20 p.m.
On Wed, Jan 26, 2011 at 01:29:17PM +0100, Tom Szilagyi wrote:
--
torben Hohn
2011/1/26 Jörn Nettingsmeier
<nettings(a)folkwang-hochschule.de>de>:
http://www.mail-archive.com/linux-audio-dev@lists.linuxaudio.org/msg06888.h…
the approach in the patch is not 100% RT clean.
however, the comments indicate where an atomic integer needs to be
applied to make it clean.
however... its highly unlikely that the RT thread blocks on that mutex.
and even if thats the case... its pretty unlikely that this would cause
an xrun.
please get this stuff fixed.
for IR, we probably need an lv2 extension which switches plugins into
freewheeling mode.
i am unsure, how you determine the correct priority for the threads.
we need an extension for this also.
should be very trivial.
since it's based on zita-convolver: did you also use the multi-threaded
partitioned convolution approach from jconvolver?
Hi Jörn,
I'm not sure about the mentioned approach, since I'm not familiar with
the jconvolver source, only zita-convolver (and only from a user
p.o.v; haven't modified it). So I don't know that this multi-threaded
approach you mention is something jconvolver actually does, or is it
just the usual workings of zita-convolver (which I use in a really
simple manner).
I will look at the jconvolver source to educate myself about said
approach when I have a bit of free time. if so, how does IR behave in freewheeling mode?
As usual: it works for me 10 out of 10 times (at least for what I do
and how I work), but YMMV. I must admit that I don't use freewheeling
that much, but some test passes with various projects (some simple and
some big) on two machines, one older single processor and one fairly
recent quad core (both 64 bit), indicated no problems. Of course this
means nothing at all in this case.
i'm asking because jconvolver is known to have problems with the timing of
its non-jack helper threads in freewheeling mode, which has finally bitten
me a few days ago (haven't had problems with it before). jconvolver is nice
enough to halt the entire graph (at least with tschack), so it's always
obvious there was a problem.
i just want to make sure that *if* IR fails in freewheeling, it will fail in
some obvious way.
That would be definitely nice but currently missing. I would say that
if there is a problem with jconvolver, IR most probably also has this
problem.
I tend to listen to what I commit, though, so I bounce in realtime.
Tom
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
4847
days inactive
4849
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
Brett McCoy -
hermann -
Jörn Nettingsmeier -
Tom Szilagyi -
torbenh