Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

Hello,

On 03/25/2011 07:13 PM, David Robillard wrote:
> Sorry. I still have plenty of releases left on the table before I have
> time to get around to this stuff... and yes, I took a little break for a
> change ;)

Okay, no problem. And congratulations to you and Stefano for the new releases.

> I also should have mentioned I found an old radix tree implementation of
> mine that should be pretty solid. I will contrast/compare these when I
> get the chance.

Okay. My implementation is pretty much experimental by the way. The remove()
function is broken, and I think it would be better to use a linked list
internally to avoid reallocs. And it needs some refactoring.

> The radix tree is for interning URIs. You could also use a hash table,
> but hash tables are ugly and clunky IMO, I prefer more elegant
> structures that grow organically (and radix trees are simple to
> implement), and as mentioned we have many common prefixes here which
> makes it a suitable choice.
> 
> Interning URIs is used to get a number to represent a URI string. This
> is necessary for even remotely appropriate performance because it means
> statement lookup is a series of integer comparisons, and not a series of
> vastly more expensive (and redundant) string comparisons.
> 
> For a store of n statements with URIs of length k, a search will thus be
> O(lg(n) + k). Without interning it would be O(k*lg(n)), and have more
> fragmented memory access as well.

In regard to performance here is what I get when running the attached benchmark:

olivier@etoile:~/dev/lv2/sord/src$ ./radix_benchmark all_words.txt
Read 21110 words from all_words.txt
Inserted words into the radix tree in 17ms
Inserted words into the hash table in 8ms
Looked up all words from the radix tree in 9ms
Looked up all words from the hash table in 4ms
Removed all words from the radix tree in 11ms
Removed all words from the hash table in 8ms

It comares the performance of the GHashTable and my radix tree (on a quad core).
It's done using a 20k list of english words, which I think isn't very
appropriate, because it leads to  a lot of single-character branches, and the
tree never gets deep. Given this, it performs reasonably well I think.

Anyway, if you need something more sophisticated and suited to your specific
needs, it's a bit hard for me to help you I think, because there may be many
details you're thinking about which I don't know.

So, right now, I suppose that I could remove the glib dependency for my own
needs, by using drop-in replacements for the hash table and sequence, even if
they're slow. I don't need such performance for parsing tiny LV2 files anyway.

--
  Olivier


#include 
#include 
#include 
#include 
#include 
#include 
#include "radix_tree.h"

/*
Usage:
radix_benchmark 

Compile with:
gcc -Wall -o radix_benchmark -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include radix_tree.c radix_benchmark.c -lglib-2.0 -lrt

20k english words:
http://www.puzzlers.org/pub/wordlists/pocket.txt
*/

static long start_time;

static gint sort_random(gconstpointer a, gconstpointer b) {
return rand() - RAND_MAX / 2;
}

static void tree_insert(gpointer data, gpointer user_data) {
RadixTree *tree = (RadixTree *) user_data;
radix_tree_insert(tree, (char *) data, strdup((char *) data));
}

static void tree_lookup(gpointer data, gpointer user_data) {
RadixTree *tree = (RadixTree *) user_data;
char *value = (char *) radix_tree_lookup(tree, (char *) data);   
if (!value)
printf("[tree] Can't find key: %s\n", (char *) data);
else if (strcmp(value, (char *) data))
printf("[tree] Error: key '%s' has wrong value: '%s'\n", (char *) data, value);
}

static void tree_remove(gpointer data, gpointer user_data) {
RadixTree *tree = (RadixTree *) user_data;
radix_tree_remove(tree, (char *) data);
}

static void table_insert(gpointer data, gpointer user_data) {
GHashTable * table = (GHashTable *) user_data;
g_hash_table_insert(table, strdup((char *) data), strdup((char *) data));
}

static void table_lookup(gpointer data, gpointer user_data) {
GHashTable * table = (GHashTable *) user_data;
char *value = (char *) g_hash_table_lookup(table, (char *) data);
if (!value)
printf("[table] Can't find key: %s\n", (char *) data);
else if (strcmp(value, (char *) data))
printf("[table] Error: key '%s' has wrong value: '%s'\n", (char *) data, value);
}

static void table_remove(gpointer data, gpointer user_data) {
GHashTable * table = (GHashTable *) user_data;
g_hash_table_remove(table, (char *) data);
}

long time_ms(clockid_t clock) {
struct timespec t;
clock_gettime(clock, &t);
return t.tv_sec * 1000LL + t.tv_nsec / 100LL;
}

void timing(const char *action) {
if (action) {
printf("%s in %ldms\n", action, time_ms(CLOCK_MONOTONIC) - start_time);
}
start_time = time_ms(CLOCK_MONOTONIC);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s  \

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On 24/03/11 06:10 PM, Olivier Guilyardi wrote:

On 03/24/2011 07:49 AM, Stefano D'Angelo wrote:
   

Hi Olivier,

2011/3/19 Olivier Guilyardi:
 

On 03/18/2011 06:06 PM, Olivier Guilyardi wrote:
   

Hi!

On 03/11/2011 07:22 PM, David Robillard wrote:

 

On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:
   

I will try and submit a patch to remove glib. It'll take some time because I
have dozens of other things to do, but I will work on this. I had a quick look
at sord, it seems it only needs glib's sequence and hash table. Is this correct,
or will you need some more utilities?
 

Overall I need sequence, hash table (or hash table like thing, I'll
probably use a radix tree)
   

Alright, attached is a minimal radix tree implementation. I just wrote it from
scratch. Would that work for sord?

If so, I'll try and benchmark it and do some more tests.
 

Attached is an updated version with a couple of fixes and optimizations.
   

I see nobody answered yet... but don't despair, it's probably because
the long-awaited LV2r4 release made David want to run away for a
while. :-)

However, I have no idea why he needs such a thing and I have to admit
my ignorance in this regard (the only thing I ever read about radix
trees is the Wikipedia article, I'm afraid).
 

Yes, same thing here, the wikipedia article ;) But it was rather fun to write.
There are quite a few things to improve, and I've realized that the remove()
function is broken. It's pretty experimental, but my first benchmarks are quite
good. I'll try and work some more on it soon.

I think that in the context of RDF, David expects many keys to share common
(sub)prefixes, and so the radix tree may be the more appropriate for speed, when
compared to a standard hash table.

With LV2, RDF is pretty small so it's really not a big deal IMO.. But sord could
also be used out of LV2 I guess, for some other RDF needs.

   


Sorry. I still have plenty of releases left on the table before I have 
time to get around to this stuff... and yes, I took a little break for a 
change ;)


I also should have mentioned I found an old radix tree implementation of 
mine that should be pretty solid. I will contrast/compare these when I 
get the chance.


The radix tree is for interning URIs. You could also use a hash table, 
but hash tables are ugly and clunky IMO, I prefer more elegant 
structures that grow organically (and radix trees are simple to 
implement), and as mentioned we have many common prefixes here which 
makes it a suitable choice.


Interning URIs is used to get a number to represent a URI string. This 
is necessary for even remotely appropriate performance because it means 
statement lookup is a series of integer comparisons, and not a series of 
vastly more expensive (and redundant) string comparisons.


For a store of n statements with URIs of length k, a search will thus be 
O(lg(n) + k). Without interning it would be O(k*lg(n)), and have more 
fragmented memory access as well.


Thanks,

-dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 03/24/2011 07:49 AM, Stefano D'Angelo wrote:
> Hi Olivier,
> 
> 2011/3/19 Olivier Guilyardi :
>> On 03/18/2011 06:06 PM, Olivier Guilyardi wrote:
>>> Hi!
>>>
>>> On 03/11/2011 07:22 PM, David Robillard wrote:
>>>
 On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:
> I will try and submit a patch to remove glib. It'll take some time 
> because I
> have dozens of other things to do, but I will work on this. I had a quick 
> look
> at sord, it seems it only needs glib's sequence and hash table. Is this 
> correct,
> or will you need some more utilities?
 Overall I need sequence, hash table (or hash table like thing, I'll
 probably use a radix tree)
>>> Alright, attached is a minimal radix tree implementation. I just wrote it 
>>> from
>>> scratch. Would that work for sord?
>>>
>>> If so, I'll try and benchmark it and do some more tests.
>> Attached is an updated version with a couple of fixes and optimizations.
> 
> I see nobody answered yet... but don't despair, it's probably because
> the long-awaited LV2r4 release made David want to run away for a
> while. :-)
> 
> However, I have no idea why he needs such a thing and I have to admit
> my ignorance in this regard (the only thing I ever read about radix
> trees is the Wikipedia article, I'm afraid).

Yes, same thing here, the wikipedia article ;) But it was rather fun to write.
There are quite a few things to improve, and I've realized that the remove()
function is broken. It's pretty experimental, but my first benchmarks are quite
good. I'll try and work some more on it soon.

I think that in the context of RDF, David expects many keys to share common
(sub)prefixes, and so the radix tree may be the more appropriate for speed, when
compared to a standard hash table.

With LV2, RDF is pretty small so it's really not a big deal IMO.. But sord could
also be used out of LV2 I guess, for some other RDF needs.

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

Hi Olivier,

2011/3/19 Olivier Guilyardi :
> On 03/18/2011 06:06 PM, Olivier Guilyardi wrote:
>> Hi!
>>
>> On 03/11/2011 07:22 PM, David Robillard wrote:
>>
>>> On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:
>>
 I will try and submit a patch to remove glib. It'll take some time because 
 I
 have dozens of other things to do, but I will work on this. I had a quick 
 look
 at sord, it seems it only needs glib's sequence and hash table. Is this 
 correct,
 or will you need some more utilities?
>>> Overall I need sequence, hash table (or hash table like thing, I'll
>>> probably use a radix tree)
>>
>> Alright, attached is a minimal radix tree implementation. I just wrote it 
>> from
>> scratch. Would that work for sord?
>>
>> If so, I'll try and benchmark it and do some more tests.
>
> Attached is an updated version with a couple of fixes and optimizations.

I see nobody answered yet... but don't despair, it's probably because
the long-awaited LV2r4 release made David want to run away for a
while. :-)

However, I have no idea why he needs such a thing and I have to admit
my ignorance in this regard (the only thing I ever read about radix
trees is the Wikipedia article, I'm afraid).

In any case, I have to ping him for a number of related things w.r.t.
SLV2 (Windows port, mostly), so I will try to remember him about this.

Best regards,

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 03/18/2011 06:06 PM, Olivier Guilyardi wrote:
> Hi!
> 
> On 03/11/2011 07:22 PM, David Robillard wrote:
> 
>> On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:
> 
>>> I will try and submit a patch to remove glib. It'll take some time because I
>>> have dozens of other things to do, but I will work on this. I had a quick 
>>> look
>>> at sord, it seems it only needs glib's sequence and hash table. Is this 
>>> correct,
>>> or will you need some more utilities?
>> Overall I need sequence, hash table (or hash table like thing, I'll
>> probably use a radix tree)
> 
> Alright, attached is a minimal radix tree implementation. I just wrote it from
> scratch. Would that work for sord?
> 
> If so, I'll try and benchmark it and do some more tests.

Attached is an updated version with a couple of fixes and optimizations.

--
  Olivier
/*
 * Copyright (c) 2011 Samalyse
 * Author: Olivier Guilyardi
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice immediately at the beginning of the file, without modification,
 *this list of conditions, and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

#include 
#include 
#include 
#include "radix_tree.h"

typedef struct Node Node;

struct Node {
char  *leaf;
Node  *branches;
intnbranches;
void  *data;
};

struct RadixTree {
Node  root;
RadixTreeFreeData free_data;
};

RadixTree *
radix_tree_new(RadixTreeFreeData free_data) {
RadixTree *self = calloc(1, sizeof(*self));
self->free_data = free_data;
return self;
}

static void
destroy_branches(Node *node, RadixTreeFreeData free_data) {
Node *child, *end = node->branches + node->nbranches;

for (child = node->branches; child < end; child++) {
if (child->nbranches) {
destroy_branches(child, free_data);
}
free(child->leaf);
if (free_data)
free_data(child->data);
}
if (node->branches)
free(node->branches);
}

void
radix_tree_destroy(RadixTree *self) {
destroy_branches(&self->root, self->free_data);
free(self);
}

static Node *
lookup_node(const Node *node, const char *key, int *matched, int *split, Node **parent) {
int common, consumed = 0;
Node *child, *result = NULL, *end = node->branches + node->nbranches;

if (parent)
*parent = (Node *) node;

char *leaf, *k;
for (child = node->branches; child < end; child++) {
leaf = child->leaf;
if (*leaf == *key) {
// printf("%s\t%s\n", key, child->leaf);
k = (char *) key;
for (k++, leaf++, common = 1; *k && *k == *leaf; common++, k++, leaf++)
;

if (*leaf == '\0') {
key += common;
consumed = common;
*split   = 0;
if (*key == '\0') {
result = child;
} else {
result = child->nbranches ? lookup_node(child, key, matched, split, parent) : NULL;
if (!result) {
result = child;
*split = common;
}
}
break;
} else if (common > consumed) {
result   = child;
*split   = common;
consumed = common;
}
}
}

*matched += consumed;
return result;
}

void *
radix_tree_lookup(const RadixTree *self, const char *key) {
int matched = 0, split = 0;
Node *node = lookup_node(&self->root, key, &matched, &split, NULL);
return node && split == 0 ? node->data : NULL;
}

static inline void
add_node(Node *parent, const char *leaf, const void *data, const Node *branches,
 int nbranches) {
parent->branches= realloc(parent->branches,
  (parent->

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

Hi!

On 03/11/2011 07:22 PM, David Robillard wrote:

> On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:

>> I will try and submit a patch to remove glib. It'll take some time because I
>> have dozens of other things to do, but I will work on this. I had a quick 
>> look
>> at sord, it seems it only needs glib's sequence and hash table. Is this 
>> correct,
>> or will you need some more utilities?
> 
> Overall I need sequence, hash table (or hash table like thing, I'll
> probably use a radix tree)

Alright, attached is a minimal radix tree implementation. I just wrote it from
scratch. Would that work for sord?

If so, I'll try and benchmark it and do some more tests.

Cheers,

--
  Olivier
/*
 * Copyright (c) 2011 Samalyse
 * Author: Olivier Guilyardi
 * 
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice immediately at the beginning of the file, without modification,
 *this list of conditions, and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *  
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
 * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

#include 
#include 
#include 
#include "radix_tree.h"

typedef struct Node Node;

struct Node {
char  *leaf;
Node  *branches;
intnbranches;
void  *data;
};

struct RadixTree {
Node  root;
RadixTreeFreeData free_data;
};

RadixTree *
radix_tree_new(RadixTreeFreeData free_data) {
RadixTree *self = calloc(1, sizeof(*self));
self->free_data = free_data;
return self;
}

static void
destroy_branches(Node *node, RadixTreeFreeData free_data) {
Node *child, *end = node->branches + node->nbranches;

for (child = node->branches; child < end; child++) {
if (child->nbranches) {
destroy_branches(child, free_data);
}
free(child->leaf);
if (free_data)
free_data(child->data);
}
if (node->branches)
free(node->branches);
}

void
radix_tree_destroy(RadixTree *self) {
destroy_branches(&self->root, self->free_data);
free(self);
}

static int
find_common_prefix_length(const char *str1, const char *str2) {
int i;
int len1 = strlen(str1);
int len2 = strlen(str2);
for (i = 0; i < len1 && i < len2 && str1[i] == str2[i]; i++)
;
return i;
}

static Node *
lookup(const Node *node, const char *key, int *matched, int *split, Node **parent) {
int common, consumed = 0;
Node *child, *result = NULL, *end = node->branches + node->nbranches;

if (parent)
*parent = (Node *) node;

for (child = node->branches; child < end; child++) {
common = find_common_prefix_length(child->leaf, key);
if (common == strlen(child->leaf)) {
key += common;
consumed = common;
if (!strlen(key)) {
result = child;
} else {
result = lookup(child, key, matched, split, parent);
if (!result) {
result = child;
*split = common;
}
}
break;
} else if (common > consumed) {
result   = child;
*split   = common;
consumed = common;
}
}

*matched += consumed;
return result;
}

void *
radix_tree_lookup(const RadixTree *self, const char *key) {
int matched = 0, split = 0;
Node *node = lookup(&self->root, key, &matched, &split, NULL);
return node && split == 0 ? node->data : NULL;
}

static void
add_node(Node *parent, const char *leaf, const void *data, const Node *branches,
 int nbranches) {
parent->branches= realloc(parent->branches,
  (parent->nbranches + 1) * sizeof(*parent->branches));
Node *node  = parent->branches + parent->nbranches++;
node->leaf  = strdup(leaf);
node->data  = (void *) data;
node->branches  = (Node *) branches;
node-

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-03-11 at 19:40 +0100, Olivier Guilyardi wrote:
> On 03/11/2011 07:22 PM, David Robillard wrote:
> > On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:
> 
> >> I will try and submit a patch to remove glib. It'll take some time because 
> >> I
> >> have dozens of other things to do, but I will work on this. I had a quick 
> >> look
> >> at sord, it seems it only needs glib's sequence and hash table. Is this 
> >> correct,
> >> or will you need some more utilities?
> > 
> > Overall I need sequence, hash table (or hash table like thing, I'll
> > probably use a radix tree), and module loading (currently still POSIX in
> > SLV2).
> 
> From the docs I see that using GModule only adds Windows support

Well, yeah. "Portable" usually means "have to deal with *%&$# windows",
otherwise straight POSIX would be fine :)

> , unless you
> also care about HP-UX. So, a small abstraction layer around dlopen() and
> LoadLibrary() should suffice, no?

Yep

> > No rush, I may make the relevant lib myself soon if you don't beat me to
> > it, I just don't want to hold up the next release for it.
> 
> No rush here as well. I can work on a patch, but on the other side I don't 
> want
> to interfere if you're in the middle of your work.

I am deliberately trying to avoid doing that bit of work, because I'll
get lost off in la-la computer science land making data structures and
benchmarking them and stuff, and not making the LAD related releases I
really need to be making.

... I do enjoy that la-la land though. Soon enough. :)

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 03/11/2011 07:22 PM, David Robillard wrote:
> On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:

>> I will try and submit a patch to remove glib. It'll take some time because I
>> have dozens of other things to do, but I will work on this. I had a quick 
>> look
>> at sord, it seems it only needs glib's sequence and hash table. Is this 
>> correct,
>> or will you need some more utilities?
> 
> Overall I need sequence, hash table (or hash table like thing, I'll
> probably use a radix tree), and module loading (currently still POSIX in
> SLV2).

>From the docs I see that using GModule only adds Windows support, unless you
also care about HP-UX. So, a small abstraction layer around dlopen() and
LoadLibrary() should suffice, no?

> 
> No rush, I may make the relevant lib myself soon if you don't beat me to
> it, I just don't want to hold up the next release for it.

No rush here as well. I can work on a patch, but on the other side I don't want
to interfere if you're in the middle of your work.

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-03-11 at 12:08 +0100, Olivier Guilyardi wrote:
> On 02/25/2011 10:00 PM, David Robillard wrote:
> > On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
> 
> >> That said there is another big problem. This glib dependency, it's way too 
> >> heavy
> >> for mobile deployment.
> > 
> > Glib was the most effective route of getting the job done - rewriting
> > the few bits that are required is not an effective use of my time right
> > now (it's not exposed in the API, so it's not a compatibility issue, and
> > there's a ton of more pressing LV2 things that need doing).
> > 
> > I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
> > unoffensive a dependency as they come. On mobile, I guess that meg or so
> > actually makes a difference.
> > 
> > Replacing glib will not be very difficult, very little of it is used:
> > just a balanced BST, dynamic array, and ideally a hash table or trie
> > other appropriate structure for string interning (the BST would do for
> > this part, with a bit of a performance cost). Good old-fashioned data
> > structure implementation is my favourite thing to do, but unfortunately
> > there is no shortage of more pragmatic things that need doing ;)
> > 
> > Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
> > just tearing the required bits out of glib itself. Sqlite has an
> > in-memory hash table IIRC. Code abounds.
> > 
> > Present a viable alternative, and I'll switch sord/slv2 to it, but I
> > have no good reason to invest time in reinventing glib right now.
> 
> I will try and submit a patch to remove glib. It'll take some time because I
> have dozens of other things to do, but I will work on this. I had a quick look
> at sord, it seems it only needs glib's sequence and hash table. Is this 
> correct,
> or will you need some more utilities?

Overall I need sequence, hash table (or hash table like thing, I'll
probably use a radix tree), and module loading (currently still POSIX in
SLV2).

No rush, I may make the relevant lib myself soon if you don't beat me to
it, I just don't want to hold up the next release for it.

Cheers,

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 10:00 PM, David Robillard wrote:
> On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:

>> That said there is another big problem. This glib dependency, it's way too 
>> heavy
>> for mobile deployment.
> 
> Glib was the most effective route of getting the job done - rewriting
> the few bits that are required is not an effective use of my time right
> now (it's not exposed in the API, so it's not a compatibility issue, and
> there's a ton of more pressing LV2 things that need doing).
> 
> I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
> unoffensive a dependency as they come. On mobile, I guess that meg or so
> actually makes a difference.
> 
> Replacing glib will not be very difficult, very little of it is used:
> just a balanced BST, dynamic array, and ideally a hash table or trie
> other appropriate structure for string interning (the BST would do for
> this part, with a bit of a performance cost). Good old-fashioned data
> structure implementation is my favourite thing to do, but unfortunately
> there is no shortage of more pragmatic things that need doing ;)
> 
> Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
> just tearing the required bits out of glib itself. Sqlite has an
> in-memory hash table IIRC. Code abounds.
> 
> Present a viable alternative, and I'll switch sord/slv2 to it, but I
> have no good reason to invest time in reinventing glib right now.

I will try and submit a patch to remove glib. It'll take some time because I
have dozens of other things to do, but I will work on this. I had a quick look
at sord, it seems it only needs glib's sequence and hash table. Is this correct,
or will you need some more utilities?

--
  Olivier

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/3/1 David Robillard :
> On Tue, 2011-03-01 at 14:00 +0100, Stefano D'Angelo wrote:
>> 2011/3/1 David Robillard :
>> > On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote:
> [...]
>> >> Once you remove the glib dep, I should be able to tell you what size I 
>> >> get when
>> >> compiling with the Android NDK. I have checked again, and 100Kb is good 
>> >> in my
>> >> case. FYI, APK packaging uses zip compression.
>> >
>> > I would guess it will be at the very least a month before this happens,
>> > unless somebody steps up to do it. The relevant SLV2 release
>> > announcement will mention the glib removal.
>>
>> Are you planning to remove it in the next release?
>
> Nope. The next release will be very soon. It is not a short-term
> priority for me at all.
>
> If a solid replacement for all the necessary things shows up that I
> don't have to work on whatsoever, then I'll switch to it.
>
> I very much need to start releasing /plugins/ and /programs/ - things
> users actually /use/ directly. At first I only care about doing so on
> this platform, and glib is not a problem whatsoever on this platform.
> There's still a ton of LV2 core/extension work that needs doing before I
> get to do that. Pissing time away replacing glib? No thanks. :)

As said, same priority framework here, but your previous answer seemed
to indicate otherwise.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-03-01 at 14:00 +0100, Stefano D'Angelo wrote:
> 2011/3/1 David Robillard :
> > On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote:
[...]
> >> Once you remove the glib dep, I should be able to tell you what size I get 
> >> when
> >> compiling with the Android NDK. I have checked again, and 100Kb is good in 
> >> my
> >> case. FYI, APK packaging uses zip compression.
> >
> > I would guess it will be at the very least a month before this happens,
> > unless somebody steps up to do it. The relevant SLV2 release
> > announcement will mention the glib removal.
> 
> Are you planning to remove it in the next release?

Nope. The next release will be very soon. It is not a short-term
priority for me at all.

If a solid replacement for all the necessary things shows up that I
don't have to work on whatsoever, then I'll switch to it.

I very much need to start releasing /plugins/ and /programs/ - things
users actually /use/ directly. At first I only care about doing so on
this platform, and glib is not a problem whatsoever on this platform.
There's still a ton of LV2 core/extension work that needs doing before I
get to do that. Pissing time away replacing glib? No thanks. :)

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-02-25 at 23:12 -0500, Paul Davis wrote:
> On Fri, Feb 25, 2011 at 9:27 PM, David Robillard  wrote:
> 
> > If we want to do it, this is the copyright situation:
> >
> > Copyright (C) 2000-2002 Richard W.E. Furse, Paul Barton-Davis,
> >Stefan Westerfeld.
> > Copyright (C) 2006-2010 Steve Harris, David Robillard.
> 
> > 1) Does everyone present support making lv2.h 2-clause BSD? Some other
> > alternative, perhaps? (you can also explicitly absolve yourself of the
> > copyright if you'd prefer)
> 
> BSD is fine with me.

On Tue, 2011-03-01 at 08:45 +, Richard Furse wrote:
> I've no problem with a BSD style license for LADSPA

That leaves Stefan and Steve.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/3/1 David Robillard :
> On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote:
>> Hi!
>>
>> On 02/26/2011 09:08 PM, David Robillard wrote:
>>
>> > Fair enough. The sum of all installed LV2 data loaded into a data
>> > structure can be large, though. My new implementation is still not quite
>> > optimal, though:
>>
>> [...]
>>
>> > On Android it's probably not an issue though, as you say. For other
>> > embedded situations it would be nice to have absolutely minimal space
>> > overhead on top of the actual data itself... plus it's fun :)
>>
>> It makes sense indeed to reduce memory usage, but reading the above, I get a
>> feeling like parsing the metadata of a typical plugin set won't exceed a few 
>> Kb
>> of RAM.
>>
>> To give you an idea, on a rather old device such as the HTC Magic, you have
>> 288Mb of RAM, and when an app is in the foreground you can safely use quite a
>> lot of memory.
>>
>> There could more constrained embedded situations where plugins are needed,
>> although I can't really think about any real-world example ATM.
>
> I will need to make a "load all LV2 data and do nothing" program to
> benchmark how much space is used by loading all LV2 stuff. I suspect it
> will be a figure workable within 288MB of RAM, but ideally should be
> smaller since apps have other things to store, especially when audio is
> involved.

IIRC, my Turtle parser/in-memory graph store, had roughly a < 6x
overhead over the actual amount of data, that on my laptop is around 1
MB (excluding dynamic manifests). I bet that we are already able to
stay below 32 MB with lots and lots of plugins around.

However, I think the actual RAM usage is more dependent on loaded
plugin libraries and plugin instances in hosts that allow you to load
more than a small bunch of them. And that cannot be avoided AFAIK.

In this regard, SLV2 is already showing good behavior in loading
metadata on demand.

>> > Fair enough. It seems the libraries involved can be built to be well
>> > under 100k with -Os and such, but I have no idea how 64-bit shared
>> > library code compares to static android code in terms of size. I'm all
>> > for contributions that shave a bit of space, but everything seems pretty
>> > good to me now (glib aside).
>>
>> Once you remove the glib dep, I should be able to tell you what size I get 
>> when
>> compiling with the Android NDK. I have checked again, and 100Kb is good in my
>> case. FYI, APK packaging uses zip compression.
>
> I would guess it will be at the very least a month before this happens,
> unless somebody steps up to do it. The relevant SLV2 release
> announcement will mention the glib removal.

Are you planning to remove it in the next release?

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote:
> Hi!
> 
> On 02/26/2011 09:08 PM, David Robillard wrote:
> 
> > Fair enough. The sum of all installed LV2 data loaded into a data
> > structure can be large, though. My new implementation is still not quite
> > optimal, though:
> 
> [...]
> 
> > On Android it's probably not an issue though, as you say. For other
> > embedded situations it would be nice to have absolutely minimal space
> > overhead on top of the actual data itself... plus it's fun :)
> 
> It makes sense indeed to reduce memory usage, but reading the above, I get a
> feeling like parsing the metadata of a typical plugin set won't exceed a few 
> Kb
> of RAM.
> 
> To give you an idea, on a rather old device such as the HTC Magic, you have
> 288Mb of RAM, and when an app is in the foreground you can safely use quite a
> lot of memory.
> 
> There could more constrained embedded situations where plugins are needed,
> although I can't really think about any real-world example ATM.

I will need to make a "load all LV2 data and do nothing" program to
benchmark how much space is used by loading all LV2 stuff. I suspect it
will be a figure workable within 288MB of RAM, but ideally should be
smaller since apps have other things to store, especially when audio is
involved.

> > Fair enough. It seems the libraries involved can be built to be well
> > under 100k with -Os and such, but I have no idea how 64-bit shared
> > library code compares to static android code in terms of size. I'm all
> > for contributions that shave a bit of space, but everything seems pretty
> > good to me now (glib aside).
> 
> Once you remove the glib dep, I should be able to tell you what size I get 
> when
> compiling with the Android NDK. I have checked again, and 100Kb is good in my
> case. FYI, APK packaging uses zip compression.

I would guess it will be at the very least a month before this happens,
unless somebody steps up to do it. The relevant SLV2 release
announcement will mention the glib removal.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

Hi!

On 02/26/2011 09:08 PM, David Robillard wrote:

> Fair enough. The sum of all installed LV2 data loaded into a data
> structure can be large, though. My new implementation is still not quite
> optimal, though:

[...]

> On Android it's probably not an issue though, as you say. For other
> embedded situations it would be nice to have absolutely minimal space
> overhead on top of the actual data itself... plus it's fun :)

It makes sense indeed to reduce memory usage, but reading the above, I get a
feeling like parsing the metadata of a typical plugin set won't exceed a few Kb
of RAM.

To give you an idea, on a rather old device such as the HTC Magic, you have
288Mb of RAM, and when an app is in the foreground you can safely use quite a
lot of memory.

There could more constrained embedded situations where plugins are needed,
although I can't really think about any real-world example ATM.

> Fair enough. It seems the libraries involved can be built to be well
> under 100k with -Os and such, but I have no idea how 64-bit shared
> library code compares to static android code in terms of size. I'm all
> for contributions that shave a bit of space, but everything seems pretty
> good to me now (glib aside).

Once you remove the glib dep, I should be able to tell you what size I get when
compiling with the Android NDK. I have checked again, and 100Kb is good in my
case. FYI, APK packaging uses zip compression.

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/27 Giuseppe Zompatori :
> 2011/2/27 Stefano D'Angelo :
>>
>>
>> Ciao Giuseppe,
>
> Ciao Stefano,
>
>>
>> In the FAQ they say it's actually some sort of preamp... but well, I
>> can't provide hardware anyway.
>
> I was merely pointing it out as I don't think there is currently any
> other way to do it.
> Connecting the guitar directly to the phone with a simple plug adapter
> would probably sound meh.
> Unless Google wants to add support for external USB sound cards to Android? ;)

Oh well. :-)

>> I don't even know if I would charge for such plug-ins and/or release
>> them as closed source. Ideally, I would release them under GPL and
>> accept donations, but have no idea really. Actually there are a couple
>> of plug-ins I could really charge for since they are really beyond
>> state of the art and suitable for scientific publications (indeed,
>> that's why I'm developing them). They are physics-based simulators: a
>> fully parametric tube amp + eq + output transformer + loudspeaker +
>> air impedance, and a couple of diode clippers (one is
>> tubescreamer-like) - still some pieces are missing at the moment (new
>> triode model in the making, oversampling not yet in place, opamp model
>> not yet serious).
>>
>
> Sounds cool, I recently bought one of those beasts (
> http://www.fractalaudio.com/products-fa-axefx.html ), and I think it's
> amazing, hands down the best amp modeling I've ever heard (and amazing
> effects too!) demos are here
> http://www.fractalaudio.com/experience.html
>
> It also does model the power stage section (power tubes->output
> transformer<->cabinet interaction) and exposes many parameters to the
> user, like tubes bias, negative feedback amount (if any), sag, B+
> filtering/capacitance, even speaker distortion etc.
> I'd be happy to compare your plug-ins to the Axe-FX ;)

Well... they seem to have a lot of stuff there. :-)

However, I wonder how they do it... I think they are probably using
some black box modeling, since multiple nonlinearities+feedback in a
single system is very hard to model.

The kind of stuff I'm trying to do is accurately model a class A amp
with a single triode using white box techniques... to give you an idea
of what it sounds like see this:
http://www.youtube.com/watch?v=cdNtmaIdLdo - it is part of my MSc
thesis presentation (100.000 lire guitar, dated and slow laptop, cheap
speaker and cheap camera... only the sound card is good).

I guess you speak Italian (at least your name suggests that), so enjoy
my weird southern accent. :-P

> I would personally prefer desktop LV2 versions of your plug-ins, they
> could always be ported later to Android if it's going to be worth the
> effort.

Sure, that would be the path to follow.

> And I would prefer GPL'ed plug-ins and be willing to donate, I don't
> think there are many options right now on Linux, I dislike rakarrack
> and guitar_ix, and find CAPS* so so.

Well, they say guitarix has improved, yet the last time I was all but
satisfied with it. You may want to take a look at invada plugins, if
you haven't already.

>> However, correct me if I am wrong, I don't think most Android
>> platforms would be suitable for live processing (latency), but only
>> for recording (what about quality?).
>
> Can't help you there, sorry. I have a cheap entry level HTC Tattoo and
> it's slow as molasses. Haven't even attempted to install any audio
> related apps. It might be feasible on higher end droid phones though
> provided the audio API allows it, I just don't know. I think there has
> been a recent discussion about realtime audio apps on Android on LAU
> if I am not mistaken, you might want to search for it.

Ok, thanks.

Stammi bene,

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Giuseppe Zompatori]

2011/2/27 Stefano D'Angelo :
>
>
> Ciao Giuseppe,

Ciao Stefano,

>
> In the FAQ they say it's actually some sort of preamp... but well, I
> can't provide hardware anyway.

I was merely pointing it out as I don't think there is currently any
other way to do it.
Connecting the guitar directly to the phone with a simple plug adapter
would probably sound meh.
Unless Google wants to add support for external USB sound cards to Android? ;)

>
> I don't even know if I would charge for such plug-ins and/or release
> them as closed source. Ideally, I would release them under GPL and
> accept donations, but have no idea really. Actually there are a couple
> of plug-ins I could really charge for since they are really beyond
> state of the art and suitable for scientific publications (indeed,
> that's why I'm developing them). They are physics-based simulators: a
> fully parametric tube amp + eq + output transformer + loudspeaker +
> air impedance, and a couple of diode clippers (one is
> tubescreamer-like) - still some pieces are missing at the moment (new
> triode model in the making, oversampling not yet in place, opamp model
> not yet serious).
>

Sounds cool, I recently bought one of those beasts (
http://www.fractalaudio.com/products-fa-axefx.html ), and I think it's
amazing, hands down the best amp modeling I've ever heard (and amazing
effects too!) demos are here
http://www.fractalaudio.com/experience.html

It also does model the power stage section (power tubes->output
transformer<->cabinet interaction) and exposes many parameters to the
user, like tubes bias, negative feedback amount (if any), sag, B+
filtering/capacitance, even speaker distortion etc.
I'd be happy to compare your plug-ins to the Axe-FX ;)

I would personally prefer desktop LV2 versions of your plug-ins, they
could always be ported later to Android if it's going to be worth the
effort.
And I would prefer GPL'ed plug-ins and be willing to donate, I don't
think there are many options right now on Linux, I dislike rakarrack
and guitar_ix, and find CAPS* so so.

> However, correct me if I am wrong, I don't think most Android
> platforms would be suitable for live processing (latency), but only
> for recording (what about quality?).

Can't help you there, sorry. I have a cheap entry level HTC Tattoo and
it's slow as molasses. Haven't even attempted to install any audio
related apps. It might be feasible on higher end droid phones though
provided the audio API allows it, I just don't know. I think there has
been a recent discussion about realtime audio apps on Android on LAU
if I am not mistaken, you might want to search for it.

Sorry for the OT.

Ciao,

-Giuseppe

>
> Stefano
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/27 Giuseppe Zompatori :
> 2011/2/26 Stefano D'Angelo :
>> 2011/2/26 Olivier Guilyardi :
>>> On 02/26/2011 06:45 PM, Stefano D'Angelo wrote:
>>>
> Something like 100k-200K could be fine in my case, at the condition that 
> adding
> LV2 support provides a real benefit in terms of functionality.

 This depends on what you are using it for and how. Being decentralized
 & extensible, you could also use it to make coffee. :-)
>>>
>>> Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be.
>>>
>>> Aside, in the ui ext docs there's this example which contains ui:binary, 
>>> but I
>>> can't find any reference documentation about this binary property on the 
>>> page:
>>> http://lv2plug.in/ns/extensions/ui/
>>
>> Good catch, that ought to be fixed.
>>
> I don't want to wake up old trolls, but last fall, when I had a sound 
> engineer
> intern working on the topic, we ended up thinking that integrating LADSPA 
> would
> really be straightforward. No such overhead, great portability, and 
> plenty of
> plugins.

> So most logically, when time comes to add plugin support, I will start 
> with
> LADSPA. LV2 will maybe come afterwards. But this could change if there 
> suddenly
> is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages 
> arrive
> on the Android Market.

 I respect your choice and understand the rationale. Also, all of this
 changes won't happen by tomorrow (my guess is 2/3 months, based on
 feeling more than facts), so if you "need effects soon", you should
 probably go that route.
>>>
>>> Effects are not the top priority. I've done quite a lot of research on it
>>> because it was a good topic for my intern to work on. I have other basic
>>> features to add first. And the schedule that you mention makes sense to me.
>>
>> Hopefully it makes sense also to Dave as well, since everything else
>> that's needed is his stuff.
>>
 However, in the long run, I would avoid LADSPA for two reasons: 1.
 lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts
 without explicit support through the NASPRO bridges (which will be
 able to work by default with SLV2 starting from the next SLV2 release,
 otherwise you can grab the current svn SLV2 already).
>>>
>>> Hmm, I've been wandering in google yesterday about such LV2-LADSPA bridge.
>>>
>>> I am discovering the NASPRO project. That's interesting. It seems like it 
>>> may
>>> consume a lot of brain-time diving into all this when compared to LADSPA. 
>>> But
>>> I'm nevertheless a bit worried about adding support for LADSPA, as it's 
>>> getting
>>> old and somehow obsolete. But IIUC correctly you are about to add some sort 
>>> of
>>> LADSPA backward compatibility, which in any case, sounds very good and was
>>> clearly missing.
>>
>> It's already there if you want, the 0.2.0 release is from the last
>> year but should still work if you use a recent svn version of SLV2.
>>
 So it turns out it depends on how long you want to wait, or rather if
 you would consider giving some help, and what you want to do with LV2.
>>>
>>> What kind of help would you need?
>>
>> There are several departments. :-)
>>
>> I've enumerated above the stuff missing from NASPRO core, then SLV2
>> should use it, and that would probably be a good part of the work
>> already.
>>
>>> Also, are you/is there anyone on the list who is interested in releasing 
>>> audio
>>> plugins for Android? Feel free to write me personally if needed.
>>
>> I plan to develop a DSP language and compiler that generates LV2
>> plugins. Also in this case, a prototype is already in place (look for
>> "Permafrost" on the NASPRO website - no easy-to-read language
>> documentation yet, and both the syntax and the compiler have to be
>> redone, but I may get resources - time and moeny - to do this pretty
>> soon).
>>
>> Then, there are some plugins I more or less did (but not released
>> yet). It's guitar fx stuff, however, so I don't know how they could be
>> used in Android (ideas?).
>>
>
> Ciao Stefano,
>
> With a small impedance matching device connected to the mic-in of the
> phone, the way IK Multimedia's guitar amp sims work on iPhone?
>
> http://www.ikmultimedia.com/Main.html?iphone/index.php&fenderiphone

Ciao Giuseppe,

In the FAQ they say it's actually some sort of preamp... but well, I
can't provide hardware anyway.

I don't even know if I would charge for such plugins and/or release
them as closed source. Ideally, I would release them under GPL and
accept donations, but have no idea really. Actually there are a couple
of plugins I could really charge for since they are really beyond
state of the art and suitable for scientific publications (indeed,
that's why I'm developing them). They are physics-based simulators: a
fully parametric tube amp + eq + output transformer + loudspeaker +
air impedance, and a couple of diode cli

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Giuseppe Zompatori]

2011/2/26 Stefano D'Angelo :
> 2011/2/26 Olivier Guilyardi :
>> On 02/26/2011 06:45 PM, Stefano D'Angelo wrote:
>>
 Something like 100k-200K could be fine in my case, at the condition that 
 adding
 LV2 support provides a real benefit in terms of functionality.
>>>
>>> This depends on what you are using it for and how. Being decentralized
>>> & extensible, you could also use it to make coffee. :-)
>>
>> Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be.
>>
>> Aside, in the ui ext docs there's this example which contains ui:binary, but 
>> I
>> can't find any reference documentation about this binary property on the 
>> page:
>> http://lv2plug.in/ns/extensions/ui/
>
> Good catch, that ought to be fixed.
>
 I don't want to wake up old trolls, but last fall, when I had a sound 
 engineer
 intern working on the topic, we ended up thinking that integrating LADSPA 
 would
 really be straightforward. No such overhead, great portability, and plenty 
 of
 plugins.
>>>
 So most logically, when time comes to add plugin support, I will start with
 LADSPA. LV2 will maybe come afterwards. But this could change if there 
 suddenly
 is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages 
 arrive
 on the Android Market.
>>>
>>> I respect your choice and understand the rationale. Also, all of this
>>> changes won't happen by tomorrow (my guess is 2/3 months, based on
>>> feeling more than facts), so if you "need effects soon", you should
>>> probably go that route.
>>
>> Effects are not the top priority. I've done quite a lot of research on it
>> because it was a good topic for my intern to work on. I have other basic
>> features to add first. And the schedule that you mention makes sense to me.
>
> Hopefully it makes sense also to Dave as well, since everything else
> that's needed is his stuff.
>
>>> However, in the long run, I would avoid LADSPA for two reasons: 1.
>>> lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts
>>> without explicit support through the NASPRO bridges (which will be
>>> able to work by default with SLV2 starting from the next SLV2 release,
>>> otherwise you can grab the current svn SLV2 already).
>>
>> Hmm, I've been wandering in google yesterday about such LV2-LADSPA bridge.
>>
>> I am discovering the NASPRO project. That's interesting. It seems like it may
>> consume a lot of brain-time diving into all this when compared to LADSPA. But
>> I'm nevertheless a bit worried about adding support for LADSPA, as it's 
>> getting
>> old and somehow obsolete. But IIUC correctly you are about to add some sort 
>> of
>> LADSPA backward compatibility, which in any case, sounds very good and was
>> clearly missing.
>
> It's already there if you want, the 0.2.0 release is from the last
> year but should still work if you use a recent svn version of SLV2.
>
>>> So it turns out it depends on how long you want to wait, or rather if
>>> you would consider giving some help, and what you want to do with LV2.
>>
>> What kind of help would you need?
>
> There are several departments. :-)
>
> I've enumerated above the stuff missing from NASPRO core, then SLV2
> should use it, and that would probably be a good part of the work
> already.
>
>> Also, are you/is there anyone on the list who is interested in releasing 
>> audio
>> plugins for Android? Feel free to write me personally if needed.
>
> I plan to develop a DSP language and compiler that generates LV2
> plugins. Also in this case, a prototype is already in place (look for
> "Permafrost" on the NASPRO website - no easy-to-read language
> documentation yet, and both the syntax and the compiler have to be
> redone, but I may get resources - time and moeny - to do this pretty
> soon).
>
> Then, there are some plugins I more or less did (but not released
> yet). It's guitar fx stuff, however, so I don't know how they could be
> used in Android (ideas?).
>

Ciao Stefano,

With a small impedance matching device connected to the mic-in of the
phone, the way IK Multimedia's guitar amp sims work on iPhone?

http://www.ikmultimedia.com/Main.html?iphone/index.php&fenderiphone

-Giuseppe

> Stefano
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Sat, 2011-02-26 at 19:44 +0100, Olivier Guilyardi wrote:
> On 02/26/2011 07:28 PM, David Robillard wrote:
> 
> >> Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could 
> >> be.
> > 
> > I think browser UI is definitely the way to go. Then it's a UI for
> > basically anything, and one that's inherently remote control capable.
> > 
> > I have a few ideas knocking around in the back of my head about simple
> > dynamic RAD for web based plugin GUIs...
> 
> Browser UI is too much overhead IMO. I've had many Android devices in my 
> hands.
> Some of them are fast, some of them lag terribly. You need to optimize as much
> as you can, and thus avoid extra layers such as a browser, javascript, and 
> all that.
> 
> Also, for really nice Android plugin UIs, the use of OpenGL could be great. It
> provides a great frame rate, suitable for fancy realtime frequency curves,
> waveforms, etc..
> 
> But all this need some careful research.

At this very instant, on a particular device, browser might not be up to
snuff.

Personally I'm more interested in better long-term investments, and the
browser is only going to get better - and it's getting better very, very
quickly. This stuff is moving way too fast to throw out all the wins and
ease of browser UIs, IMO.

The ultra-portability is a really lucrative feature. Being able to
control plugins over the network from anything with a web browser
without requiring any UI-client side specific code whatsoever is a whole
lot of awesome. Even for desktop software - have a nice phone or tablet?
Go to http://yourmachine:12345 (or whatever) and there's the UI. No
screwing around with phone/tablet software whatsoever.

Just want the UI on the same machine? Do the same in your browser.

I understand your priorities might be slightly different, since you're
trying to push Android software in the market, but that's my position.
>From a makin' money makin' apps perspective, a free iPhone/iPad port
sure doesn't hurt, though... 

(Aside: For Ingen fans, I think this is the way things are going for
making UIs for Ingen patches. Build your UI, even dynamically, by
visually programming with LV2 messages, and your patch can have a custom
browser UI that can be used if you're running Ingen as an app, or if the
patch is running as an LV2 plugin in some other host. Develop LV2
plugins, with a network transparent GUI, without writing a single line
of code.)

> > I just dropped explicit LADSPA support from Ingen in favour of NASPRO.
> > IMO, if the bridge is inadequate, then the bridge should be fixed, so
> > I'm investing in NASPRO, so to speak, so hopefully it remains a vibrant
> > project :)
> 
> I am really glad to read that this gap between LADSPA and LV2 is about to 
> disappear.

Likewise.

I think I am going to create a "LADSPA metadata" LV2 bundle with a
(hand-curated) data file with extra info about various LADSPA plugins,
particularly classes (plugin categories) for plugins without lrdf.
LADSPA plugins not being categorized in the menu is the user-visible
kink in integration right now...

Porting is, of course, even better. A tool that uses slv2 and
dyn-manifest to dump out a bundle for a wrapped plugin would do almost
all the LADSPA=>LV2 porting work for you, and is trivial to write...

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Sat, 2011-02-26 at 19:32 +0100, Olivier Guilyardi wrote:
> On 02/26/2011 07:18 PM, David Robillard wrote:
> 
> > I'm more in to shrinking the actual runtime memory overhead to the
> > absolute bare minimum than shrinking the code. I have roughly infinity
> > more useful things to do than pretending <100k libraries are bloated :)
> 
> Oddly, on most Android devices you actually have plenty of RAM to work with,
> especially in native code where the Java maximum heap size do not apply.
> Memory's not a bottleneck.

Fair enough. The sum of all installed LV2 data loaded into a data
structure can be large, though. My new implementation is still not quite
optimal, though:

The per-statement overhead in Sord can be reduced from 

4 * sizeof(void*)) * n_triples * n_indices

to

4 * sizeof(void*)) * n_triples

relatively easily, but it already seems to be much smaller than the old
librdf version (judging by my last unscientific experiment and feedback
from others, at least). n_indices is typically in [1..4], and IIRC 2 for
slv2.

There's also, from SLV2's perspective, 2 copies made of every parsed
node (from disk to serd, then from serd to sord). This can be reduced to
1, the optimum[1], at a slight cost in processing overhead (reading a
character gets one function call more expensive).

Everything else is pretty tight; with these two improvements serd =>
sord will be roughly as space efficient as it is possible for an
implementation of "reading Turtle in to a searchable model" can be.

On Android it's probably not an issue though, as you say. For other
embedded situations it would be nice to have absolutely minimal space
overhead on top of the actual data itself... plus it's fun :)

> I wasn't saying that libraries <100k are bloated. So far, I had the impression
> that we were in the order hundreds of kilobytes, which is too much for plugin
> support in an app, when you think about it as a whole, which means codecs and
> other deps.

Fair enough. It seems the libraries involved can be built to be well
under 100k with -Os and such, but I have no idea how 64-bit shared
library code compares to static android code in terms of size. I'm all
for contributions that shave a bit of space, but everything seems pretty
good to me now (glib aside).

-dr

[1] In a basic model where reading from "disk" is considered a copy. To
make the implementation literally as lightweight as possible in reality,
it could mmap everything, so in the case where the data is already
cached it would not be copied at all thanks to virtual memory. I will
probably try this eventually for fun, but it's probably more of a
high-performance computing CS nerd wank than something that needs to
happen...


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/26 Olivier Guilyardi :
> On 02/26/2011 07:37 PM, Stefano D'Angelo wrote:
>> 2011/2/26 Olivier Guilyardi :
>
 So it turns out it depends on how long you want to wait, or rather if
 you would consider giving some help, and what you want to do with LV2.
>
>>> What kind of help would you need?
>>
>> There are several departments. :-)
>>
>> I've enumerated above the stuff missing from NASPRO core, then SLV2
>> should use it, and that would probably be a good part of the work
>> already.
>
> Hmm, I will first try and learn more about NASPRO, compile it on Android, and
> see if I can get it to work with SLV2 for LADSPA plugins.

Get the current hg, the released stuff is old and a completely
different codebase (might still work however, but requires librdf...)

Of the current stuff, NASPRO core is the only serious thing you want,
since the rest is being developed and does next to nothing.

>> I plan to develop a DSP language and compiler that generates LV2
>> plugins. Also in this case, a prototype is already in place (look for
>> "Permafrost" on the NASPRO website - no easy-to-read language
>> documentation yet, and both the syntax and the compiler have to be
>> redone, but I may get resources - time and moeny - to do this pretty
>> soon).
>>
>> Then, there are some plugins I more or less did (but not released
>> yet). It's guitar fx stuff, however, so I don't know how they could be
>> used in Android (ideas?).
>
> There are many musicians using my app, and amongst them many guitarists. I 
> think
> they're mainly the ones who requested effects. You could provide your plugins 
> as
> standalone packages on the android market. My app could be the first host, but
> there could be many other hosts in the future, if it's documented and easy.

Oh well, that'd be awesome. :-D

But still, priorities... my main one is completing the next NASPRO
release, then porting SLV2 to Windows and then maybe, unless there is
some urgency. However, there are already some guitar fx plugins worth
using (e.g., Invada).

> I'll be happy to discuss more about this next week. Now, I need to go.

Sure.

> Thanks for the great discussion!

You're welcome. ;-)

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/26/2011 07:37 PM, Stefano D'Angelo wrote:
> 2011/2/26 Olivier Guilyardi :

>>> So it turns out it depends on how long you want to wait, or rather if
>>> you would consider giving some help, and what you want to do with LV2.

>> What kind of help would you need?
> 
> There are several departments. :-)
> 
> I've enumerated above the stuff missing from NASPRO core, then SLV2
> should use it, and that would probably be a good part of the work
> already.

Hmm, I will first try and learn more about NASPRO, compile it on Android, and
see if I can get it to work with SLV2 for LADSPA plugins.

> I plan to develop a DSP language and compiler that generates LV2
> plugins. Also in this case, a prototype is already in place (look for
> "Permafrost" on the NASPRO website - no easy-to-read language
> documentation yet, and both the syntax and the compiler have to be
> redone, but I may get resources - time and moeny - to do this pretty
> soon).
> 
> Then, there are some plugins I more or less did (but not released
> yet). It's guitar fx stuff, however, so I don't know how they could be
> used in Android (ideas?).

There are many musicians using my app, and amongst them many guitarists. I think
they're mainly the ones who requested effects. You could provide your plugins as
standalone packages on the android market. My app could be the first host, but
there could be many other hosts in the future, if it's documented and easy.

I'll be happy to discuss more about this next week. Now, I need to go.

Thanks for the great discussion!

Cheers

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/26/2011 07:28 PM, David Robillard wrote:

>> Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be.
> 
> I think browser UI is definitely the way to go. Then it's a UI for
> basically anything, and one that's inherently remote control capable.
> 
> I have a few ideas knocking around in the back of my head about simple
> dynamic RAD for web based plugin GUIs...

Browser UI is too much overhead IMO. I've had many Android devices in my hands.
Some of them are fast, some of them lag terribly. You need to optimize as much
as you can, and thus avoid extra layers such as a browser, javascript, and all 
that.

Also, for really nice Android plugin UIs, the use of OpenGL could be great. It
provides a great frame rate, suitable for fancy realtime frequency curves,
waveforms, etc..

But all this need some careful research.

> I just dropped explicit LADSPA support from Ingen in favour of NASPRO.
> IMO, if the bridge is inadequate, then the bridge should be fixed, so
> I'm investing in NASPRO, so to speak, so hopefully it remains a vibrant
> project :)

I am really glad to read that this gap between LADSPA and LV2 is about to 
disappear.

>>From a host author POV, it's pretty awesome to implement a single plugin
> API and get full-featured support for (possibly) all the plugin APIs for
> free...

I completely agree with that. Especially when you also mention 20k ;)

--
  Olivier

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/26 Olivier Guilyardi :
> On 02/26/2011 06:45 PM, Stefano D'Angelo wrote:
>
>>> Something like 100k-200K could be fine in my case, at the condition that 
>>> adding
>>> LV2 support provides a real benefit in terms of functionality.
>>
>> This depends on what you are using it for and how. Being decentralized
>> & extensible, you could also use it to make coffee. :-)
>
> Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be.
>
> Aside, in the ui ext docs there's this example which contains ui:binary, but I
> can't find any reference documentation about this binary property on the page:
> http://lv2plug.in/ns/extensions/ui/

Good catch, that ought to be fixed.

>>> I don't want to wake up old trolls, but last fall, when I had a sound 
>>> engineer
>>> intern working on the topic, we ended up thinking that integrating LADSPA 
>>> would
>>> really be straightforward. No such overhead, great portability, and plenty 
>>> of
>>> plugins.
>>
>>> So most logically, when time comes to add plugin support, I will start with
>>> LADSPA. LV2 will maybe come afterwards. But this could change if there 
>>> suddenly
>>> is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages 
>>> arrive
>>> on the Android Market.
>>
>> I respect your choice and understand the rationale. Also, all of this
>> changes won't happen by tomorrow (my guess is 2/3 months, based on
>> feeling more than facts), so if you "need effects soon", you should
>> probably go that route.
>
> Effects are not the top priority. I've done quite a lot of research on it
> because it was a good topic for my intern to work on. I have other basic
> features to add first. And the schedule that you mention makes sense to me.

Hopefully it makes sense also to Dave as well, since everything else
that's needed is his stuff.

>> However, in the long run, I would avoid LADSPA for two reasons: 1.
>> lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts
>> without explicit support through the NASPRO bridges (which will be
>> able to work by default with SLV2 starting from the next SLV2 release,
>> otherwise you can grab the current svn SLV2 already).
>
> Hmm, I've been wandering in google yesterday about such LV2-LADSPA bridge.
>
> I am discovering the NASPRO project. That's interesting. It seems like it may
> consume a lot of brain-time diving into all this when compared to LADSPA. But
> I'm nevertheless a bit worried about adding support for LADSPA, as it's 
> getting
> old and somehow obsolete. But IIUC correctly you are about to add some sort of
> LADSPA backward compatibility, which in any case, sounds very good and was
> clearly missing.

It's already there if you want, the 0.2.0 release is from the last
year but should still work if you use a recent svn version of SLV2.

>> So it turns out it depends on how long you want to wait, or rather if
>> you would consider giving some help, and what you want to do with LV2.
>
> What kind of help would you need?

There are several departments. :-)

I've enumerated above the stuff missing from NASPRO core, then SLV2
should use it, and that would probably be a good part of the work
already.

> Also, are you/is there anyone on the list who is interested in releasing audio
> plugins for Android? Feel free to write me personally if needed.

I plan to develop a DSP language and compiler that generates LV2
plugins. Also in this case, a prototype is already in place (look for
"Permafrost" on the NASPRO website - no easy-to-read language
documentation yet, and both the syntax and the compiler have to be
redone, but I may get resources - time and moeny - to do this pretty
soon).

Then, there are some plugins I more or less did (but not released
yet). It's guitar fx stuff, however, so I don't know how they could be
used in Android (ideas?).

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/26/2011 07:18 PM, David Robillard wrote:

> I'm more in to shrinking the actual runtime memory overhead to the
> absolute bare minimum than shrinking the code. I have roughly infinity
> more useful things to do than pretending <100k libraries are bloated :)

Oddly, on most Android devices you actually have plenty of RAM to work with,
especially in native code where the Java maximum heap size do not apply.
Memory's not a bottleneck.

I wasn't saying that libraries <100k are bloated. So far, I had the impression
that we were in the order hundreds of kilobytes, which is too much for plugin
support in an app, when you think about it as a whole, which means codecs and
other deps.

> Replacing glib, it seems, is the main and by far most significant thing
> that needs doing to get a very small embedded appropriate limitation.
> The code size of my new libraries, IMO, is well within reasonable limits
> for anything that would use LV2 plugins.

All these changes sound very good to me.

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Sat, 2011-02-26 at 19:19 +0100, Olivier Guilyardi wrote:
> On 02/26/2011 06:45 PM, Stefano D'Angelo wrote:
> 
> >> Something like 100k-200K could be fine in my case, at the condition that 
> >> adding
> >> LV2 support provides a real benefit in terms of functionality.
> > 
> > This depends on what you are using it for and how. Being decentralized
> > & extensible, you could also use it to make coffee. :-)
> 
> Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be.

I think browser UI is definitely the way to go. Then it's a UI for
basically anything, and one that's inherently remote control capable.

I have a few ideas knocking around in the back of my head about simple
dynamic RAD for web based plugin GUIs...

> Aside, in the ui ext docs there's this example which contains ui:binary, but I
> can't find any reference documentation about this binary property on the page:
> http://lv2plug.in/ns/extensions/ui/

Noted. An error duplicated from an ealier LV2 spec. One of these days
I'll write a simple validator to catch this stuff...

> > However, in the long run, I would avoid LADSPA for two reasons: 1.
> > lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts
> > without explicit support through the NASPRO bridges (which will be
> > able to work by default with SLV2 starting from the next SLV2 release,
> > otherwise you can grab the current svn SLV2 already).
> 
> Hmm, I've been wandering in google yesterday about such LV2-LADSPA bridge.
> 
> I am discovering the NASPRO project. That's interesting. It seems like it may
> consume a lot of brain-time diving into all this when compared to LADSPA. But
> I'm nevertheless a bit worried about adding support for LADSPA, as it's 
> getting
> old and somehow obsolete. But IIUC correctly you are about to add some sort of
> LADSPA backward compatibility, which in any case, sounds very good and was
> clearly missing.

I just dropped explicit LADSPA support from Ingen in favour of NASPRO.
IMO, if the bridge is inadequate, then the bridge should be fixed, so
I'm investing in NASPRO, so to speak, so hopefully it remains a vibrant
project :)

>From a host author POV, it's pretty awesome to implement a single plugin
API and get full-featured support for (possibly) all the plugin APIs for
free...

-dr

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/26/2011 07:07 PM, David Robillard wrote:
> On Sat, 2011-02-26 at 17:33 +0100, Olivier Guilyardi wrote:
> [...]
>> This RDF turtle format is surely a beautiful thing when you write or read it,
>> but it requires such a parsing machinery...
> 
> The serd reader is about 1300 lines of C with no dependencies.

Sounds good.

>> What about an alternative format intended for lightweight packaging and 
>> parsing?
>> It would take the turtle metadata and convert it into a text file which 
>> could be
>> parsed with about 100 lines of C. It may not work for all plugins, but maybe 
>> for
>> the vast majority of them?
> 
> If you want a /really/ simple to parse RDF text format, it's ntriples.
> The actual data itself would become significantly larger than the space
> you save in the parsing code. I doubt this would be a net space savings,
> unless very few plugins are involved. You could gzip it or something,
> but then the plugin format is broken/wierd and you need even more
> machinery...
> 
> libserd.so is 34K on my 64-bit machine (compiled with -Os), and that
> includes an abbreviating serialiser. If you stripped it down to the
> reader it would be significantly smaller still (let's say halved).

I don't get it. Do you mean that libserd is the only thing that I would need in
the host?

>> At least I'm thinking about that kind of solution for packaging for Android.
>> Some kind of pre-parsing/metadata-simplification at packaging stage to avoid 
>> the
>> need for bundling a full-fledged parser.
> 
> Is that "full-fledged" parser really too big? You can't spend ~20K in a
> program that's loading plugins and doing audio processing? Let's keep
> things in perspective here: this parser is about as large as a simple
> plugin or two, and certainly smaller than some. I don't think claiming
> this is an unacceptable implementation size for using those plugins is
> at all reasonable. The heavyweight parsing machinery problem is a thing
> of the past.

20K? Now we're talking :)

But I don't understand exactly what's required in the host and also during
packaging to achieve such a tiny requirement.

--
  Olivier

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Sat, 2011-02-26 at 17:47 +0100, Stefano D'Angelo wrote:
> 2011/2/26 Olivier Guilyardi :
> > On 02/25/2011 09:13 PM, Stefano D'Angelo wrote:
[...]
> So, the latest SLV2 has dropped librdf in favor of a minimal
> RDF/Turtle implementation already done by Dave himself. Such
> implementation is basically made of two libraries: Serd (parser) and
> Sord (triple store).
> 
> Here is the size of the current svn SLV2 and its dependencies on my
> machine (arch linux x86-64), all stripped, yet probably compiled with
> -02, excluing glib: libslv2 is 61K, libsord is 29K, libserd is 44K,
> libpcre is 236K (I didn't know it was a dependency, what is it for
> Dave?). That means: slv2+sord+serd = 134K, adding pcre is 370K.

PCRE is a dependency of glib. I don't use regular expressions in these
projects.

> Now, libnacore when stripped is 56K... if it could substitute both
> pcre and glib, it would mean the whole stack = 190K + something else.
> 
> Considering that Android platforms are probably 32 bit (right?) and
> stuff could be compiled with -Os, I would say we would end up
> somewhere in between 100 to 250K. Is that still too much?

I could probably make slv2 itself smaller by using a single
non-type-safe collection type rather than the different collection type
for each element type which is the current situation (stupid neanderthal
type primitive type systems). This would reduce the number of functions
quite a bit. Other 'function compression' could also happen, but this
all would break the API thoroughly. Type safety (i.e. lack of dirty
casts and confusing API to use) here is more important than code size,
which I don't think is unreasonable anyway.

I'm more in to shrinking the actual runtime memory overhead to the
absolute bare minimum than shrinking the code. I have roughly infinity
more useful things to do than pretending <100k libraries are bloated :)

Replacing glib, it seems, is the main and by far most significant thing
that needs doing to get a very small embedded appropriate limitation.
The code size of my new libraries, IMO, is well within reasonable limits
for anything that would use LV2 plugins.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/26/2011 06:45 PM, Stefano D'Angelo wrote:

>> Something like 100k-200K could be fine in my case, at the condition that 
>> adding
>> LV2 support provides a real benefit in terms of functionality.
> 
> This depends on what you are using it for and how. Being decentralized
> & extensible, you could also use it to make coffee. :-)

Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be.

Aside, in the ui ext docs there's this example which contains ui:binary, but I
can't find any reference documentation about this binary property on the page:
http://lv2plug.in/ns/extensions/ui/

>> I don't want to wake up old trolls, but last fall, when I had a sound 
>> engineer
>> intern working on the topic, we ended up thinking that integrating LADSPA 
>> would
>> really be straightforward. No such overhead, great portability, and plenty of
>> plugins.
> 
>> So most logically, when time comes to add plugin support, I will start with
>> LADSPA. LV2 will maybe come afterwards. But this could change if there 
>> suddenly
>> is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages 
>> arrive
>> on the Android Market.
> 
> I respect your choice and understand the rationale. Also, all of this
> changes won't happen by tomorrow (my guess is 2/3 months, based on
> feeling more than facts), so if you "need effects soon", you should
> probably go that route.

Effects are not the top priority. I've done quite a lot of research on it
because it was a good topic for my intern to work on. I have other basic
features to add first. And the schedule that you mention makes sense to me.

> However, in the long run, I would avoid LADSPA for two reasons: 1.
> lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts
> without explicit support through the NASPRO bridges (which will be
> able to work by default with SLV2 starting from the next SLV2 release,
> otherwise you can grab the current svn SLV2 already).

Hmm, I've been wandering in google yesterday about such LV2-LADSPA bridge.

I am discovering the NASPRO project. That's interesting. It seems like it may
consume a lot of brain-time diving into all this when compared to LADSPA. But
I'm nevertheless a bit worried about adding support for LADSPA, as it's getting
old and somehow obsolete. But IIUC correctly you are about to add some sort of
LADSPA backward compatibility, which in any case, sounds very good and was
clearly missing.

> So it turns out it depends on how long you want to wait, or rather if
> you would consider giving some help, and what you want to do with LV2.

What kind of help would you need?

Also, are you/is there anyone on the list who is interested in releasing audio
plugins for Android? Feel free to write me personally if needed.

--
  Olivier

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Sat, 2011-02-26 at 17:33 +0100, Olivier Guilyardi wrote:
[...]
> This RDF turtle format is surely a beautiful thing when you write or read it,
> but it requires such a parsing machinery...

The serd reader is about 1300 lines of C with no dependencies.

> What about an alternative format intended for lightweight packaging and 
> parsing?
> It would take the turtle metadata and convert it into a text file which could 
> be
> parsed with about 100 lines of C. It may not work for all plugins, but maybe 
> for
> the vast majority of them?

If you want a /really/ simple to parse RDF text format, it's ntriples.
The actual data itself would become significantly larger than the space
you save in the parsing code. I doubt this would be a net space savings,
unless very few plugins are involved. You could gzip it or something,
but then the plugin format is broken/wierd and you need even more
machinery...

libserd.so is 34K on my 64-bit machine (compiled with -Os), and that
includes an abbreviating serialiser. If you stripped it down to the
reader it would be significantly smaller still (let's say halved).

> At least I'm thinking about that kind of solution for packaging for Android.
> Some kind of pre-parsing/metadata-simplification at packaging stage to avoid 
> the
> need for bundling a full-fledged parser.

Is that "full-fledged" parser really too big? You can't spend ~20K in a
program that's loading plugins and doing audio processing? Let's keep
things in perspective here: this parser is about as large as a simple
plugin or two, and certainly smaller than some. I don't think claiming
this is an unacceptable implementation size for using those plugins is
at all reasonable. The heavyweight parsing machinery problem is a thing
of the past.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/26 David Robillard :
> On Sat, 2011-02-26 at 15:11 +0100, Stefano D'Angelo wrote:
>> 2011/2/25 David Robillard :
>> > On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
>> >> On 02/25/2011 08:57 PM, David Robillard wrote:
>> >>
>> >> >> It's a few months ago now that I investigated LV2. IIRC, at that time I
>> >> >> concluded that this wasn't an option because SLV2 was GPL'ed. But 
>> >> >> things are
>> >> >> changing IIUC :)
>> >> >
>> >> > You never asked. I would have changed it... but I am not psychic ;)
>> >>
>> >> It's not always easy to discuss about religious matters, such as licenses 
>> >> ;)
>> >>
>> >> That said there is another big problem. This glib dependency, it's way 
>> >> too heavy
>> >> for mobile deployment.
>> >
>> > Glib was the most effective route of getting the job done - rewriting
>> > the few bits that are required is not an effective use of my time right
>> > now (it's not exposed in the API, so it's not a compatibility issue, and
>> > there's a ton of more pressing LV2 things that need doing).
>> >
>> > I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
>> > unoffensive a dependency as they come. On mobile, I guess that meg or so
>> > actually makes a difference.
>> >
>> > Replacing glib will not be very difficult, very little of it is used:
>> > just a balanced BST, dynamic array, and ideally a hash table or trie
>> > other appropriate structure for string interning (the BST would do for
>> > this part, with a bit of a performance cost). Good old-fashioned data
>> > structure implementation is my favourite thing to do, but unfortunately
>> > there is no shortage of more pragmatic things that need doing ;)
>> >
>> > Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
>> > just tearing the required bits out of glib itself. Sqlite has an
>> > in-memory hash table IIRC. Code abounds.
>> >
>> > Present a viable alternative, and I'll switch sord/slv2 to it, but I
>> > have no good reason to invest time in reinventing glib right now.
>>
>> Given the discussions we had already, NASPRO core could be a viable 
>> alternative.
>>
>> Pros:
>> - no dependencies apart from libc and libm
>> - size (181K without stripping on Arch Linux x86-64, -O2)
>> - high portability, little and confined platform-specific code,
>> compiler-specific (symbol visibility, etc.) code confined to a small
>> header
>> - gracefully handles platform-specific conventions (i.e., ':' vs ';'
>> in path variables, zero-length prefixes in path variables under *nix,
>> directory separators, etc.)
>> - total amount of code is circa 7.5k lines, including comments and
>> public headers
>> - UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme
>> counting is supported
>> - thread safety (e.g., data types are synchronized at a very granular
>> level, but allow you to have more coarse synchronization if you want)
>> - extremely low memory footprint
>> - locale-independent asprintf() and vasprintf(), C99 level (except
>> "%lc" and "%ls" conversions, possibly they are not even needed if
>> using UTF-8)
>> - semi-serious, integrated and as-lightweight-as-it-can-be
>> error/message reporting mechanism
>> - precise and well defined error checking and error codes
>> - includes directory traversal, dynamic loading
>> - well documented
>>
>> Cons:
>> - not yet released
>> - no real test suite and not extensively tested
>> - currently implemented data types: doubly linked lists and AVL trees only
>> - not yet ported to non POSIX platforms (i.e., Windows)
>> - API/ABI are "stable enough", but can't guarantee for total stability
>> in the next future (i.e., no big changes will happen, yet something
>> might change)
>> - no locale-independent sscanf() or similar
>> - no UTF16-BE support/conversion
>> - till now, a one man effort
>>
>> That is, it is certainly possible to make it become viable to replace
>> SLV2, but this is not high priority for me at the moment. Once the new
>> NASPRO release is out I can consider whether to do the work, since I
>> want to port SLV2 to Windows right after.
>>
>> The decision, however, depends on whether Dave would like that or not.
>
> Sure. Sounds good, probably a good choice, and it would be nice if your
> work - originally intended to escape slv2 - could be used by it to make
> a better general solution instead :)

You got the idea. :-D
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/26 Olivier Guilyardi :
> On 02/26/2011 05:47 PM, Stefano D'Angelo wrote:
>
>> So, the latest SLV2 has dropped librdf in favor of a minimal
>> RDF/Turtle implementation already done by Dave himself. Such
>> implementation is basically made of two libraries: Serd (parser) and
>> Sord (triple store).
>
> I was unsure librdf. It's good to know that it's not needed anymore
>
>> Here is the size of the current svn SLV2 and its dependencies on my
>> machine (arch linux x86-64), all stripped, yet probably compiled with
>> -02, excluing glib: libslv2 is 61K, libsord is 29K, libserd is 44K,
>> libpcre is 236K (I didn't know it was a dependency, what is it for
>> Dave?). That means: slv2+sord+serd = 134K, adding pcre is 370K.
>>
>> Now, libnacore when stripped is 56K... if it could substitute both
>> pcre and glib, it would mean the whole stack = 190K + something else.
>>
>> Considering that Android platforms are probably 32 bit (right?) and
>> stuff could be compiled with -Os, I would say we would end up
>> somewhere in between 100 to 250K. Is that still too much?
>
> Yes, ARM, 32bit. But, with the Android NDK, "By default, ARM target binaries
> will be generated in 'thumb' mode, where each instruction are 16-bit wide.".
> This is intended to save space.

Ah, didn't know. :-) Never actually used the NDK, only the SDK.

> The only way to know what size it will really take is to compile with the
> Android NDK. Also, linking statically when using a reasonable set of SLV2
> functions would give a more realistic figure. This should also avoid extra ELF
> stuff when creating an .so.

Ah sure, static linking would cut out some unneeded code too. Don't
really know how much actually.

> I haven't played so much with flags such as -Os because there's like a very 
> very
> careful mood about portability when compiling native libraries for Android. 
> The
> NDK already sets various optimization flags. But this could be worked around.
>
> Something like 100k-200K could be fine in my case, at the condition that 
> adding
> LV2 support provides a real benefit in terms of functionality.

This depends on what you are using it for and how. Being decentralized
& extensible, you could also use it to make coffee. :-)

> I don't want to wake up old trolls, but last fall, when I had a sound engineer
> intern working on the topic, we ended up thinking that integrating LADSPA 
> would
> really be straightforward. No such overhead, great portability, and plenty of
> plugins.

> So most logically, when time comes to add plugin support, I will start with
> LADSPA. LV2 will maybe come afterwards. But this could change if there 
> suddenly
> is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages 
> arrive
> on the Android Market.

I respect your choice and understand the rationale. Also, all of this
changes won't happen by tomorrow (my guess is 2/3 months, based on
feeling more than facts), so if you "need effects soon", you should
probably go that route.

However, in the long run, I would avoid LADSPA for two reasons: 1.
lack of extensibility, etc., 2. LADSPA plugins can run into LV2 hosts
without explicit support through the NASPRO bridges (which will be
able to work by default with SLV2 starting from the next SLV2 release,
otherwise you can grab the current svn SLV2 already).

So it turns out it depends on how long you want to wait, or rather if
you would consider giving some help, and what you want to do with LV2.

HTH,

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Sat, 2011-02-26 at 15:11 +0100, Stefano D'Angelo wrote:
> 2011/2/25 David Robillard :
> > On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
> >> On 02/25/2011 08:57 PM, David Robillard wrote:
> >>
> >> >> It's a few months ago now that I investigated LV2. IIRC, at that time I
> >> >> concluded that this wasn't an option because SLV2 was GPL'ed. But 
> >> >> things are
> >> >> changing IIUC :)
> >> >
> >> > You never asked. I would have changed it... but I am not psychic ;)
> >>
> >> It's not always easy to discuss about religious matters, such as licenses 
> >> ;)
> >>
> >> That said there is another big problem. This glib dependency, it's way too 
> >> heavy
> >> for mobile deployment.
> >
> > Glib was the most effective route of getting the job done - rewriting
> > the few bits that are required is not an effective use of my time right
> > now (it's not exposed in the API, so it's not a compatibility issue, and
> > there's a ton of more pressing LV2 things that need doing).
> >
> > I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
> > unoffensive a dependency as they come. On mobile, I guess that meg or so
> > actually makes a difference.
> >
> > Replacing glib will not be very difficult, very little of it is used:
> > just a balanced BST, dynamic array, and ideally a hash table or trie
> > other appropriate structure for string interning (the BST would do for
> > this part, with a bit of a performance cost). Good old-fashioned data
> > structure implementation is my favourite thing to do, but unfortunately
> > there is no shortage of more pragmatic things that need doing ;)
> >
> > Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
> > just tearing the required bits out of glib itself. Sqlite has an
> > in-memory hash table IIRC. Code abounds.
> >
> > Present a viable alternative, and I'll switch sord/slv2 to it, but I
> > have no good reason to invest time in reinventing glib right now.
> 
> Given the discussions we had already, NASPRO core could be a viable 
> alternative.
> 
> Pros:
> - no dependencies apart from libc and libm
> - size (181K without stripping on Arch Linux x86-64, -O2)
> - high portability, little and confined platform-specific code,
> compiler-specific (symbol visibility, etc.) code confined to a small
> header
> - gracefully handles platform-specific conventions (i.e., ':' vs ';'
> in path variables, zero-length prefixes in path variables under *nix,
> directory separators, etc.)
> - total amount of code is circa 7.5k lines, including comments and
> public headers
> - UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme
> counting is supported
> - thread safety (e.g., data types are synchronized at a very granular
> level, but allow you to have more coarse synchronization if you want)
> - extremely low memory footprint
> - locale-independent asprintf() and vasprintf(), C99 level (except
> "%lc" and "%ls" conversions, possibly they are not even needed if
> using UTF-8)
> - semi-serious, integrated and as-lightweight-as-it-can-be
> error/message reporting mechanism
> - precise and well defined error checking and error codes
> - includes directory traversal, dynamic loading
> - well documented
> 
> Cons:
> - not yet released
> - no real test suite and not extensively tested
> - currently implemented data types: doubly linked lists and AVL trees only
> - not yet ported to non POSIX platforms (i.e., Windows)
> - API/ABI are "stable enough", but can't guarantee for total stability
> in the next future (i.e., no big changes will happen, yet something
> might change)
> - no locale-independent sscanf() or similar
> - no UTF16-BE support/conversion
> - till now, a one man effort
> 
> That is, it is certainly possible to make it become viable to replace
> SLV2, but this is not high priority for me at the moment. Once the new
> NASPRO release is out I can consider whether to do the work, since I
> want to port SLV2 to Windows right after.
> 
> The decision, however, depends on whether Dave would like that or not.

Sure. Sounds good, probably a good choice, and it would be nice if your
work - originally intended to escape slv2 - could be used by it to make
a better general solution instead :)

Like you, I think releasing the current state of things is a higher
priority though. Plenty enough improvement and new libraries lately as
it is, time to kick it out the door and get it on users machines. We can
look into this.. y'know.. later.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/26/2011 05:47 PM, Stefano D'Angelo wrote:

> So, the latest SLV2 has dropped librdf in favor of a minimal
> RDF/Turtle implementation already done by Dave himself. Such
> implementation is basically made of two libraries: Serd (parser) and
> Sord (triple store).

I was unsure librdf. It's good to know that it's not needed anymore

> Here is the size of the current svn SLV2 and its dependencies on my
> machine (arch linux x86-64), all stripped, yet probably compiled with
> -02, excluing glib: libslv2 is 61K, libsord is 29K, libserd is 44K,
> libpcre is 236K (I didn't know it was a dependency, what is it for
> Dave?). That means: slv2+sord+serd = 134K, adding pcre is 370K.
> 
> Now, libnacore when stripped is 56K... if it could substitute both
> pcre and glib, it would mean the whole stack = 190K + something else.
> 
> Considering that Android platforms are probably 32 bit (right?) and
> stuff could be compiled with -Os, I would say we would end up
> somewhere in between 100 to 250K. Is that still too much?

Yes, ARM, 32bit. But, with the Android NDK, "By default, ARM target binaries
will be generated in 'thumb' mode, where each instruction are 16-bit wide.".
This is intended to save space.

The only way to know what size it will really take is to compile with the
Android NDK. Also, linking statically when using a reasonable set of SLV2
functions would give a more realistic figure. This should also avoid extra ELF
stuff when creating an .so.

I haven't played so much with flags such as -Os because there's like a very very
careful mood about portability when compiling native libraries for Android. The
NDK already sets various optimization flags. But this could be worked around.

Something like 100k-200K could be fine in my case, at the condition that adding
LV2 support provides a real benefit in terms of functionality.

I don't want to wake up old trolls, but last fall, when I had a sound engineer
intern working on the topic, we ended up thinking that integrating LADSPA would
really be straightforward. No such overhead, great portability, and plenty of
plugins.

So most logically, when time comes to add plugin support, I will start with
LADSPA. LV2 will maybe come afterwards. But this could change if there suddenly
is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages arrive
on the Android Market.

--
  Olivier

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/26 Olivier Guilyardi :
> On 02/25/2011 09:13 PM, Stefano D'Angelo wrote:
>> 2011/2/25 Olivier Guilyardi :
>
>>> That said there is another big problem. This glib dependency, it's way too 
>>> heavy
>>> for mobile deployment.
>>
>> Since this was already discussed and we happen to have possible GLib
>> replacements, could you expand on that? Why is it too heavy?
>
> Size. There are two bottlenecks related to size when deploying on Android:
>
> - the space it takes on the device. In the past apps could only be installed 
> in
> the device internal memory, and it is often quite small, like about 150Mb.
> People tend to install a lot of apps so this gets filled quickly. So, a
> mechanism, app2sd, has been added to allow installing apps on the sdcard, 
> which
> is usually more than 8Gb. But this doesn't work for native libraries, because
> the sdcard is mounted noexec. You can use app2sd, but the native libraries
> provided by the app are copied to internal memory.
>
> - the download time. It is common for users to download apps when they're on 
> the
> go, and thus possibly using a bad internet link.
>
> My app is currently a little less than 1Mb, and I actually don't really want 
> to
> make it bigger. Some games can get big, but my app isn't a game, it's intended
> to be lightweight.
>
> For example, I needed to add a little magic, to detect file formats. So I
> grabbed libmagic, compiled that, linked statically, and IIRC it resulted in a
> size increase of about 200Kb. That was quite unacceptable for such a simple
> functionality.
>
> So, I read the code and libmagic metadata files, and I implemented my own 
> magic
> (OGG, WAV, FLAC, AIFF, MP3) in about 30 lines of C. I had a couple of bugs, 
> but
> it now works flawlessly.
>
> That said, I would need to test what kind of size it takes when linking
> statically against SLV2. But I will need to support glib as a shared library 
> or
> something like that because of the LGPL. That's a lot of complication.
>
> This RDF turtle format is surely a beautiful thing when you write or read it,
> but it requires such a parsing machinery...
>
> What about an alternative format intended for lightweight packaging and 
> parsing?
> It would take the turtle metadata and convert it into a text file which could 
> be
> parsed with about 100 lines of C. It may not work for all plugins, but maybe 
> for
> the vast majority of them?
>
> At least I'm thinking about that kind of solution for packaging for Android.
> Some kind of pre-parsing/metadata-simplification at packaging stage to avoid 
> the
> need for bundling a full-fledged parser.

So, the latest SLV2 has dropped librdf in favor of a minimal
RDF/Turtle implementation already done by Dave himself. Such
implementation is basically made of two libraries: Serd (parser) and
Sord (triple store).

Here is the size of the current svn SLV2 and its dependencies on my
machine (arch linux x86-64), all stripped, yet probably compiled with
-02, excluing glib: libslv2 is 61K, libsord is 29K, libserd is 44K,
libpcre is 236K (I didn't know it was a dependency, what is it for
Dave?). That means: slv2+sord+serd = 134K, adding pcre is 370K.

Now, libnacore when stripped is 56K... if it could substitute both
pcre and glib, it would mean the whole stack = 190K + something else.

Considering that Android platforms are probably 32 bit (right?) and
stuff could be compiled with -Os, I would say we would end up
somewhere in between 100 to 250K. Is that still too much?

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 09:13 PM, Stefano D'Angelo wrote:
> 2011/2/25 Olivier Guilyardi :

>> That said there is another big problem. This glib dependency, it's way too 
>> heavy
>> for mobile deployment.
> 
> Since this was already discussed and we happen to have possible GLib
> replacements, could you expand on that? Why is it too heavy?

Size. There are two bottlenecks related to size when deploying on Android:

- the space it takes on the device. In the past apps could only be installed in
the device internal memory, and it is often quite small, like about 150Mb.
People tend to install a lot of apps so this gets filled quickly. So, a
mechanism, app2sd, has been added to allow installing apps on the sdcard, which
is usually more than 8Gb. But this doesn't work for native libraries, because
the sdcard is mounted noexec. You can use app2sd, but the native libraries
provided by the app are copied to internal memory.

- the download time. It is common for users to download apps when they're on the
go, and thus possibly using a bad internet link.

My app is currently a little less than 1Mb, and I actually don't really want to
make it bigger. Some games can get big, but my app isn't a game, it's intended
to be lightweight.

For example, I needed to add a little magic, to detect file formats. So I
grabbed libmagic, compiled that, linked statically, and IIRC it resulted in a
size increase of about 200Kb. That was quite unacceptable for such a simple
functionality.

So, I read the code and libmagic metadata files, and I implemented my own magic
(OGG, WAV, FLAC, AIFF, MP3) in about 30 lines of C. I had a couple of bugs, but
it now works flawlessly.

That said, I would need to test what kind of size it takes when linking
statically against SLV2. But I will need to support glib as a shared library or
something like that because of the LGPL. That's a lot of complication.

This RDF turtle format is surely a beautiful thing when you write or read it,
but it requires such a parsing machinery...

What about an alternative format intended for lightweight packaging and parsing?
It would take the turtle metadata and convert it into a text file which could be
parsed with about 100 lines of C. It may not work for all plugins, but maybe for
the vast majority of them?

At least I'm thinking about that kind of solution for packaging for Android.
Some kind of pre-parsing/metadata-simplification at packaging stage to avoid the
need for bundling a full-fledged parser.

--
  Olivier

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/26 Stefano D'Angelo :
> 2011/2/25 David Robillard :
>> On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
>>> On 02/25/2011 08:57 PM, David Robillard wrote:
>>>
>>> >> It's a few months ago now that I investigated LV2. IIRC, at that time I
>>> >> concluded that this wasn't an option because SLV2 was GPL'ed. But things 
>>> >> are
>>> >> changing IIUC :)
>>> >
>>> > You never asked. I would have changed it... but I am not psychic ;)
>>>
>>> It's not always easy to discuss about religious matters, such as licenses ;)
>>>
>>> That said there is another big problem. This glib dependency, it's way too 
>>> heavy
>>> for mobile deployment.
>>
>> Glib was the most effective route of getting the job done - rewriting
>> the few bits that are required is not an effective use of my time right
>> now (it's not exposed in the API, so it's not a compatibility issue, and
>> there's a ton of more pressing LV2 things that need doing).
>>
>> I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
>> unoffensive a dependency as they come. On mobile, I guess that meg or so
>> actually makes a difference.
>>
>> Replacing glib will not be very difficult, very little of it is used:
>> just a balanced BST, dynamic array, and ideally a hash table or trie
>> other appropriate structure for string interning (the BST would do for
>> this part, with a bit of a performance cost). Good old-fashioned data
>> structure implementation is my favourite thing to do, but unfortunately
>> there is no shortage of more pragmatic things that need doing ;)
>>
>> Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
>> just tearing the required bits out of glib itself. Sqlite has an
>> in-memory hash table IIRC. Code abounds.
>>
>> Present a viable alternative, and I'll switch sord/slv2 to it, but I
>> have no good reason to invest time in reinventing glib right now.
>
> Given the discussions we had already, NASPRO core could be a viable 
> alternative.
>
> Pros:
> - no dependencies apart from libc and libm
> - size (181K without stripping on Arch Linux x86-64, -O2)
> - high portability, little and confined platform-specific code,
> compiler-specific (symbol visibility, etc.) code confined to a small
> header
> - gracefully handles platform-specific conventions (i.e., ':' vs ';'
> in path variables, zero-length prefixes in path variables under *nix,
> directory separators, etc.)
> - total amount of code is circa 7.5k lines, including comments and
> public headers
> - UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme
> counting is supported
> - thread safety (e.g., data types are synchronized at a very granular
> level, but allow you to have more coarse synchronization if you want)
> - extremely low memory footprint
> - locale-independent asprintf() and vasprintf(), C99 level (except
> "%lc" and "%ls" conversions, possibly they are not even needed if
> using UTF-8)
> - semi-serious, integrated and as-lightweight-as-it-can-be
> error/message reporting mechanism
> - precise and well defined error checking and error codes
> - includes directory traversal, dynamic loading
> - well documented
>
> Cons:
> - not yet released
> - no real test suite and not extensively tested
> - currently implemented data types: doubly linked lists and AVL trees only
> - not yet ported to non POSIX platforms (i.e., Windows)
> - API/ABI are "stable enough", but can't guarantee for total stability
> in the next future (i.e., no big changes will happen, yet something
> might change)
> - no locale-independent sscanf() or similar
> - no UTF16-BE support/conversion
> - till now, a one man effort
>
> That is, it is certainly possible to make it become viable to replace
> SLV2

Oops, I meant, to replace GLib in SLV2.

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/25 David Robillard :
> On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
>> On 02/25/2011 08:57 PM, David Robillard wrote:
>>
>> >> It's a few months ago now that I investigated LV2. IIRC, at that time I
>> >> concluded that this wasn't an option because SLV2 was GPL'ed. But things 
>> >> are
>> >> changing IIUC :)
>> >
>> > You never asked. I would have changed it... but I am not psychic ;)
>>
>> It's not always easy to discuss about religious matters, such as licenses ;)
>>
>> That said there is another big problem. This glib dependency, it's way too 
>> heavy
>> for mobile deployment.
>
> Glib was the most effective route of getting the job done - rewriting
> the few bits that are required is not an effective use of my time right
> now (it's not exposed in the API, so it's not a compatibility issue, and
> there's a ton of more pressing LV2 things that need doing).
>
> I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
> unoffensive a dependency as they come. On mobile, I guess that meg or so
> actually makes a difference.
>
> Replacing glib will not be very difficult, very little of it is used:
> just a balanced BST, dynamic array, and ideally a hash table or trie
> other appropriate structure for string interning (the BST would do for
> this part, with a bit of a performance cost). Good old-fashioned data
> structure implementation is my favourite thing to do, but unfortunately
> there is no shortage of more pragmatic things that need doing ;)
>
> Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
> just tearing the required bits out of glib itself. Sqlite has an
> in-memory hash table IIRC. Code abounds.
>
> Present a viable alternative, and I'll switch sord/slv2 to it, but I
> have no good reason to invest time in reinventing glib right now.

Given the discussions we had already, NASPRO core could be a viable alternative.

Pros:
- no dependencies apart from libc and libm
- size (181K without stripping on Arch Linux x86-64, -O2)
- high portability, little and confined platform-specific code,
compiler-specific (symbol visibility, etc.) code confined to a small
header
- gracefully handles platform-specific conventions (i.e., ':' vs ';'
in path variables, zero-length prefixes in path variables under *nix,
directory separators, etc.)
- total amount of code is circa 7.5k lines, including comments and
public headers
- UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme
counting is supported
- thread safety (e.g., data types are synchronized at a very granular
level, but allow you to have more coarse synchronization if you want)
- extremely low memory footprint
- locale-independent asprintf() and vasprintf(), C99 level (except
"%lc" and "%ls" conversions, possibly they are not even needed if
using UTF-8)
- semi-serious, integrated and as-lightweight-as-it-can-be
error/message reporting mechanism
- precise and well defined error checking and error codes
- includes directory traversal, dynamic loading
- well documented

Cons:
- not yet released
- no real test suite and not extensively tested
- currently implemented data types: doubly linked lists and AVL trees only
- not yet ported to non POSIX platforms (i.e., Windows)
- API/ABI are "stable enough", but can't guarantee for total stability
in the next future (i.e., no big changes will happen, yet something
might change)
- no locale-independent sscanf() or similar
- no UTF16-BE support/conversion
- till now, a one man effort

That is, it is certainly possible to make it become viable to replace
SLV2, but this is not high priority for me at the moment. Once the new
NASPRO release is out I can consider whether to do the work, since I
want to port SLV2 to Windows right after.

The decision, however, depends on whether Dave would like that or not.

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Jörn Nettingsmeier]

On 02/26/2011 05:12 AM, Paul Davis wrote:

2) Is Richard contactable? If not, what was his contribution to


his company in london is active and in the audio software business
(ambisonics for the masses, IIRC). i can't remember its name right
now, but i bumped into by accident a month or two ago.


richard is reachable as first name at muse440 dot com.
his company is http://blueripplesound.com

is there a problem wrt ladspa unique ids?
last time i tried, he responded within 1-2 days, but granted that's been 
a while.


best,

jörn

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Fri, Feb 25, 2011 at 9:27 PM, David Robillard  wrote:

> If we want to do it, this is the copyright situation:
>
> Copyright (C) 2000-2002 Richard W.E. Furse, Paul Barton-Davis,
>                        Stefan Westerfeld.
> Copyright (C) 2006-2010 Steve Harris, David Robillard.

> 1) Does everyone present support making lv2.h 2-clause BSD? Some other
> alternative, perhaps? (you can also explicitly absolve yourself of the
> copyright if you'd prefer)

BSD is fine with me.

> 2) Is Richard contactable? If not, what was his contribution to

his company in london is active and in the audio software business
(ambisonics for the masses, IIRC). i can't remember its name right
now, but i bumped into by accident a month or two ago.

--p
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-02-25 at 20:44 -0500, Paul Davis wrote:
> On Fri, Feb 25, 2011 at 7:52 PM, David Robillard  wrote:
> 
> > The LGPL is wonderful. It lets you write a library that has the GPL
> > benefits (i.e. you can't take my code and proprietary-ize it without
> > sharing), while allowing proprietary projects to make use of the
> > library.
> 
> as long as they can meet the relink requirements. not always a trivial matter.

True, but there's good reasons those requirements are there. Perhaps
there is use for a "LGPL without relink" requirements, but... oh well.

(Obligatory disclaimer: I am not a lawyer, and the following is not
legal advice)

Note that relinking is inherently trivial with the typical use of LV2,
since it's an interface for dynamically loaded modules, but it is
possible to use the LV2 interface statically, which (though pretty
weird) might make sense in some embedded scenarios.

The LGPL is a tool for keeping your library implementation free. For
lv2.h, there isn't even an implementation to keep free. It's all a bit
silly anyway; you could easily take an LV2 plugin binary and clean-room
reverse engineer a compatible spec without having ever even heard about
lv2.h, let alone seen or copied it. Restrictive licenses have no place
in generic(*) plugin APIs! (yes, I'm looking at you, Steinberg). A more
liberal license seems more appropriate, particularly since widespread
adoption of LV2, including by proprietary software, is desirable, and a
win for free software (and everyone). If this is a blocker for
implementing LV2 on mobile devices or whatever, that's a problem. The
license is just being a nuisance and hindering progress without
protecting anything anyway.

If we want to do it, this is the copyright situation:

Copyright (C) 2000-2002 Richard W.E. Furse, Paul Barton-Davis,
Stefan Westerfeld.
Copyright (C) 2006-2010 Steve Harris, David Robillard.

Everyone here is still active, except perhaps Richard? IIRC his
disappearance became a problem with LADSPA ID allocation...

So, questions:

1) Does everyone present support making lv2.h 2-clause BSD? Some other
alternative, perhaps? (you can also explicitly absolve yourself of the
copyright if you'd prefer)

2) Is Richard contactable? If not, what was his contribution to
ladspa.h, and has it actually made it in to lv2.h? Much has been removed
(lv2.h is roughly half the size of ladspa.h), it's quite possible it has
not.

Personally, I could go either way. I'm down if everyone else is.

-dr

(* Note the "generic" part is important, since module and host are not
derivative works of each other, which is not true of all modules)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Fri, Feb 25, 2011 at 7:52 PM, David Robillard  wrote:

> The LGPL is wonderful. It lets you write a library that has the GPL
> benefits (i.e. you can't take my code and proprietary-ize it without
> sharing), while allowing proprietary projects to make use of the
> library.

as long as they can meet the relink requirements. not always a trivial matter.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-02-25 at 23:17 +, Chris Cannam wrote:
> 
> On 25 Feb 2011 18:34, "David Robillard"  wrote:
> >
> > I switched Serd and Sord to 2-clause BSD. Enjoy. 
> 
> Thanks! I hope to.
> 
> > The license header is
> > bigger and uglier and has a bunch of lawyer boiler-plate yelling in
> it,
> > which I am not aesthetically please with at all... :)
> 
> I've always rather liked the look of the BSD boilerplate.

I like the apache 2.0 one because it's pretty and short and free of
lawyer. Alas, it's incompatible with (L)GPLv2... technically I could
make a similar header myself and use it, but there's no decent somewhat
canonical URI to refer to a BSD license I can find.

Of course we're all plenty used to just mentally skipping all the
boilerplate, but I like pretty things anyway :)

> > This made me notice something though: lv2.h itself is LGPL
> (inherited
> > from ladspa.h). So, if you're implementing an LV2 host there's
> > inherently LGPL involved anyway.
> 
> For me that's OK, an LV2 implementation would be of rather different
> purpose from a general store implementation.  Though I can imagine
> others finding it difficult -- I've noticed some confusion about what
> exactly the LGPL means for use of the LADSPA header in the past.

We could attempt to contact everyone involved and get approval to switch
it and/or absolve themselves of copyright on it...

> > I am fully on the pro-GPL card-carrying FSF member team
> 
> I can see many cases for GPL libraries and BSD libraries, but I've not
> so often been convinced by the use of the LGPL.

The LGPL is wonderful. It lets you write a library that has the GPL
benefits (i.e. you can't take my code and proprietary-ize it without
sharing), while allowing proprietary projects to make use of the
library.

In a world free of selfish dickheads, public domain would be all we
need. In this one, the LGPL is nice :)

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Chris Cannam]

On 25 Feb 2011 18:34, "David Robillard"  wrote:
>
> I switched Serd and Sord to 2-clause BSD. Enjoy.

Thanks! I hope to.

> The license header is
> bigger and uglier and has a bunch of lawyer boiler-plate yelling in it,
> which I am not aesthetically please with at all... :)

I've always rather liked the look of the BSD boilerplate.

> This made me notice something though: lv2.h itself is LGPL (inherited
> from ladspa.h). So, if you're implementing an LV2 host there's
> inherently LGPL involved anyway.

For me that's OK, an LV2 implementation would be of rather different purpose
from a general store implementation.  Though I can imagine others finding it
difficult -- I've noticed some confusion about what exactly the LGPL means
for use of the LADSPA header in the past.

> I am fully on the pro-GPL card-carrying FSF member team

I can see many cases for GPL libraries and BSD libraries, but I've not so
often been convinced by the use of the LGPL.

Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Fri, Feb 25, 2011 at 4:02 PM, Jeremy Salwen  wrote:
> On Fri, Feb 25, 2011 at 3:09 PM, Olivier Guilyardi 
> wrote:
>>
>> That said there is another big problem. This glib dependency, it's way too
>> heavy
>> for mobile deployment.
>
> Perhaps one of these alternatives could work as a stand-in replacement?
>
> https://secure.wikimedia.org/wikipedia/en/wiki/GNU_C_Library#Use_in_small_devices

glib != glibc

two very, very different libraries.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Jeremy Salwen]

On Fri, Feb 25, 2011 at 3:09 PM, Olivier Guilyardi wrote:

>
> That said there is another big problem. This glib dependency, it's way too
> heavy
> for mobile deployment.
>

Perhaps one of these alternatives could work as a stand-in replacement?

https://secure.wikimedia.org/wikipedia/en/wiki/GNU_C_Library#Use_in_small_devices

Jeremy
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
> On 02/25/2011 08:57 PM, David Robillard wrote:
> 
> >> It's a few months ago now that I investigated LV2. IIRC, at that time I
> >> concluded that this wasn't an option because SLV2 was GPL'ed. But things 
> >> are
> >> changing IIUC :)
> > 
> > You never asked. I would have changed it... but I am not psychic ;)
> 
> It's not always easy to discuss about religious matters, such as licenses ;)
> 
> That said there is another big problem. This glib dependency, it's way too 
> heavy
> for mobile deployment.

Glib was the most effective route of getting the job done - rewriting
the few bits that are required is not an effective use of my time right
now (it's not exposed in the API, so it's not a compatibility issue, and
there's a ton of more pressing LV2 things that need doing).

I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
unoffensive a dependency as they come. On mobile, I guess that meg or so
actually makes a difference.

Replacing glib will not be very difficult, very little of it is used:
just a balanced BST, dynamic array, and ideally a hash table or trie
other appropriate structure for string interning (the BST would do for
this part, with a bit of a performance cost). Good old-fashioned data
structure implementation is my favourite thing to do, but unfortunately
there is no shortage of more pragmatic things that need doing ;)

Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
just tearing the required bits out of glib itself. Sqlite has an
in-memory hash table IIRC. Code abounds.

Present a viable alternative, and I'll switch sord/slv2 to it, but I
have no good reason to invest time in reinventing glib right now.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 09:24 PM, Stefano D'Angelo wrote:
> 2011/2/25 Olivier Guilyardi :
 There are a couple of security issues with linking about a third-party .so 
 though.
>>> True.
>>> However, my question about this Android/LV2 possibility is: what for? Any 
>>> ideas?
>> In my case, it's intended to provide effects for my app, TapeMachine:
>> http://tapemachine.samalyse.com/
>>
>> Users are requesting effects.
> 
> The app looks very cool, having LV2 there would be awesome!

Thank you :) Yes it could be very nice.

Cheers

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/25 Olivier Guilyardi :
>>> There are a couple of security issues with linking about a third-party .so 
>>> though.
>>
>> True.
>
>>
>> However, my question about this Android/LV2 possibility is: what for? Any 
>> ideas?
>
> In my case, it's intended to provide effects for my app, TapeMachine:
> http://tapemachine.samalyse.com/
>
> Users are requesting effects.

The app looks very cool, having LV2 there would be awesome!

> Also, I think that Android is quite unique (amongst popular mobile platforms)
> when it comes to providing a high-level of inter-operability between apps, 
> such
> as here in the case of plugins.

Agreed.

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 08:59 PM, Stefano D'Angelo wrote:

>> The thing about Android is that third-party plugins should be rather 
>> feasible.
>> There are simple mechanisms which could easily allow a host to discover which
>> plugins are installed on the system. Such plugins could be distributed as
>> standalone packages (APK) on the Android Market.
> 
> Yes, I don't know the details of those mechanisms, but after seeing
> how Flash is distributed as an APK and integrates into the browser, I
> was thinking something along those lines too.

The keywords are Intent filters, Content Providers, Services. These can be used
for dynamic plugin discovery.

>> There are a couple of security issues with linking about a third-party .so 
>> though.
> 
> True.

> 
> However, my question about this Android/LV2 possibility is: what for? Any 
> ideas?

In my case, it's intended to provide effects for my app, TapeMachine:
http://tapemachine.samalyse.com/

Users are requesting effects.

Also, I think that Android is quite unique (amongst popular mobile platforms)
when it comes to providing a high-level of inter-operability between apps, such
as here in the case of plugins.

And now I need to go, I'm late and a friend of mine is giving a concert.

Cheers,

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/25 Olivier Guilyardi :
> On 02/25/2011 08:57 PM, David Robillard wrote:
>
>>> It's a few months ago now that I investigated LV2. IIRC, at that time I
>>> concluded that this wasn't an option because SLV2 was GPL'ed. But things are
>>> changing IIUC :)
>>
>> You never asked. I would have changed it... but I am not psychic ;)
>
> It's not always easy to discuss about religious matters, such as licenses ;)
>
> That said there is another big problem. This glib dependency, it's way too 
> heavy
> for mobile deployment.

Since this was already discussed and we happen to have possible GLib
replacements, could you expand on that? Why is it too heavy?

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 08:57 PM, David Robillard wrote:

>> It's a few months ago now that I investigated LV2. IIRC, at that time I
>> concluded that this wasn't an option because SLV2 was GPL'ed. But things are
>> changing IIUC :)
> 
> You never asked. I would have changed it... but I am not psychic ;)

It's not always easy to discuss about religious matters, such as licenses ;)

That said there is another big problem. This glib dependency, it's way too heavy
for mobile deployment.

> I am planning on making the next release LGPLv3+
> 
>> The thing about Android is that third-party plugins should be rather 
>> feasible.
>> There are simple mechanisms which could easily allow a host to discover which
>> plugins are installed on the system. Such plugins could be distributed as
>> standalone packages (APK) on the Android Market.
> 
> I have an android device; I havn't done any hacking for it yet (aside
> from making web UIs intended to be usable on such devices), but would
> very much like to see LV2 working there. Mobile is where all the action
> is...

Yes, and tablets opens many perspectives for audio.

--
  Olivier

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/25 Olivier Guilyardi :
> On 02/25/2011 08:15 PM, Stefano D'Angelo wrote:
>> 2011/2/25 Olivier Guilyardi :
>>> On 02/25/2011 08:14 PM, Stefano D'Angelo wrote:
 2011/2/25 Olivier Guilyardi :
> LV2 plugins on mobile devices? Yes, I'm investigating that :)
 Olivier++

 Android or...?
>>> Yep :)
>>
>> Is there something I could take a look at?
>
> Oh, well, I've only done some research so far. I have a closed source Android
> audio app which could act as a plugin host.
>
> It's a few months ago now that I investigated LV2. IIRC, at that time I
> concluded that this wasn't an option because SLV2 was GPL'ed. But things are
> changing IIUC :)

Yep. :-)

> The thing about Android is that third-party plugins should be rather feasible.
> There are simple mechanisms which could easily allow a host to discover which
> plugins are installed on the system. Such plugins could be distributed as
> standalone packages (APK) on the Android Market.

Yes, I don't know the details of those mechanisms, but after seeing
how Flash is distributed as an APK and integrates into the browser, I
was thinking something along those lines too.

> There are a couple of security issues with linking about a third-party .so 
> though.

True.

However, my question about this Android/LV2 possibility is: what for? Any ideas?

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-02-25 at 20:29 +0100, Olivier Guilyardi wrote:
> On 02/25/2011 08:15 PM, Stefano D'Angelo wrote:
> > 2011/2/25 Olivier Guilyardi :
> >> On 02/25/2011 08:14 PM, Stefano D'Angelo wrote:
> >>> 2011/2/25 Olivier Guilyardi :
>  LV2 plugins on mobile devices? Yes, I'm investigating that :)
> >>> Olivier++
> >>>
> >>> Android or...?
> >> Yep :)
> > 
> > Is there something I could take a look at?
> 
> Oh, well, I've only done some research so far. I have a closed source Android
> audio app which could act as a plugin host.
> 
> It's a few months ago now that I investigated LV2. IIRC, at that time I
> concluded that this wasn't an option because SLV2 was GPL'ed. But things are
> changing IIUC :)

You never asked. I would have changed it... but I am not psychic ;)

I am planning on making the next release LGPLv3+

> The thing about Android is that third-party plugins should be rather feasible.
> There are simple mechanisms which could easily allow a host to discover which
> plugins are installed on the system. Such plugins could be distributed as
> standalone packages (APK) on the Android Market.

I have an android device; I havn't done any hacking for it yet (aside
from making web UIs intended to be usable on such devices), but would
very much like to see LV2 working there. Mobile is where all the action
is...

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 08:15 PM, Stefano D'Angelo wrote:
> 2011/2/25 Olivier Guilyardi :
>> On 02/25/2011 08:14 PM, Stefano D'Angelo wrote:
>>> 2011/2/25 Olivier Guilyardi :
 LV2 plugins on mobile devices? Yes, I'm investigating that :)
>>> Olivier++
>>>
>>> Android or...?
>> Yep :)
> 
> Is there something I could take a look at?

Oh, well, I've only done some research so far. I have a closed source Android
audio app which could act as a plugin host.

It's a few months ago now that I investigated LV2. IIRC, at that time I
concluded that this wasn't an option because SLV2 was GPL'ed. But things are
changing IIUC :)

The thing about Android is that third-party plugins should be rather feasible.
There are simple mechanisms which could easily allow a host to discover which
plugins are installed on the system. Such plugins could be distributed as
standalone packages (APK) on the Android Market.

There are a couple of security issues with linking about a third-party .so 
though.

--
  Olivier





___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/25 Olivier Guilyardi :
> On 02/25/2011 08:14 PM, Stefano D'Angelo wrote:
>> 2011/2/25 Olivier Guilyardi :
>>> LV2 plugins on mobile devices? Yes, I'm investigating that :)
>>
>> Olivier++
>>
>> Android or...?
>
> Yep :)

Is there something I could take a look at?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 08:14 PM, Stefano D'Angelo wrote:
> 2011/2/25 Olivier Guilyardi :
>> LV2 plugins on mobile devices? Yes, I'm investigating that :)
> 
> Olivier++
> 
> Android or...?

Yep :)




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/25 Olivier Guilyardi :
> LV2 plugins on mobile devices? Yes, I'm investigating that :)

Olivier++

Android or...?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Olivier Guilyardi]

On 02/25/2011 07:33 PM, David Robillard wrote:

> That said, I can't think of an actual reason why LGPL complicates
> matters...

I am not a lawyer and all that but on mobile devices it can be very complicated
(or impossible) to satisfy the ability-to-relink LGPL requirement.

LV2 plugins on mobile devices? Yes, I'm investigating that :)

--
  Olivier
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Thu, 2011-02-24 at 10:48 +, Chris Cannam wrote:
> On 23 February 2011 23:55, David Robillard  wrote:
> > They're all in my LAD meta-repository:
> 
> Ah, externals.
> 
> LGPL I see -- I've no problem with that in principle, but it would
> complicate matters a bit (both Dataquay and Redland being BSD).

I switched Serd and Sord to 2-clause BSD. Enjoy. The license header is
bigger and uglier and has a bunch of lawyer boiler-plate yelling in it,
which I am not aesthetically please with at all... :)

This made me notice something though: lv2.h itself is LGPL (inherited
from ladspa.h). So, if you're implementing an LV2 host there's
inherently LGPL involved anyway.

I am fully on the pro-GPL card-carrying FSF member team (Affero GPL3 it
all, comrades!), but a decent argument could be made for lv2.h having a
more liberal license, since it just defines an interface which we want
implemented as widely as possible...

That said, I can't think of an actual reason why LGPL complicates
matters...

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Thu, 2011-02-24 at 10:48 +, Chris Cannam wrote:
> On 23 February 2011 23:55, David Robillard  wrote:
> > They're all in my LAD meta-repository:
> 
> Ah, externals.
> 
> LGPL I see -- I've no problem with that in principle, but it would
> complicate matters a bit (both Dataquay and Redland being BSD).

I could perhaps be convinced to make it BSD since it's intended to be as
widely usable as possible... the goal is to provide an enabling
technology to promote Turtle/RDF, not the software itself, so that's
appropriate. I'm making a single-file "amalgamation" ala SQlite as well,
public domain / unlicense like they do might be a good choice too.

> > if you're just interested in Turtle + in-memory model
> 
> That's essentially all I use -- Dataquay does a basic job of wrapping
> SPARQL as well, but a case could be made for that to be optional.

I always wanted a programmatic query interface in Redland... having
actual textual queries that need to be parsed every time is a bit silly
in something like SLV2. Maybe one day I'll try my hand at a (simple than
SPARQL) query engine, but it's a bit hard, and it turns out that doing
triple queries and just iterating over those (possibly nested) actually
makes much more clear code from a C coding perspective. Nested foreach
style loops is much more natural than tabular query results for the type
of code that uses LV2 (not that SPARQL style querying doesn't have it's
uses, of course).

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Chris Cannam]

On 23 February 2011 23:55, David Robillard  wrote:
> They're all in my LAD meta-repository:

Ah, externals.

LGPL I see -- I've no problem with that in principle, but it would
complicate matters a bit (both Dataquay and Redland being BSD).

> if you're just interested in Turtle + in-memory model

That's essentially all I use -- Dataquay does a basic job of wrapping
SPARQL as well, but a case could be made for that to be optional.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-23 at 22:35 +, Chris Cannam wrote:
> On 23 February 2011 22:11, David Robillard  wrote:
> > SLV2 is now based on two new libraries: Serd (RDF syntax) and Sord (RDF
> > store). Both are roughly 2 thousand lines of C, solid and thoroughly
> > tested (about 95% code coverage, like SLV2 itself). Serd has zero
> > dependencies, Sord depends only on Glib (for the time being, possibly
> > not in the future).
> 
> Can you point me at the API or code?  I couldn't see it in a quick
> browse on your SVN server.

They're all in my LAD meta-repository:

http://svn.drobilla.net/lad/trunk/

Or, individually:

http://svn.drobilla.net/lad/trunk/slv2
http://svn.drobilla.net/serd/trunk/
http://svn.drobilla.net/sord/trunk/

All the usual disclaimers about unreleased software apply.

> I have a library (Dataquay,
> http://code.breakfastquay.com/projects/dataquay -- preparing a 1.0
> release of it at the moment, so if anyone wants to try it, go for the
> repository rather than the old releases) which provides a Qt4 wrapper
> for librdf and an object-RDF mapper.
> 
> It's intended for applications whose developers like the idea of RDF
> as an abstract data model and Turtle as a syntax, but are not
> particularly interested in being scalable datastores or engaging in
> the linked data world.

More implementation alternatives for working with that "micro-stack"
would be great, it's a good one...

> For my purposes, Dataquay using librdf is fine -- I can configure it
> so that bloat is not an issue (and hey! I'm using Qt already) and some
> optional extras are welcome.  But I can see the appeal of a more
> limited, lightweight, or at least less configuration-dependent
> back-end.

You can compile a far more lightweight librdf yourself, but, well, users
don't, nor should they have to. That said, sure, it's still a good
option sometimes, but I am shooting for an extremely low barrier of
entry. Small C libraries with no dependencies are an easy sell, because
they're not a pain in anyone's ass.

The sord API is vaguely reminiscent of the specific subset of the librdf
API I needed at the time, but I made it as part of a hyper pragmatic
mission to get a Redland-free SLV2, not a librdf replacement in general.
The API probably still needs a bit of polish. In other words, I'm not
pitching Sord as a viable Redland replacement in general (nor is making
it one a priority), but if you're just interested in Turtle + in-memory
model, it may be. Let me know what you think.

> I've considered doing LV2 as a simple example case for Dataquay, but
> the thought of engaging in more flamewars about LV2 and GUIs is really
> what has put me off so far.  In other words, I like the cut of your
> jib here.

So don't engage in it. Virtually all such nonsense on here is nothing
but the peanut gallery. Mentioning what you plan to do here before doing
it is usually not a good idea (dumbass on mailing list hinders progress,
film at eleven). Don't let L-A-D deter you from working on LV2 things.
If you need useful feedback before proceeding, the LV2 mailing list
 or IRC channel (#lv2 on
irc.freenode.net) are productive, on-topic, flame-free venues for LV2
related discussion/coordination. You can of course also just work
directly with another host/plugin author, which is typical, and is why
most of the LV2 noise here is just that.

Anyway, as for that simple example, a Qt based LV2 host based on a new
RDF stack would be great to see. It's a useful real-world example. I
don't know exactly how a flame against writing that would go, but I do
know it would be painfully stupid, and not worth your attention. Anchors
away!

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Chris Cannam]

On 23 February 2011 22:11, David Robillard  wrote:
> SLV2 is now based on two new libraries: Serd (RDF syntax) and Sord (RDF
> store). Both are roughly 2 thousand lines of C, solid and thoroughly
> tested (about 95% code coverage, like SLV2 itself). Serd has zero
> dependencies, Sord depends only on Glib (for the time being, possibly
> not in the future).

Can you point me at the API or code?  I couldn't see it in a quick
browse on your SVN server.

I have a library (Dataquay,
http://code.breakfastquay.com/projects/dataquay -- preparing a 1.0
release of it at the moment, so if anyone wants to try it, go for the
repository rather than the old releases) which provides a Qt4 wrapper
for librdf and an object-RDF mapper.

It's intended for applications whose developers like the idea of RDF
as an abstract data model and Turtle as a syntax, but are not
particularly interested in being scalable datastores or engaging in
the linked data world.

For my purposes, Dataquay using librdf is fine -- I can configure it
so that bloat is not an issue (and hey! I'm using Qt already) and some
optional extras are welcome.  But I can see the appeal of a more
limited, lightweight, or at least less configuration-dependent
back-end.

I've considered doing LV2 as a simple example case for Dataquay, but
the thought of engaging in more flamewars about LV2 and GUIs is really
what has put me off so far.  In other words, I like the cut of your
jib here.


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev