On Mon, Oct 22, 2012 at 02:31:35PM +0200, Stéphane Letz wrote:
You can use semas on OSX, you'll need to use sem_open API instead of sem_init.
Using here: sem_open, sem_post/sem_wait, sem_unlink/sem_close with success
(In Faust Work Stealing Scheduler code). And semas are actually a slight
On Mon, Oct 22, 2012 at 9:03 AM, Stéphane Letz l...@grame.fr wrote:
Le 22 oct. 2012 à 14:50, Fons Adriaensen a écrit :
On Mon, Oct 22, 2012 at 02:31:35PM +0200, Stéphane Letz wrote:
You can use semas on OSX, you'll need to use sem_open API instead of
sem_init.
Using here: sem_open,
Le 22 oct. 2012 à 15:09, Paul Davis a écrit :
On Mon, Oct 22, 2012 at 9:03 AM, Stéphane Letz l...@grame.fr wrote:
Le 22 oct. 2012 à 14:50, Fons Adriaensen a écrit :
On Mon, Oct 22, 2012 at 02:31:35PM +0200, Stéphane Letz wrote:
You can use semas on OSX, you'll need to use
On Mon, Oct 22, 2012 at 09:09:56AM -0400, Paul Davis wrote:
http://subversion.ardour.org/svn/ardour2/branches/3.0/libs/pbd/pbd/semaphore.h
(work by david robillard)
I know about this, and it will find its way into zita-convolver some day.
That does however require a major version increment,
On 20 October 2012 19:45, Robin Gareus ro...@gareus.org wrote:
Tom. I had a look the IR.LV2 code and before setting out on this one and
wanted to patch IR.LV2 but that turned into a rewrite. The three main
reasons for that are
1) IR.LV2 does buffering to align small block-sizes to an
On 21 October 2012 12:41, Tom Szilagyi tomszila...@gmail.com wrote:
Not really important to the core discussion, JFTR let me point out
that this is not entirely true. There are two versions of IR (they
should have been called branches, because that's what they really
are). IR.lv2 version
Am 21.10.2012 13:38, schrieb Fons Adriaensen:
Zita-convolver works on Linux and OSX, that does not depend on*how*
you use it.
And on FreeBSD as well, if you add this little patch to allow it. ;-)
___
Linux-audio-dev mailing list
Am 21.10.2012 13:38, schrieb Fons Adriaensen:
Zita-convolver works on Linux and OSX, that does not depend on*how*
you use it.
And on FreeBSD as well, if you add this little patch to allow it. ;-)
ähm, this one.
removed
bullshit, sorry, no patch is needed.
On Sun, Oct 21, 2012 at 12:41:45PM +0200, Tom Szilagyi wrote:
I use IR almost daily on quite sophisticated A2 projects with more
than 10 IR instances on a 4-core machine. I'm quite puzzled by your
remark because I don't really experience any crashes I can relate to
IR. (yes, A2 crashes
On Sun, Oct 21, 2012 at 11:38:26AM +, Fons Adriaensen wrote:
If the processing is happening in another thread, then e.g. at the very
first block, run() must either:
(1) Wait (i.e. block) for the other thread to process the data
(2) Add latency
(3) Busy wait and drop out if
On Sun, 2012-10-21 at 11:38 +, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 07:02:16PM -0400, David Robillard wrote:
The goal of the plugin is to do synchronous (i.e. processing in the
run() context) convolution in a *strictly* hard-real-time fashion with
no latency. Doing the
On Sun, Oct 21, 2012 at 01:38:48PM -0400, David Robillard wrote:
On Sun, 2012-10-21 at 11:38 +, Fons Adriaensen wrote:
[...]
Zita-convolver works on Linux and OSX
... where it locks a mutex in the process thread.
Yes, the mutex being part of a condition variable,
used to emulate sem_t
On Sun, Oct 21, 2012 at 01:36:00PM -0400, David Robillard wrote:
As *speculated* above. Things like this are shown by experiment, and
experiment only.
How apt. I've done some half year of experiments like this
while going through the four or five different experimental
architectures of
On Sun, 2012-10-21 at 19:24 +, Fons Adriaensen wrote:
On Sun, Oct 21, 2012 at 01:38:48PM -0400, David Robillard wrote:
On Sun, 2012-10-21 at 11:38 +, Fons Adriaensen wrote:
[...]
Zita-convolver works on Linux and OSX
... where it locks a mutex in the process thread.
Yes,
On Sun, Oct 21, 2012 at 03:49:30PM -0400, David Robillard wrote:
The appropriate thing to use on OSX is mach semaphores. This code is
terrible.
I'd be most happy to replace the current code with
some using Mach semas. Patches will be much appreciated.
(A blocking in a real-time thread is
On Sun, 2012-10-21 at 19:44 +, Fons Adriaensen wrote:
On Sun, Oct 21, 2012 at 01:36:00PM -0400, David Robillard wrote:
As *speculated* above. Things like this are shown by experiment, and
experiment only.
How apt. I've done some half year of experiments like this
while going
On Sat, Oct 20, 2012 at 12:14:29AM -0400, David Robillard wrote:
convoLV2 is in an early stage of development and is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length restrictions, in this case:
* Maximum block length must be passed as
On 20 October 2012 06:14, David Robillard d...@drobilla.net wrote:
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
I'm accepting patches to IR if anyone cares to implement the features
now seemingly made
On 10/20/2012 03:27 PM, Tom Szilagyi wrote:
On 20 October 2012 06:14, David Robillard d...@drobilla.net wrote:
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
I'm accepting patches to IR if anyone cares to
On Sat, 2012-10-20 at 11:44 +, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 12:14:29AM -0400, David Robillard wrote:
convoLV2 is in an early stage of development and is not yet suitable for
users. However, it serves as a working example of an LV2 plugin with
block length
On Sat, 2012-10-20 at 15:27 +0200, Tom Szilagyi wrote:
On 20 October 2012 06:14, David Robillard d...@drobilla.net wrote:
We hope that convoLV2 will eventually be as fully-featured as IR.lv2
without resorting to kludges that violate the LV2 specification.
I'm accepting patches to IR if
On Sat, 2012-10-20 at 19:45 +0200, Robin Gareus wrote:
[...]
If that is the case, maybe you can consider helping up getting convoLV2
Since my intent to make convoLV2 a GUI-less plugin does not
seem to work out, there'll be need for a GUI at some point in time.
I still want the plugin to be
You (Fons) obviously know your stuff when it comes to implementing
convolution, and I'm very grateful you gave us libzita-convolver, but I
have to disagree with this statement:
On Sat, 2012-10-20 at 12:00 +, Fons Adriaensen wrote:
Thirdly, for the use case of reverbs, the whole latency
On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus wrote:
On 10/20/2012 01:44 PM, Fons Adriaensen wrote:
ConvoLV2 uses libzita-convolver, but in a very inefficient way,
Yes, we are aware of that. At this point in time we favor clean design
over efficiency. The choice to use a fixed
On Sat, 2012-10-20 at 21:03 +, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus wrote:
On 10/20/2012 01:44 PM, Fons Adriaensen wrote:
ConvoLV2 uses libzita-convolver, but in a very inefficient way,
Yes, we are aware of that. At this point in time we
On Sat, 2012-10-20 at 09:54 +0200, hermann meyer wrote:
Am 20.10.2012 06:14, schrieb David Robillard:
convoLV2 is an LV2 plugin to convolve audio signals without additional
latency.
https://github.com/x42/convoLV2
https://github.com/x42/convoLV2/tarball/v0.2
convoLV2 is in an early
convoLV2 is an LV2 plugin to convolve audio signals without additional
latency.
https://github.com/x42/convoLV2
https://github.com/x42/convoLV2/tarball/v0.2
convoLV2 is in an early stage of development and is not yet suitable for
users. However, it serves as a working example of an LV2 plugin
27 matches
Mail list logo
