Re: [LAD] Rubber Band Library v3.0.0 released

[Chris Cannam]

On Thu, 28 Jul 2022, at 20:35, Yuri wrote:
> There are 4 LV2 plugins. Carla loads plugins without "R3" in them.
> But these 2 fail to load: Rubber Band R3 {Mono|Stereo} Pitch Shifter.

Thanks - there is a report of this here 
https://github.com/breakfastquay/rubberband/issues/66 and I'll take a look at 
it soon.

(I'm just catching up on issues and threads today after a few days away)


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

Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released

[Chris Cannam]

On Thu, 28 Jul 2022, at 17:06, Robin Gareus wrote:
> On 7/28/22 15:52, Chris Cannam wrote:
>> 
>> The version in the .pc file is written in at install time,
>
> Except, it isn't. $PREFIX/lib/pkgconfig/rubberband.pc here has Version:
> 1.8.2 for rubberband v3.0.0

Oops. How are you installing? If I use e.g. "meson build && ninja -C build && 
ninja -C build install" here I get a copy that does have the right version in 
it. I haven't looked too closely at how it does that though. Since it appears 
to work equally well with %VERSION% in the .in file, and it's obviously not 
great to have a wrong literal value in there, I'll make that change.

>> The ABI has been at 2.something since version 1.2, 
>
> Yeah that's fine. I was just surprised to see the age being zero.
>
> http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

That page just makes my head spin a little faster if anything! It seems rather 
libtool-specific and doesn't indicate how current:revision:age maps on to the 
installed library suffix. Is "current" the soname number, "revision" the minor 
number, and "age" the point number, as I would naively read it?

If so, then it appears to be saying that merely adding a function *should* 
result in incrementing the soname:

"If any interfaces have been added, removed, or changed since the last update, 
increment current, and set revision to 0"

where "current" is the soname, right?

As I read it, it seems to be saying that if the current version is (say) 2.1.7, 
then a backward-compatible addition should result in an updated version 3.0.8 
whereas an incompatible change should result in 3.0.0. I'm not sure I 
understand the logic regardless of the explanation in the page. I don't recall 
having ever read quite that method before.


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

Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released

[Chris Cannam]

On Thu, 28 Jul 2022, at 15:26, Fons Adriaensen wrote:
> In this case you didn't just add a function, but a completely new and
> improved algorithm. That's reason enough to increment the major version,
> even if only for 'marketing'. And more so if you also offer a commercial
> license.

I guess you're right (and thank you also for the kind words earlier on this 
list by the way!)

It hadn't really occurred to me to think of the soname as marketing, but an 
increment does indicate novelty to humans as well as the machine. I am perhaps 
too invested in backward compatibility as the arbiter for this.


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

[LAD] library soname, was Re: Rubber Band Library v3.0.0 released

[Chris Cannam]

On Fri, 15 Jul 2022, at 23:02, Robin Gareus wrote:
> Congrats on the release and thanks for the very informative blog post.

Thank you!

> https://hg.sr.ht/~breakfastquay/rubberband/browse/rubberband.pc.in?rev=v3.0.0
>
> states Version: 1.8.2 (not 3.0.0).
> The ABI version of the shared object is 2.2.0
>
> Is that expected?

Yes to both... I hope.

The version in the .pc file is written in at install time, although I guess it 
would be nice to have the right version in place in .pc.in in the first place 
(or to omit it until installation) as it does look kind of confusing.

The ABI has been at 2.something since version 1.2, which was the last release 
to break binary compatibility. This release bumped it from 2.1.7 to 2.2.0. A 
program dynamically linked against version 1.2 will still run correctly against 
this new version.

But I find that after all these years I am still not totally clear on whether a 
*compatible* change to the ABI should cause a change to the soname, or only to 
the minor number. I thought I knew this, but I find now that sources contradict 
each other, and sometimes themselves, with great confidence - and it's been 
such a long time that I can no longer remember exactly why I formed my own view 
in the first place.

For example:

https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

section 3.1.1 "The soname has the prefix ``lib'', the name of the library, the 
phrase ``.so'', followed by a period and a version number that is incremented 
whenever the interface changes". This implies that if you e.g. add a function, 
you should change the soname.

section 3.6 "When a new version of a library is binary-incompatible with the 
old one the soname needs to change... you can keep your Application Binary 
Interface (ABI) compatible if you avoid such changes. For example, you might 
want to add new functions but not delete the old ones". This implies that if 
you add a function, you need not change the soname.

I always took the view that if the library can be upgraded without breaking an 
application linked against the old version, it should have the same soname 
(i.e. first component of ABI version) because the alternative would be too 
annoying in practice. That seems consistent with many other libraries, anyway. 
But it does mean that library downgrades don't fail cleanly and I am definitely 
finding sources out there that suggest it isn't the right thing to do after 
all. Has consensus on this changed over the years perhaps?


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

Re: [LAD] Rubber Band Library v3.0.0 released

[Chris Cannam]

On Fri, 15 Jul 2022, at 18:33, Will Godfrey wrote:
> When you say higher CPU cost, can you give a rough estimate as to how much?

About 3x.

> Is it possible to have both versions compiled, and for a host to switch 
> between
> them at runtime?

Yes, that's the way it's designed. The library can run either engine. You pick 
one when you construct the stretcher object, and the rest of the API and the 
way you use it are identical.

In principle to switch an application from one to the other is simply a matter 
of adding "| OptionEngineFiner" to the end of the options list when the 
existing code constructs its stretcher. (I say "in principle" because you would 
want to test it thoroughly and check that it is actually doing what you expect!)

It is also usually a good idea to call the new function getEngineVersion() 
after construction to check you have the engine you expected, because that 
guarantees you don't accidentally get linked against an old library version 
that doesn't support the new engine.

See also this post which has more background 
https://thebreakfastpost.com/2022/07/13/rubber-band-library-a-thrilling-new-release/


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

[LAD] Rubber Band Library v3.0.0 released

[Chris Cannam]

Version 3.0.0 of Rubber Band Library is now available.

https://breakfastquay.com/rubberband/

Rubber Band Library is an audio time-stretching and pitch-shifting library and 
utility designed for musical applications. It allows you to change the tempo 
and pitch of an audio recording independently of one another.

This is an exciting major release which, among other things, introduces an 
entirely new processing engine known as the R3 or Finer engine. This typically 
produces substantially higher-quality output than the existing engine (now 
referred to as R2 or Faster), although at higher CPU cost. The more 
energy-efficient R2 is still the default, and R3 can be selected using the new 
OptionEngineFiner option on construction.

I'm immensely proud of the work done for this release, and hope it will delight 
you and all the users of your software.


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

Re: [LAD] Programming LV2 plugin from scratch tutorial video series

[Chris Cannam]

On Tue, 19 Oct 2021, at 10:00, Chris Cannam wrote:
> For example, I could have chosen to write [...]

naturally I notice a typo just after sending - forgot to capitalise the P of 
lv2:Plugin in my second version. Sorry. The capital initial in "type" URIs is 
also just a convention, btw.


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

Re: [LAD] Programming LV2 plugin from scratch tutorial video series

[Chris Cannam]

On Mon, 18 Oct 2021, at 21:54, Fons Adriaensen wrote:
> Which raises the question why those @prefix lines are 
> required at all. [...]
> So all that these lines seem to provide is some illusion
> of conformity which isn't enforced or checked at all. 

I used to find this conceptually tricky as well. I think it's true that there 
is an illusion of conformance there. The @prefix lines have an official look to 
them that doesn't reflect the reality, which is simpler than it appears.

RDF itself is a structure of triples, in which each element (subject, 
predicate, object) can be a URI (a string with some limitations as to character 
content) or, in certain positions, other types such as literal character data. 
RDF doesn't have prefixes itself, they're a sort of macro expansion used in the 
Turtle format, which is intended to be written and read at least partially by 
humans.

On loading the Turtle document

@prefix lv2:  .
@prefix my:  .
my:plugin a lv2:Plugin .

what the RDF store actually receives is a single triple of three URIs, which in 
the more basic ntriples format would look like

 
 
 .

The two prefixed names are expanded, as well as the standard shorthand "a". But 
you didn't *have* to use the prefixes, you could have written exactly the line 
above (which is valid Turtle as well as ntriples). It's just that it's harder 
to write the document correctly that way. All that matters is that the second 
and third URIs (predicate and object) expand to exactly the strings shown, and 
that the first URI (the subject) is used consistently as the subject for all 
properties of your plugin.

So the above document is equivalent to any other Turtle document that expands 
to the same set of RDF triples. For example, I could have chosen to write

@prefix plu:  .
@prefix rdf:  .
 rdf:type plu:gin .

Run this through a Turtle-to-ntriples converter (e.g. rapper -i turtle) and 
you'll get the same output as before:

 
 
 .

And, of course, URIs are just strings - the fact that they are typically 
written with http at the start etc is just a namespacing convention. The lv2 
standard could have used  instead of 
 and it would still work.


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

Re: [LAD] Multiple JACK servers connected in one host?

[Chris Cannam]

On Fri, Mar 11, 2016, at 07:13 PM, Fons Adriaensen wrote:
> A client that generates a very uneven load (e.g.
> doing big FFTs every Nth cycle) can easily make it indicate
> much more than the average CPU load. Of course clients doing
> that are just badly implemented, but they do exist.

Badly implemented? For a convolver perhaps, but I think (as I would)
that it's perfectly fair to implement some methods that way. A phase
vocoder at a short period size will exhibit exactly that behaviour.


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

Re: [LAD] Spectral envelope code

[Chris Cannam]

On Tue, Aug 18, 2015, at 08:42 PM, Gerald Mwangi wrote:
 Is the license compatible with the GPL in the
 sense that I could embed the envelope class/functions in my own code?

Yes, it is.


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

Re: [LAD] Spectral envelope code

[Chris Cannam]

Yep, this Simple Cepstrum plugin can do this, to some approximation --

https://code.soundsoftware.ac.uk/projects/vamp-simple-cepstrum

The code is BSD/MIT licensed, though I realise I've forgotten to put in
a separate licence file (I should go back and do that, maybe even build
some binaries as well). The licence is stated in the source headers
though.


Chris

On Fri, Aug 14, 2015, at 07:39 PM, Alex Norman wrote:
 maybe something from this?
 
 http://vamp-plugins.org/download.html?platform=linux64
 
 On  0, Gerald Mwangi gerald.mwa...@gmx.de wrote:
  Hi Can anyone point me out to code that extracts the spectral envelope
  of a signal. Due to my tight time constraints I can't dig much into the
  topic to develope such an extractor, so somewhat working C/C++ code is
  appreciable.
  Thanks Gerald
  ___
  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
 Email had 1 attachment:
 + signature.asc
   1k (application/pgp-signature)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Vamp plugin SDK v2.6 now available

[Chris Cannam]

Version 2.6 of the Vamp plugin SDK is now available.

   http://www.vamp-plugins.org/

Vamp is a plugin API for audio analysis and feature extraction plugins
written in C or C++.  Its SDK features an easy-to-use set of C++ classes
for plugin and host developers, a reference host implementation, example
plugins, and documentation.  It is supported across Linux, OS/X, and
Windows.

A documentation guide to writing plugins using the Vamp SDK can be found
at http://www.vamp-plugins.org/guide.pdf.

Version 2.6 is a bugfix and minor enhancement release. For more details,
see the changelog at

http://code.soundsoftware.ac.uk/projects/vamp-plugin-sdk/repository/entry/CHANGELOG


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

Re: [LAD] GuitarSynth

[Chris Cannam]

On Tue, Apr 28, 2015, at 04:10 PM, Gerald wrote:
 [...] dividing the FFT'd input signal by the envelope

This LADSPA plugin

https://code.soundsoftware.ac.uk/projects/preprocess

will do a crude job of that, if you want to try it out. It uses a
cepstral envelope estimator.


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

Re: [LAD] GuitarSynth

[Chris Cannam]

On Tue, Apr 28, 2015, at 05:12 PM, Gerald wrote:
 By 'crude' do you mean it does the job, but not that well?

What I really mean is that it wasn't written for use in a specific
application, so it hasn't had any real testing or evaluation. The
purpose of it is to be a handy tool that you can use to figure out
whether this sort of transformation makes a difference to your feature
extractor, rather than necessarily to be the final implementation you'd
actually put in the extractor.


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

[LAD] Constant-Q library and Vamp plugin

[Chris Cannam]

Announcing a new C++ library and Vamp plugin implementing the Constant-Q
transform of a time-domain signal.

https://code.soundsoftware.ac.uk/projects/constant-q-cpp

The Constant-Q transform is a time-to-frequency-domain transform related
to the short-time Fourier transform, but with output bins spaced
logarithmically in frequency, rather than linearly. The output bins are
therefore linearly spaced in terms of musical pitch. The Constant-Q is
useful as a preliminary transform in various other methods such as note
transcription and key estimation techniques.

This library provides:

 * Forward transform: time-domain to complex Constant-Q bins
 * Forward spectrogram: time-domain to interpolated Constant-Q magnitude
 spectrogram
 * Inverse transform: complex Constant-Q bins to time domain

The Vamp plugin provides:

 * Constant-Q magnitude spectrogram with high and low frequency extents
 defined in Hz
 * Constant-Q magnitude spectrogram with high and low frequency extents
 defined as MIDI pitch values
 * Pitch chromagram obtained by folding a Constant-Q spectrogram around
 into a single-octave range

The code is provided with full source under a liberal licence, and
plugin binaries are provided for Windows, OS/X, and Linux.

The method is drawn from Christian Schörkhuber and Anssi Klapuri,
Constant-Q transform toolbox for music processing, SMC 2010. See the
file CITATION for details. If you use this code in research work, please
cite this paper.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] building the new Guitarix LV2 Amp

[Chris Cannam]

On 11 December 2012 16:31, David Robillard d...@drobilla.net wrote:
 Looks like you are building against a static library. Since you are building
 a shared module, pedantically you can't do this

A static library is just a pile of object files. Of course you can
build a shared object against them. The problem is just that the
objects in this particular static library were built without PIC.


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

Re: [LAD] meterbridge 0.9.2 IEC-scale bug fix

[Chris Cannam]

[This went rather in one ear and out the other when you posted it (if
that's possible for email) but I did eventually realise I'd seen it.]

On 11 June 2012 18:47, Robin Gareus ro...@gareus.org wrote:
 Anyway, some of you who package or copied code from meterbridge may be
 interested in this as well.
 [...]
 //   def = (db + 60.0f) * 0.5f + 5.0f;  //  5.0  ..  10.0 // bug? v0.9.2
  def = (db + 60.0f) * 0.5f + 2.5f;  //  2.5  ..   7.5 // fix!

You're quite right -- I just double-checked the standard and your fix
is the right one. I have cargo-culted this code into a couple of other
places myself without ever seeing this mistake, so I'll have to fix
those.

Thanks for spotting this.


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

Re: [LAD] meterbridge 0.9.2 IEC-scale bug fix

[Chris Cannam]

On 26 September 2012 16:39, Fons Adriaensen f...@linuxaudio.org wrote:
 There is more to fix.

 The meterbridge website still claims that those meters 'almost' conform
 to some standards while in fact they even don't come close.

I'm not sure whether you're addressing me, but I have nothing to do
with meterbridge. My interest was limited to the IEC 268-18 extension
curve. Which I apparently should have done due diligence on.

Not sure whether Steve would be applying patches? If he isn't placed
to update it, it might be a better idea to tell people to use
something else (jmeters? with a link?) than to spend too much time on
specific issues with meterbridge. Especially if they've been described
before and if there is no way to get a fix through to anyone who picks
up the program from the obvious location or through a search.


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

Re: [LAD] a *simple* ring buffer, comments pls?

[Chris Cannam]

On 12 July 2011 13:44, Dan Muresan danm...@gmail.com wrote:
 I wonder if

 {
 pthread_mutex_t dummy = PTHREAD_MUTEX_INITIALIZER;
 pthread_mutex_lock(dummy);
 pthread_mutex_unlock(dummy);
 }

 doesn't provide a portable full memory barrier.

According to 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
the answer must surely be yes -- pthread_mutex_lock provides a memory
barrier and the only (explicit) exception is for recursive mutexes
already held by the caller.

 Oh, and you probably need a barrier in the consummer too

Yes, before updating the read index (I said read index earlier when I
meant write index).

Thinking it over and going back over some references and earlier
threads here (e.g. much earlier ones from Olivier et al) it does seem
that this should be enough.  This particular situation isn't so
complicated after all.  I think the more I read earlier during this
thread (and reading around) generally about memory ordering, the more
I was beginning to feel as if the entire subject was a source of only
trouble.


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

Re: [LAD] a *simple* ring buffer, comments pls?

[Chris Cannam]

On 12 July 2011 21:20, Olivier Guilyardi l...@samalyse.com wrote:
 Quite interestingly, I have noticed that discussions about memory barriers are
 often somehow endless. [...] So I thought, maybe there's a hidden topic
 behind that. A memory barrier...

Indeed -- perhaps these discussions need some sort of memory write
barrier, ensuring that everything discussed before the barrier will be
recalled from store subsequently, instead of being discussed anew.
But this list would be awfully quiet if we had such a thing.


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

Re: [LAD] a *simple* ring buffer, comments pls?

[Chris Cannam]

On 12 July 2011 21:36, Paul Davis p...@linuxaudiosystems.com wrote:
   2) do you need memory barriers to ensure correct synchronization
         for this kind of data structure in the face of possible hardware level
         instruction reordering?

The transactional metaphor for this kind of thing seems useful -- the
idea that we've written everything, now we commit for our readers
feels like a helpful way to picture the points where barriers might be
necessary.

Since transactional integrity is not provided for us, the commit needs
to be either

 * protected with a memory barrier, if it doesn't matter that the data
is available before it has been announced but does matter if the data
is announced before being available
 * an atomic swap, if the new data must not be available before it has
been announced and also there is only a single point of reference to
the new data
 * mutex protected, if the references to any changes may be
significant or we are not confident of either of the previous cases

...?


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

Re: [LAD] a *simple* ring buffer, comments pls?

[Chris Cannam]

On 12 July 2011 22:32, Olivier Guilyardi l...@samalyse.com wrote:
 Thing is, of every single thing that has been said on this thread about memory
 barriers and ringbuffers, no one can prove anything. On this thread, on 
 others,
 on LAD and elsewhere. For example, no one can write a test case which fails 
 when
 memory barriers are missing in a ringbuffer implementation.

There is one in the iPad 2 example Sean posted a link to earlier in the thread:

http://wanderingcoder.net/2011/04/01/arm-memory-ordering/

I haven't tried it, lacking an iPad 2 or any other multicore ARM computer.


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

Re: [LAD] a *simple* ring buffer, comments pls?

[Chris Cannam]

On 11 July 2011 21:32, James Morris jwm.art@gmail.com wrote:
 I've ended up going back to Fons's pragmatism. If
 non-blocking/lock-free programming is so impossibly difficult,
 requiring intimate hardware knowledge of numerous different
 architectures then there's only one solution available to people like
 me, and that's to code for AMD64/Intel and use the existing ringbuffer
 implementations.

Perhaps the pragmatic solution is to _lock_ the shared buffer?

I'm not at all sound on this subject, but I wouldn't be surprised if
Dan was right that memory ordering guarantees on the read/write index
variables might still leave the data that is just copied into the
buffer exposed to cache coherency problems.

I know taking locks in a RT process is deeply frowned upon around
here, but a critical section juts across the code used to update the
buffer and read back from it -- with an accompanying guarantee of
actually getting the right data out again -- might not be such a bad
tradeoff these days as we'd be inclined to think?


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

Re: [LAD] a *simple* ring buffer, comments pls?

[Chris Cannam]

On 11 July 2011 21:50, Chris Cannam can...@all-day-breakfast.com wrote:
 [...] a critical section juts across the code

just across


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

Re: [LAD] [ann] CAPS 0.4.5

[Chris Cannam]

On 18 April 2011 15:50, David Robillard d...@drobilla.net wrote:
 On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote:
 Library name plus label, for example.

 That is not guaranteed to be unique, and I know of at least one case in
 practise where it isn't (various blop packages have a different library
 name).  There's no reason whatsoever the library name and label of
 various LADSPA plugin distributions can't be completely different,
 neither one is an ID.

Indeed, but at least the typical failure case (when the library name
differs from the expected one) is that the plugin isn't loaded and the
program can report it, rather than that the wrong plugin is loaded
silently as occurs with the numerical ID.

 Perhaps the LADSPA spec /should/ use that (or whatever else) as an
 identifier, but it doesn't.

As Stefano pointed out, it does in fact say plugin types should be
identified by file and label.  I admit the text is strange given the
presence of the ID as well.

 file name + label would be a really annoying two-piece identifier
 anyway, even if it was an actual global identifer.

So make a pseudo URI or something out of it.

Anyway, the situation is a bit unsatisfactory either way and I don't
think we disagree on that -- probably not much point in arguing about
the details these days.  A proper URI is a better option in any
circumstance.


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

Re: [LAD] [ann] CAPS 0.4.5

[Chris Cannam]

On 17 April 2011 18:12, David Robillard d...@drobilla.net wrote:
 On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote:
 I like to disagree with David on most things LADSPA -- for example I
 think a host that uses the unique ID at all is broken from the
 outset

 Well, that's just silly... it's the only ID there is. What else would
 they use?

Library name plus label, for example.  My hosts do that and have done
for years.  Not ideal either of course, but at least it doesn't
completely stuff up any situation where a numerical ID can't be
generated in advance (dssi-vst, etc).


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

Re: [LAD] [ann] CAPS 0.4.5

[Chris Cannam]

On 13 April 2011 22:03, Tim E. Real termt...@rogers.com wrote:
 I agree that if this new port were to be sandwiched among the others
  or if he were removing ports, that's breakage.

I think that was the plan, though -- to put the new port after the
other control ports and before any of the existing audio ones.  And
that's the problem.

I like to disagree with David on most things LADSPA -- for example I
think a host that uses the unique ID at all is broken from the
outset, because there's no way to ensure that ID is actually unique,
e.g. for plugin wrappers.  But in this case, and even though my own
hosts should cope with Tim's change without problems, I have to agree
that the change is not a good idea.


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

[Chris Cannam]

On 25 Feb 2011 18:34, David Robillard d...@drobilla.net 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

[Chris Cannam]

On 23 February 2011 23:55, David Robillard d...@drobilla.net 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

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

[Chris Cannam]

On 23 February 2011 22:11, David Robillard d...@drobilla.net 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

Re: [LAD] Calculate R M S (Alfs Kurmis)

[Chris Cannam]

On 18 February 2011 21:19, Folderol folde...@ukfsn.org wrote:
 Remembering my early training... In quality moving coil test meters this was
 referred to as critical damping and not only gave the best response time but
 also gave confidence that the meter needle wasn't sticking.

There's a really good user-interface insight in there -- the same one
as exploited in touch-scrolling on certain famous handheld devices,
the sort where scrolling bounces when you reach the end...


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

Re: [LAD] Advice sought on project hosting and version control

[Chris Cannam]

On 12 February 2011 23:02, torbenh torb...@gmx.de wrote:
 after i have gotten used to the index of git. i am pretty much annoyed
 by vcs that dont have a feature like that.
 most mercurial users seem to find gits index rather annoying.

I certainly found Mercurial a relief after git -- with which (in my
rather brief experience) I found myself making too many stupid
mistakes and losing my thread too often.


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

Re: [LAD] OpenOctaveMidi2 (OOM2) beta release

[Chris Cannam]

On 27 January 2011 16:37, Christopher Cherrett ccherr...@openoctave.org wrote:
 OK, it was muse2.

Did you ever consider, for example, _not_ assigning yourselves the
copyright in the program's About box?

This is exactly what happened with Rosegarden for OOM1 -- fork the
project, provide a new theme, new keybindings and some new features,
change all identifying names, remove our copyrights, and put up a
promotional page about it with no reference to Rosegarden.  In that
instance the credits reappeared after I objected, and I was prepared
to give them the benefit of the doubt.

Perhaps the MusE team are more relaxed about attribution than I am, or
perhaps they decided they'd prefer not to be identified with the
forked software at all.  I don't know.

(No, it is not legal to take someone else's GPL software and identify
yourself as the copyright holder.)


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

Re: [LAD] [LAU] OpenOctaveMidi2 (OOM2) beta release

[Chris Cannam]

On 27 January 2011 19:38, Christopher Cherrett ccherr...@openoctave.org wrote:
 I suspect there is much more to this puzzle than attribution.

No, really not.  Attribution is incredibly important to many open
source developers, partly because there are so few tangible benefits
involved with open source work, and partly because the force of the
licenses we use (particularly the GPL) depends on being confident
about the ownership of copyright.  It matters a great deal to people
if you take someone's work and represent it as your own.

And it's a pity, because a situation like this or the earlier
Rosegarden fork ought to be beneficial to everybody.  With Rosegarden,
your project's focus was different from that of any of our core
developers and, although we like to keep people happy, we really
weren't able to spend the time to do the things you wanted.  Forking
ensured that people who liked things your way had somewhere else to
go, which made things better for them and simpler for us.

In light of that, it's a great shame that the resulting new project
should then give us such a sour impression -- and the same thing is
true again here.  Your casual attitude to other people's work means
that I and probably many others would avoid working with you again,
but that negative feeling could have been avoided with such a tiny
amount of thought and even less work.


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

Re: [LAD] What do you do for a living?

[Chris Cannam]

On Thu, Nov 11, 2010 at 7:40 PM, Gordon JC Pearce gordon...@gjcp.net wrote:
 Fuck Google.  I've already switched back to Altavista, and submitted
 bugs against Firefox and derivatives and Google Chrome suggesting that
 they either use Yahoo!, Altavista or Bing as their default search.

I like Google because they annoy Gordon, and that means more
entertainment for us.


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

Re: [LAD] What do you do for a living?

[Chris Cannam]

On Fri, Nov 12, 2010 at 10:50 AM, Patrick Shirkey
pshir...@boosthardware.com wrote:
 On Fri, November 12, 2010 1:55 am, Chris Cannam wrote:

 I like Google because they annoy Gordon, and that means more
 entertainment for us.

 All this anger. I suspect they rejected him at some point.

I would be very surprised to learn he had ever applied there.

I think actually his is the sort of complaint Google should be making
a note of -- it's clearly made up of a number of small irritations
that just happen to cross most of the spectrum of things he might use
their services for.

It's not that everyone else necessarily agrees with him, but that one
person's irritations might be things that grow to be everyone's
irritations over time, and might become things that a competitor can
take advantage of -- just as Google originally took advantage of the
overdeveloped search interfaces everyone else used to provide.

 Me, I've been rejected three times by Google. I'm getting used to it now.

It is perhaps an unbalanced world in which anyone feels they have to
apply more than once to the same employer.

I worked for a while for Yahoo.  That was... not bad.  The day-to-day
wasn't so different, but the ready availability of very clever people
with specialisations in whatever subject you wanted was a very
attractive point.  I know a few people at Google, some of whom moved
from Yahoo, and on the whole they like it there, I think for similar
reasons.

Ten or fifteen years earlier, I might have been writing that the
people I knew at Microsoft felt the same way.  These companies work
quite hard to enchant their developers and please their employees
generally.  Employees are very expensive.

(I don't know anyone at Apple.  Apple is a mystery to me.  I imagine
it's much the same, but I would like to hear any stories about forced
injection of reality-distortion drugs, etc., you might be able to
offer.  Anyone?)

Anyway, for my part -- I work in a university, at the Centre for
Digital Music at Queen Mary, University of London.  I'm unusual in
academia in that I'm employed as a developer rather than an RA or
postdoc (I have neither MSc nor PhD).  It's in a pretty grim part of
London, but it's by far the most interesting job I've ever had and, as
I've been here for over five years now, it's also the longest-standing
job I've had in 17 years of commercial work.  I was hired partly
because of the commercial experience on my CV, but mostly on the basis
of my work on free software projects.


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

Re: [LAD] Paul's Extreme Sound Stretch

[Chris Cannam]

On Thu, Sep 30, 2010 at 8:01 AM, Louigi Verona louigi.ver...@gmail.com wrote:
 1. How does Sound Stretch work?

My (vague) recollection is that it is a phase vocoder in which the
phases are randomised.


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

Re: [LAD] Mouse/knob interaction

[Chris Cannam]

On Tue, Sep 7, 2010 at 7:23 PM, Gabriel M. Beddingfield
gabrb...@gmail.com wrote:
 circle: no.
 up and down: yes.
 scroll wheel: yes.
 left and right: up to you.

Agreed on all counts.  Of course you can make them respond to
horizontal motion as well, without screwing up people who expect
vertical motion, by taking the max of horizontal and vertical
displacement as the displacement to use.

You don't give quite enough information, though -- there is some
discrepancy out there with regard to whether moving the mouse up
should move the rotary towards the start or end of its travel (i.e. up
= anticlockwise, down = clockwise or the reverse).  I had to go and
test some rotary controllers to remind myself which behaviour my hand
expects, and it turns out it's up = clockwise.


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

Re: [LAD] Mouse/knob interaction

[Chris Cannam]

On Tue, Sep 7, 2010 at 8:44 PM, Gordon JC Pearce gordon...@gjcp.net wrote:
 On Tue, 2010-09-07 at 20:24 +0100, Chris Cannam wrote:
 test some rotary controllers to remind myself which behaviour my hand
 expects, and it turns out it's up = clockwise.

 That's a funny thing, because I've been looking at some radio equipment
 with a big rotary knob to scroll through menu options.  Turning the knob
 clockwise moves the pointer up, and turning it anti-clockwise moves it
 down - utterly unintuitive!  Perhaps it's because the scrolly knob is to
 the right of the display, so the edge of the knob that moves up should
 follow the cursor?

It may be that.  I really couldn't work out in my head which direction
ought to be more intuitive -- and I was surprised by that.

In practise I find I clearly prefer mouse up = clockwise, which is the
relation that you just called unintuitive (and I think I would agree
with you -- there's no very good reason to suppose that preference in
mouse movement would be the same as preference in how a vertical
selection responds to rotary control, but it's interesting to find
they actually do differ).  My preference might be just familiarity, or
it might be my vision in the absence of any other cue aligning the
movement of the mouse with that of the left edge of the knob.


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

Re: [LAD] Mouse/knob interaction

[Chris Cannam]

On Tue, Sep 7, 2010 at 9:18 PM,  f...@kokkinizita.net wrote:
 The important thing with rotary controls is that everything
 should be relative.

True, but also true of (computer GUI, rather than real) faders.
Dragging the mouse should give the impression of dragging the control,
rather than clicking the element instantly positioning the control.

 This is similar to the advantage of *real* rotary controls
 vs. linear ones. Try to control a linear fader while you're
 running from a riot police assault during a manifestation.
 Or under attack from a US helicopter mistaking your mic for
 a rocket launcher.

Aside from a certain concern about your longevity if such is your CV,
I think that's a quite different effect -- the cause of that is that
rotary controls have a centre, so that if your hand moves
involuntarily the control won't jump -- you'll just try to push it
into a different place, which will do nothing unless the axle breaks.

Real faders also move in a relative way; you can't instantly move them
to wherever your hand happens to be.  It's just that you can push them
much more quickly with an involuntary motion.  The absolute vs
relative thing I think is entirely a computer phenomenon.


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

Re: [LAD] Attenuation of sounds in 3D space

[Chris Cannam]

On Thu, Jul 22, 2010 at 12:48 PM, Paul Davis p...@linuxaudiosystems.com wrote:
 you don't ned anything fancy to listen to B-format
 recordings, and one of the major reasons for that is fons' open source
 decoder that will allow you to listen to them with any jack-enabled
 audio player and your existing equipment.

Question that just occurred to me.  I'm very ignorant about spatial
audio, and although I'm sure several of my colleagues could tell me
this, I thought it might be sort of on-topic here.  Is it possible, or
easy, or sensible, or worthwhile, to reduce a B-format recording into
stereo in multiple different ways in order to achieve different
subjective listener position results when using headphones?


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

Re: [LAD] [Fwd: Re: No nagging, a serious question]

[Chris Cannam]

On Mon, Jul 5, 2010 at 4:16 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 IIRC, you can set the clock source on an ALSA sequence queue to be the
 clock based on a PCM device.

You can, but I'm pretty sure last time I tested it (admittedly five or
six years ago) I found that the resulting clock was quantized to the
PCM device buffer length.


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

Re: [LAD] GPL and plugins

[Chris Cannam]

On Tue, Jun 22, 2010 at 3:10 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 i think, in fact, i ADAMANTLY
 believe that run-time linking of an object module as a result of
 explicit user action (i.e. not part of the predestined lifetime of the
 process) is semantically distinct from dynamic linking. put another
 way, if you cannot look at the executable and determine that it will
 link a particular object module during its lifetime, it is very, very
 hard for me to see how the plugin can be considered a derivative work
 of the host (assuming the APIs are not host specific etc etc etc).

Exactly my view as well.


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

Re: [LAD] GPL and plugins

[Chris Cannam]

On Tue, Jun 22, 2010 at 9:24 AM, Victor Lazzarini
victor.lazzar...@nuim.ie wrote:
 Then there is the situation where you write a plugin using VST (and its
 non-free license) and GPL. GPL should 'contaminate' the plugin making it
 Free, but then Steinberg will come back at you for breaking its license.
 Surely if you use GPL code, then you need to publish your header files too.

 Sorry, I did not mean to make this discussion longer than it needs to be,
 but...

I think that situation is simpler, and is just as you surmise -- you
can't redistribute a plugin that claims to be under the GPL if it uses
the VST SDK headers.

There _are_ some VST plugins out there that use the SDK but claim to
be under the GPL, and I think that is really borne of frustration with
the current impossibility of doing it properly because of the
restrictive license for the SDK headers (most painfully, the SDK
license's reverse-engineering clause effectively forbids publishing
source for a plugin that _doesn't_ use the SDK, if you have already
accepted the SDK license).

So I expect the view is that, so long as nobody with a stake in the
software objects to it, then at least the license has described what
the plugin's author would like to happen in an ideal world. It's a
grey-market situation. You wouldn't be able to include such a plugin
in a typical Linux distribution.


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

Re: [LAD] GPL and plugins

[Chris Cannam]

On Mon, Jun 21, 2010 at 12:13 PM, Victor Lazzarini
victor.lazzar...@nuim.ie wrote:
 A simple question: can GPL plugins be loaded into non-free hosts?

First off -- you can _do_ anything you like with a GPL plugin, the
question is whether you could legally redistribute it.  Beyond that, I
don't think there is a single answer to this -- I think in practice it
would depend on whether the one thing (plugin or host) would be seen
by the reasonable person to be a derivative work of the other.  If the
plugin only worked with a single host, or the plugin was necessary in
order to use the host, then it might be.  If it used a well-defined
API supported by multiple hosts, perhaps predating either of the host
or plugin in question, then it probably wouldn't.

As a concrete example I think a GPL VST plugin would be perfectly
fine, provided of course that it used none of Steinberg's SDK code.
There are GPL'd VST hosts out there, so clearly the plugin does not
depend on a non-free host and can be happily distributed under the
GPL.  What you choose to do with it once you've received it is up to
you -- the GPL only covers distribution -- so yes, I would think you
could indeed make, distribute, and use such a plugin.


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

Re: [LAD] GPL and plugins

[Chris Cannam]

On Mon, Jun 21, 2010 at 7:22 PM, Victor Lazzarini
victor.lazzar...@nuim.ie wrote:
 I think this is the closest to the scenario I am envisaging. There is a
 host, which is non-Free and commercial, currently using a non-Free plugin,
 which is packaged with it. This non-Free plugin gets substituted by a Free
 plugin, which is free because, amongst other things, it links to a GPL
 dynamic library. Is this breaking the original GPL license of the dynamic
 lib the plugin links to?

That doesn't seem like enough information for anyone to attempt an answer.

What do you mean by gets substituted by?  Do the distributors of the
application swap in the GPL plugin, or does the user who received it?
If the latter, how?  Was the GPL plugin written specifically to
replace the proprietary one?  Can it be used in other hosts?

My inclination is that the answer to your question is probably no,
this wouldn't violate the licence.  But the fact that you're asking at
all makes me wonder whether this is a situation in which the plugin
has been designed specifically to interact with a single proprietary
application, or a situation in which the host is distributed with a
plugin that is treated differently from others.  If that's so, then
it's possible a court might think that the plugin containing API code
was a derivative work of the host that implemented the API.

I'm not aware of any case in which this has actually been tested either way.


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

Re: [LAD] GPL and plugins

[Chris Cannam]

On Mon, Jun 21, 2010 at 9:12 PM, Victor Lazzarini
victor.lazzar...@nuim.ie wrote:
 The plugin is just a Free software plugin, that is GPL, distributed in
 binary form and source code etc. It is written as a plugin, so it can be
 used by any host of the same API. The host will load this plugin instead of
 the proprietary non-free plugin that it replaces. The plugin is made
 available separately, but is also bundled with the host, which loads it
 automatically.

I would be uneasy about that last bit -- the fact that the host treats
this plugin differently from others.  I think we're deep within a
genuine grey area here (an area that is both completely untested and
in which people's opinions differ) but I could well imagine an
argument being made on the basis of the interdependence of plugin and
host.

 My reasons for asking this are that I was asked to write such a plugin and
 i) I don't normally do proprietary software; ii) I don't like to reinvent
 the wheel. If I can't provide a free solution, I may as well not take the
 job.

If I were in this position, I think I would not feel comfortable
providing a GPL plugin.

That's probably about all I can say though, and one person's
ill-supported opinion probably isn't of much use.


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

[LAD] [job advert] Software Developer: Audio and Digital Music

[Chris Cannam]

[forwarding here, hope this is not too off topic or unwelcome]

==

 Software Developer:  Audio and Digital Music

   Centre for Digital Music

   Queen Mary, University of London
 School of Electronic Engineering and Computer Science


The Centre for Digital Music (C4DM) at Queen Mary, University of
London, is seeking an experienced Software Developer with a background
and knowledge in Audio and Digital Music, to work on a new
EPSRC-funded project Sustainable Software for Digital Music  and
Audio Research. The aim of this project is to provide a Service to
support the development and use of software, data and metadata to
enable high quality research in the Audio and Digital Music research
community.

The postholder will undertake a range of software development
activities in this project, including: developing cross-platform
robust engineered software from research prototype software; tailoring
or adapting existing research software to make it usable by other
researchers; creating and maintaining software and data repositories;
providing documentation, training and advice on the use of developed
software; and engagement and outreach to the research community and
beyond.

The C4DM, part of the School of Electronic Engineering and Computer
Science, is a world-leading multidisciplinary research group in the
field of Digital Music  Audio Technology. C4DM already develops
robust software and technologies for music and audio research,
including Sonic Visualiser (SV), a popular open source cross-platform
framework for analysis of music and audio. Details about the School
can be found at www.eecs.qmul.ac.uk and about the Centre for Digital
Music at www.elec.qmul.ac.uk/digitalmusic

The post is full time and for 40 months (starting in July 2010 or as
soon as possible thereafter). Starting salary will be in the range
£27,913 - £33,659 per annum inclusive of London Allowance. Benefits
include 30 days annual leave, final salary pension scheme and
interest-free season ticket loan.

Candidates must be able to demonstrate their eligibility to work in
the UK in accordance with the Immigration, Asylum and Nationality Act
2006. Where required this may include entry clearance or continued
leave to remain under the Points Based Immigration Scheme.

Informal enquiries should be addressed to the Principal Investigator,
Prof Mark Plumbley at mark.plumb...@elec.qmul.ac.uk

Further details and an application form can be found at:
www.hr.qmul.ac.uk/vacancies
(http://webapps.qmul.ac.uk/hr/vacancies/jobs.php?id=1815)

To apply for the Software Developer position, please email the
following documents to Ms Julie Macdonald at
applicati...@eecs.qmul.ac.uk: Completed application form quoting
10212/CE; a CV listing any publications and a statement describing
your previous software development experience, outlining the relevance
to this project.  Postal applications should be sent to Ms Julie
Macdonald, School of EECS, Queen Mary University of London, Mile End
Road, London, E1 4NS

The closing date for applications is 12 noon on 25 June 2010.
Interviews are expected to be held on 7 July 2010.

If you have not heard from us by 12 July 2010 then you should assume
that you have not been shortlisted on this occasion.

Valuing Diversity  Committed to Equality
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] mailing-list problems - was: axonlib (last one)

[Chris Cannam]

On Tue, Jun 8, 2010 at 7:21 PM, ccernn cern.th.s...@gmail.com wrote:
 hmmm, i have a reply, and a reply-to-all, but no reply-to-list

Reply-to-all will work, then.

Some people get cross if you reply-to-all to one of their list
messages, because that means they may get two copies of your reply --
one to them directly and one via the list.  That does depend on their
mailer or mail server though, because the two have identical message
IDs and so can be handled correctly if their client is up to it.  (I'm
using reply-to-all now, so you'll soon find out if your client copes.
If you're using gmail, I think it will, and you will get only a single
copy of this.)

So: reply-to-list is better if you have it, but if you don't, use reply-to-all.


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

Re: [LAD] mailing-list problems - was: axonlib (last one)

[Chris Cannam]

On Tue, Jun 8, 2010 at 8:55 PM, Robin Gareus ro...@gareus.org wrote:
 On 06/08/2010 09:07 PM, Chris Cannam wrote:
 So: reply-to-list is better if you have it, but if you don't, use 
 reply-to-all.

 mmh better in what way?

better in that I have seen complaints from people here before about
getting duplicate copies from reply-to-all.  Using reply-to-list
presumably avoids that.

I wouldn't really know, I don't have reply-to-list either and don't
greatly care.  Thought it might cut down some potential objections
though.


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

Re: [LAD] A little quiz about audio measurements...

[Chris Cannam]

On Fri, May 28, 2010 at 1:31 PM,  f...@kokkinizita.net wrote:
 This week I had to perform measurements on a audio
 interface, and this resulted in some quite interesting
 results. Before revealing what happened, I'll let you
 have a look at some of the data and come up with your
 own conclusions, see

 http://www.kokkinizita.net/linuxaudio/quiz.html

Why 1015 Hz?


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

Re: [LAD] Music, Undecidability, and the tiling problem (was Re: update: OT-ish: realtime 2d placement algorithms :-/)

[Chris Cannam]

On Tue, May 25, 2010 at 9:07 PM, Folderol folde...@ukfsn.org wrote:
 On Tue, 25 May 2010 12:31:57 -0700
 Niels Mayer nielsma...@gmail.com wrote:
 Mathematics is fundamental to music -- everything from the
 relationship of notes to frequency, to what people consider musical,
 or rhythmic... has to do with math, group theory, etc.

 This is putting the cart before the horse. People were making music
 long before there was any remotest concept of mathematics. Many of us
 still work on the basis of just noodling about and 'ooo, that sounds
 nice' without the slightest thought of relationships etc.

I think the point Neils has is just that the outcome of your noodling
is somewhat independent of your explicit intention.  Notes that sound
satisfying together are probably going to sound satisfying largely
because of some intrinsic mathematical relationship, or at least
something that is probably open to analysis to some extent but that
you don't yourself understand or plan.  Quite an interesting
philosophical avenue here, and one that's fairly well trodden in other
fields (ask an English theory student about Wimsatt and Beardsley).

As an angle for compositional software, this suggests that if you can
begin to model what actually happens, you may be able to help to
short-circuit your limited understanding of your own work.  The
problem with that (as I think Paul was saying?) is that as long as the
model can be comprehended, the departures from it will continue to be
more interesting than the model itself.

Excuse me, I've probably had a glass of interesting Croatian red too many.


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Mon, May 24, 2010 at 3:03 AM, Joshua D. Boyd jdb...@jdboyd.net wrote:
 I think it isn't difficult to read because it is C++ or Boost.  It is
 difficult to read because it involves concepts like promises and futures,
 which are advanced topics that a lot of people (myself included) aren't
 adequately familiar with (at least not without referring to a cheat sheet).

That is a fair point.  And it's not unreasonable to expect people to
pick up idioms like that for concurrent programming -- it's not as if
there is a broad language of equally effective alternative concepts in
wide use.


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Mon, May 24, 2010 at 8:58 AM, torbenh torb...@gmx.de wrote:
 well... for me, saying c++, is saying boost. boost and modern c++ is what
 makes c++ better than java.
 java is a pretty great language nowadays (with generics and annotators
 and stuff). my big problem with java is that its stdlib is really a big mess.

I always thought the big chunk of new stuff added in Java 1.5 was a
really bad idea.  That took a compact, comprehensible language that
lacked a number of convenient features but at least had a single
school of practice, and gave it the capacity for the same sort of
fragmentation as you have in C++.  But I haven't done Java development
in earnest since that stuff became widespread, so I don't know whether
that's really happened in practice.

Reading a language is (for most projects) more important than writing
it.  You yourself took the jackdmp code (in C++) and ported it back to
good old C because it was written from the wrong school of C++ and
you found C easier to work with.  Jackdmp is not exactly weird code --
it's written rather like pre-1.5 Java -- but its C++ is just not the
same C++ as you use.  Similarly, for someone like me who has used Qt
for many years, Boost has always seemed largely superfluous and the
language that for you is C++ is for me something a little bit alien.
 Is it possible to write C++ in such a way that every competent C++
developer is happy to work with the results without some sort of
re-education?


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Mon, May 24, 2010 at 2:05 PM, torbenh torb...@gmx.de wrote:
 dunno. but wikipedia calls this particular style modern c++
 http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design

Ah, I see.  A neat trick, to give a still relatively esoteric idiom
such a progressive name.  One can hardly say oh no, I don't like to
write modern C++, can one?


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Sun, May 23, 2010 at 9:41 AM, torbenh torb...@gmx.de wrote:
 but i find the equivalen c++ easier to read.
 assuming we have a proper modern c++ osc lib:

 boost::unique_futureOscMsg
 osc_recv (OscPeer peer, std::string path)
 {
        boost::shared_ptr boost::promiseOscMsg  spromise( new 
 boost::promiseOscMsg )
        peer.add_handler( path, [=]( OscMsg msg )
        {
 [...]

Is this C++0xthingy?

I have to say this combination of Boost plus Weird Stuff From The
Future is no more readable to me (as a long-time C++ programmer) than
the Clojure example.  It looks neat, but I'm pretty sure it's
accessible to you only because it's what you've spent the time with
recently.

I worry about that all the time with my own code -- the more care I
take to use the language well, the less likely anyone else is to be
able to work with it.


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Sat, May 22, 2010 at 11:59 PM, Niels Mayer nielsma...@gmail.com wrote:
 results so far... using a combination of
 vamp-plugins, groovyapache-velocityjavascriptflash via xwiki java-based
 platform http://nielsmayer.com/ts-episode-timeline.png   http://nielsmayer.com/ts-episode-evnt-anls.png

You sent me email about this, which I shamefully never replied to (my
excuses include having been on holiday at the time, getting lots of
email generally, being a bit useless etc etc).  It is quite impressive
to look at.

Have you seen SAWA from Gyorgy Fazekas?  Another interesting
Vamp-based thingumijig.
http://www.isophonics.net/content/sonic-annotator-web-application


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Fri, May 21, 2010 at 7:42 PM, Niels Mayer nielsma...@gmail.com wrote:
 Actually, my thoughts during the faust presentation @LAC2010 indicates we
 seem to inhabit different islands each with it's own cargo-cult...

 (07:59:14 AM) npm: Q: what's the difference or motivation for this Block
 diagram algebra and lambda calculus and y-combinators??

 (07:59:58 AM) herman_mixer: Someone in the audience who can relay from
 IRC?

 (08:01:38 AM) npm: well i guess that answers the q

I don't understand.  What answers the question?

Actually I'm not sure I understand the question either -- do you mean
to ask why the block diagram algebra (which I guess was something from
the presentation?) is being talked about when the lambda calculus
already existed?


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Fri, May 21, 2010 at 10:52 AM, Olivier Guilyardi l...@samalyse.com wrote:
 On 05/20/2010 10:12 PM, Chris Cannam wrote:
 Being a long time Vim user is probably _why_ you found it to be so efficient 
 ...

 ... now if you were an Emacs user, that'd be another matter ...

 Well, intellisense in QtCreator is really nice, especially when you learn Qt.

Sorry, I was just being silly.  I agree with you, Qt Creator is the
first IDE a new Qt developer should look at.


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Thu, May 20, 2010 at 6:26 PM, Gabriel M. Beddingfield
gabrb...@gmail.com wrote:
 On Thu, 20 May 2010, Charles Fleche wrote:

 well (e.g. if you write LV2 plugins based on Qt, as I have, you may
 uncover some strange bugs).

 Really ? What happened ?

 When I released the Composite Sampler, I had to solve two tricky bugs:

Hang on -- I've never actually looked at Composite (sorry!) but does
this mean that it has a Qt GUI that loads in-process in GTK-based LV2
hosts?

And besides the odd hiccup, that works OK?


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

Re: [LAD] Looking for an introduction to rt programming with a gui

[Chris Cannam]

On Thu, May 20, 2010 at 5:30 PM, Olivier Guilyardi l...@samalyse.com wrote:
 Qt is really great. I also highly recommend that you look at Qt Creator which 
 is
 included in the SDK. Although I'm a long time Vim user, I really found this 
 IDE
 to be extremely simple and efficient.

Being a long time Vim user is probably _why_ you found it to be so efficient ...

... now if you were an Emacs user, that'd be another matter ...

Anyway, aside from Qt (which I also use and endorse) it might be worth
looking at JUCE (http://www.rawmaterialsoftware.com/juce.php) and NUI
(http://www.libnui.net/).  I've never tried either myself but JUCE is
quite widely used for audio applications, including by some Linux
developers.  Never really heard anything first-hand about NUI, but it
has a natty website at least.


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

[LAD] Rubber Band Library v1.5.0 now available

[Chris Cannam]

Rubber Band Library v1.5.0 is now available.

  http://breakfastquay.com/rubberband/

This release adds a key-frame mapping facility for managing variable
stretch ratios within a single offline time-stretch pass, plus a more
reliable transient detection mode for soft instruments and
band-limited transient detectors to improve performance with
compressed or lower-quality material.  It is source and binary
backward compatible with v1.4, though code written for v1.5.0 may not
work with v1.4 (the new release adds one new function and one new
enum).


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

Re: [LAD] General question: Components of Music Software

[Chris Cannam]

On Tue, Apr 27, 2010 at 10:21 AM, Jeremy jer...@autostatic.com wrote:
 On 04/27/2010 10:34 AM, rosea.grammostola wrote:
 aubiocut

 That's a MIDI slicer, but doesn't do beat analysing.

No, it's a beat slicer, nothing to do with MIDI.

Maybe the confusion arises from an incorrect summary in the man page
on the aubio website -- the first line at
http://aubio.org/aubiocut.html appears to have been cut and pasted
from the man page for aubionotes.  (cc'ing the author)


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

Re: [LAD] automation on Linux

[Chris Cannam]

On Wed, Mar 17, 2010 at 8:59 PM, rosea grammostola
rosea.grammost...@gmail.com wrote:
 *Rosegarden *could work, but apart from being bloated, it is also
 rather complicated to add automation:
 Draw event
 Open in Martrix editor
 Then under View I can add a controller, but for some reason only a
 select few.

The controllers available are those listed in the device mapping for
your track.  You can add any you like to the device mapping, or load a
preset device mapping -- 140 or so of them are bundled, including one
with all controllers in it by number rather than name.

The control editor ruler in the matrix of the current Qt4-based
Rosegarden is rather nicer than the one in 1.7.x -- thanks to Chris
Fryer for lots of work on that.

It is still rather unwieldy to have to go through the matrix editor at
all, sometimes, and there is no automation at all for internal
parameters like plugin or audio mixer settings (except by setting up
MIDI controllers and playing them back in to Rosegarden's external
controller input, but that's a real hack).


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

Re: [LAD] Integrate LASH into Jack

[Chris Cannam]

On Fri, Mar 5, 2010 at 11:51 AM, Arnold Krille arn...@arnoldarts.de wrote:
 LASH is dead. Session-handling in jack is the future. Thats why there is
 currently a big discussion going on about using jacks own ipc for the session
 handling of clients.
 You might want to read the archives of the last days of this list and the jack
 developers list...

Does any substantive Linux audio development discussion actually
happen on LAD any more?

I've only just discovered (because of your email and another pointer
to the list from LAU) that any of this session management stuff was
being discussed on jack-devel.

I don't think I've ever been subscribed to that list, at least since
it moved from SourceForge -- after all, I'm not a JACK developer.  But
I am interested in session management.  I've just subscribed to it,
and it looks like I have rather a lot to catch up on.

Hm.


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

Re: [LAD] Integrate LASH into Jack

[Chris Cannam]

On Fri, Mar 5, 2010 at 1:43 PM, Gabriel M. Beddingfield
gabrb...@gmail.com wrote:
 I've only just discovered (because of your email and another pointer
 to the list from LAU) that any of this session management stuff was
 being discussed on jack-devel.

 Well, when you're talking about changes to the JACK API, that discussion
 belongs on Jack-Devel, doesn't it?

Yes.  But the subject really is session management for Linux audio
applications.  The fact that JACK is involved is (waves hand
dismissively in manner of a Paris waiter) an implementation detail.

 The JACK site[1] says, If you're doing anything with jack, you need to be
 on this list.

True enough.  Though I've been doing things with JACK for many years
without ever having read that page before.  And -devel lists are
usually for developers of whatever it is they're about, not users of
it.

Anyway -- really I'm just cross about missing things through my own
inertia.  I suspect the real reason I'm not on that list is that I
never got around to moving my subscription there, having previously
been subscribed to the now defunct jackit-de...@lists.sourceforge.net.
 This is the first time I've really been aware that the new list was
any more active than the old!


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

Re: [LAD] tschack ... early version of smp enabled jack1

[Chris Cannam]

On Wed, Jan 27, 2010 at 6:41 PM, torbenh torb...@gmx.de wrote:
 i am not sure, but there a several users which report xruns with jack2,
 where jack1 still works.

Interesting.  At Fervent back in the day we switched from jack to
jackdmp (i.e. jack2) as the default server in our long-defunct Studio
to Go distro some three or four years ago, and at the time our tests
suggested its performance was pretty similar to jack1.  Since jackdmp
of course already had the features you're talking about (SMP
capability and clickless connection), it seemed like an obvious thing
to do.  I used to wonder why anyone still used jack1.

Of course now I use a stock distro with stock packages, and I
generally use jack1 myself because it's what's packaged.  I excuse
myself by arguing that it's wise to test with what other users have
got...


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

[LAD] [OT] jack2 on solaris, was Re: tschack ... early version of smp enabled jack1

[Chris Cannam]

Stéphane -- sorry to veer so wildly off-topic... but jackdmp is
expected to work on Solaris, right?  Is it actively tested?  Is it
expected to build with Sun compilers, or only with gcc?

I switched a machine from Linux to OpenSolaris a few months back and
at the time failed to get jackdmp working on it, but I didn't give it
much time because it wasn't all that important then.  I'd like to
revisit it though, and wondered what I should reasonably expect.


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

Re: [LAD] [OT] jack2 on solaris, was Re: tschack ... early version of smp enabled jack1

[Chris Cannam]

On Wed, Jan 27, 2010 at 9:10 PM, Stéphane Letz l...@grame.fr wrote:
 - jack_oss.o one ( so jack -S -R -d oss blab blah...) a one thread driver, 
 initially developed for RTL and tested on a MADI card

 - later on I switched to a more general (and probably more exact) 2 threads 
 model. It got called boomer' (Boomer is the SUN derived from OSS  audio 
 API..). So jack -S -R -d boomer blab blah

 Both should work on OpenSolaris with 4 Front OSS.  I never tried with Boomer 
 since my internal card was not supported at that time

OK.  I do have Boomer (using OpenSolaris dev repositories, currently
build snv_131)... but do I gather from the above that I don't
necessarily have to use the Boomer back-end?  so if I have trouble
with it, I ought to be able to get away with the old-fashioned OSS
one?

(Sound generally does work on the machine, including OSS4 software mixing.)


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

Re: [LAD] tschack ... early version of smp enabled jack1

[Chris Cannam]

On Sun, Jan 24, 2010 at 9:05 PM, torbenh torb...@gmx.de wrote:
 since i dont want to let jack1 codebase die in a feature freeze,
 i added some features.

 - smp aware
 - clickless connections

Is there any reason why a user would prefer this over jack2?


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

Re: [LAD] [LAU] Help on rubberband

[Chris Cannam]

On Wed, Jan 13, 2010 at 6:40 PM, gerald mwangi gerald.mwa...@gmx.de wrote:
 Hi, has someone looked at the code? I really need an answer to the question.

Sorry, I didn't notice this earlier on LAD because the subject line
(Is TerminatorX development stalled?) bore no relationship to the
substance of the query.  No slight to TerminatorX intended, but I
wouldn't normally look at messages on LAD about it!

 I have a question to for the devs out there though: It seems to me that i
 have to run process() a few times with a fixed blocksize before,
 getRequiredSamples() returns something 0 in Realtime-mode. All other
 options are default options. Is this true?

You have to supply process() with a certain amount of data before
anything becomes available at output, yes.  If you are using a small
fixed block size, then yes it is true that you will likely have to
call process() several times.  You might like to consider querying
getLatency() first, after setting the initial ratios, and priming
the stretcher with that number of zeroed samples before you start.


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

Re: [LAD] Session Handlers and 'level 1' support

[Chris Cannam]

On Fri, Jan 8, 2010 at 10:36 AM, Nedko Arnaudov ne...@arnaudov.name wrote:
 Currently an app cannot do it at software level. The level 1 support
 just needs to be documented.

What I mean is: if the user starts an application that has no
knowledge of LADI at all, and they check the level 1 box in ladish, is
that application then guaranteed to crash on session save and lose
their data because of an unhandled signal?

Or will ladish (and/or LADI) only attempt to notify via signal those
applications that have registered with LADI in some way?  (i.e. level
1 means aware of LADI but that's as far as it goes)


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

Re: [LAD] Session Handlers and 'level 1' support

[Chris Cannam]

On Fri, Jan 8, 2010 at 11:18 AM, Nedko Arnaudov ne...@arnaudov.name wrote:
 Chris Cannam can...@all-day-breakfast.com writes:
 That sounds rather hazardous to me.  To lose all of one's data instead
 of saving it, after a potentially long session's work, because of a
 check box incorrectly checked when starting the session, surely
 wouldn't please many users?

 Please take a look at the video. You are wrong. The radio button is
 selected when app is started for first time, not when session is
 started.

*boggle*

OK... That sounds rather hazardous to me.  To lose all of one's data
instead of saving it, after a potentially long session's work, because
of a check box incorrectly checked when starting the application,
surely wouldn't please many users?


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

Re: [LAD] Session Handlers and 'level 1' support

[Chris Cannam]

On Fri, Jan 8, 2010 at 11:50 AM, Nedko Arnaudov ne...@arnaudov.name wrote:
 Chris Cannam can...@all-day-breakfast.com writes:
 OK... That sounds rather hazardous to me.  To lose all of one's data
 instead of saving it, after a potentially long session's work, because
 of a check box incorrectly checked when starting the application,
 surely wouldn't please many users?

 And you are suggesting what?

Uh, I think you've lost me a bit, Nedko.  What do I appear to be suggesting?

I'm just saying that it might not be such a good idea for a session
manager to kill applications instead of saving them, when asked to
save.  Especially if that decision is based on user input that
happened a long time ago (so that the user may have done a lot of work
since making their mistake, but before discovering it was a mistake).

Since none of my applications have any support for any sort of session
manager yet, it's hardly surprising that I might be interested in
thinking about how they might behave if someone tried to use them with
one.


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

Re: [LAD] Session Handlers and 'level 1' support

[Chris Cannam]

On Fri, Jan 8, 2010 at 12:06 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
 What better alternative you propose?

Well, I don't want to be a wet blanket, and please understand I'm
absolutely not trying to start a fight -- but my instinct is to say
just don't do that. Sending an arbitrary signal to an application
that isn't expecting it doesn't seem like a great idea, and using a
signal for session save seems like a nasty hack already (apart from
anything else it's inviting people to attempt the actual save from the
signal handler).

The procedural difficulty I suppose is that you're trying to get
applications to take part in session management without having to get
their authors to change them significantly to do so.  I can see why
that's attractive, but the SIGUSR1 method is still a code change -- it
still needs acceptance from developers, a new release of the
application, c.  Meanwhile, it makes things risky for people who want
to continue using applications that don't support it.

For my part (and I realise I'm probably inviting the wrath of Fons and
others here) I'd probably rather add some D-BUS or equivalent proper
message receipt to the application and be done with it. So long as
boilerplate code is readily available, that doesn't seem too painful.

The problem I have always had with most of the proposed LA session
handlers is not so much doing the code as getting around to doing
the code, which basically means understanding what the code was
supposed to be in the first place -- and I suspect this problem is
commonplace, particularly for something like LASH which has always
seemed strangely demanding from the code point of view.

But, I have never tried using ladish and frankly the time taken to
write this message is probably about as much as I can afford at the
moment.  If I don't properly understand its goals, I'm probably just
covering ground that you've already covered and reaching conclusions
you've already rejected, and I apologise for that.

(One idle thought is that any proper desktop application is going to
have to handle session save already, for the desktop session manager.
Can that be exploited?)


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

Re: [LAD] Session Handlers and 'level 1' support

[Chris Cannam]

On Fri, Jan 8, 2010 at 1:36 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
 Yes the goal is to have simple to implement state save message that
 does not require additional libraries.

Well, I suppose as long as users are made aware that enabling it for
applications they aren't absolutely sure support it is a dangerous
thing to do.  I don't like it, I think it's a simplification too far,
but then I'm not one of the people using it.

 Maybe you can watch the video, it is less than 5 minutes long.

I did actually watch that, when it was announced.

 Desktop session handler traditionally relies on X11. The trend in
 freedesktop (KDE, GNOME) is to use D-Bus as IPC instead. I'm not aware
 of D-Bus desktop session manager.

GNOME is starting to use one.  gnome-session switched to it in GNOME
2.24, completely breaking backward compatible session management
during that release series for lots of users, including me.  Badly
done, but not intrinsically technically wrong.

 In future, ladish aims to save/restore window
 properties like window position, virtual desktop and screen
 (multimonitor).

That does sound like a desktop session manager to me.


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

Re: [LAD] Session Handlers and 'level 1' support

[Chris Cannam]

On Fri, Jan 8, 2010 at 2:06 PM, Gabriel M. Beddingfield
gabrb...@gmail.com wrote:
 On Fri, 8 Jan 2010, Chris Cannam wrote:

 This is far too weak -- it _cannot_ safely be done from a signal handler.

 Why not?

A signal handler can be called at any time, so can't safely interact
with its environment (even with the heap) in any meaningful way.

e.g. C99:

If the signal occurs other than as the result of calling the abort or
raise function, the
behavior is undefined if the signal handler refers to any object with
static storage duration
other than by assigning a value to an object declared as volatile
sig_atomic_t, or
the signal handler calls any function in the standard library other
than the abort
function, the _Exit function, or the signal function with the first
argument equal to
the signal number corresponding to the signal that caused the
invocation of the handler.

So the only thing you're allowed to do, besides exit, is assign to a
global volatile sig_atomic_t variable and return.

Realistically you may be able to get away with more than that, but
saving a document is definitely out.


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

Re: [LAD] LADI

[Chris Cannam]

On Sun, Dec 20, 2009 at 11:18 PM, torbenh torb...@gmx.de wrote:
 anyways... effort is frozen.
 we are dumping a working implementation.

Can you summarise why, for people like me who haven't read any of the
interim discussion?

Thanks...


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

Re: [LAD] LADI

[Chris Cannam]

On Tue, Nov 24, 2009 at 7:46 PM, Paul Davis p...@linuxaudiosystems.com wrote:
 On Tue, Nov 24, 2009 at 2:24 PM,  f...@kokkinizita.net wrote:
 The problem I pointed out exists when the 'real' loop (in
 the C, C++ sense), in other words the while() thing above,
 is completely absorbed into a GUI toolkit.

 you can view it that way around if you wish. but i think that its
 equally accurate to say that things start with a particular event loop
 (in the C, C++ sense) and then the toolkit is built around it.

At the event loop level, neither GTK nor Qt is a GUI toolkit.  That
is, GTK's event loop is found in glib rather than GTK itself; Qt's
event loop (whether native or using glib) is also below the GUI
toolkit level, available for use by event-driven applications that
neither use X11 nor link against any of Qt's GUI code.


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

Re: [LAD] Just an information for the coders of Rosegarden and Open Octave

[Chris Cannam]

On Mon, Nov 9, 2009 at 3:40 PM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote:
 Emanuel Rumpf wrote:
 Opening the hr-timer with rosegarden freezes my whole system here,
 what could cause that ?

 I guess Open Octave is based on Rosegarden. While Qtractor is fine with
 HR timer on my system, Open Octave freezes my system too. I only was
 able to push reset, resp. I didn't try magic keys.

If using the timer locks the system, then it's a kernel problem.

I believe that's why Emanuel was asking here in the first place --
he'd already discussed it on rosegarden-devel, but got nowhere.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 6:41 AM, Jeff McClintock j...@synthedit.com wrote:
 GMPI is quietly and successfully in use as the new native plugin format of
 SynthEdit.

Interesting.  Can you link to an API reference or the like?


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 4:09 PM, David Robillard d...@drobilla.net wrote:
 Qt can now use the glib main loop.

Not just can, it does by default since Qt 4.4.  I think the
intention was exactly to allow cross-toolkit plugins.  So it's quite
likely there is a way to make this work, though obviously not with the
existing GTK UI extension.  Wish I had time to look into this myself,
but I haven't.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 6:59 PM, David Robillard d...@drobilla.net wrote:
 On Sun, 2009-11-08 at 17:46 +, Chris Cannam wrote:
 likely there is a way to make this work

 Yay

 , though obviously not with the
 existing GTK UI extension.

 Why not?

Because it passes a GTK window, doesn't it?  (Doesn't it?)  Which has
no meaning anywhere except GTK.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
 Chris Cannam can...@all-day-breakfast.com writes:
 Because it passes a GTK window, doesn't it?  (Doesn't it?)  Which has
 no meaning anywhere except GTK.

 It passes GTK *widget*.

Right, OK, same thing though from this point of view.  GTK anything.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 7:25 PM, David Robillard d...@drobilla.net wrote:
 On Sun, 2009-11-08 at 19:19 +, Chris Cannam wrote:
 On Sun, Nov 8, 2009 at 7:18 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
  Chris Cannam can...@all-day-breakfast.com writes:
  Because it passes a GTK window, doesn't it?  (Doesn't it?)  Which has
  no meaning anywhere except GTK.
 
  It passes GTK *widget*.

 Right, OK, same thing though from this point of view.  GTK anything.

 How can one possible embed a Gtk widget without... having a Gtk
 widget? :)

Uh, with an X window or whatever.  GTK and Qt are both X toolkits
after all.  In any case, it doesn't have to be embeddable to be useful
-- it only has to be in-process (even if in a separate window) to be
better than the DSSI alternative.

 Again, to be sure this is clear, there is no Gtk UI extension.  The UI
 extension can return a UI of any type (as a void pointer), Gtk just
 happens to be one of them.

But it's only of any use at all if the host and plugin know what the
void pointer points to.  Presumably the extension provides a way to
communicate that; otherwise, it either really is a GTK UI extension
(because there are GTK plugins that use it already, so all hosts must
assume the unknown void pointer is a GTK widget pointer), or else it's
just a very fancy segmentation fault extension.

Anyway, even if you can write plugins using any toolkit and run them
in a host that uses any toolkit, I posit that a UI extension in which
the UIs only appear if the plugin and host happen to be using the same
toolkit is not a very useful one.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 7:43 PM, Chris Cannam
can...@all-day-breakfast.com wrote:
 Uh, with an X window or whatever. [...]

 Again, to be sure this is clear, there is no Gtk UI extension.  The UI
 extension can return a UI of any type (as a void pointer), Gtk just
 happens to be one of them.

 But it's only of any use at all if the host and plugin know what the
 void pointer points to.  Presumably the extension provides a way to
 communicate that; otherwise, it either really is a GTK UI extension

... but of course you're right that if it allows any pointer to be
passed (provided it's possible to say what it is), then the same
extension should be usable for passing the X window or whatever it
is you have.  Though that still complicates the social problem of how
to know what extensions are needed or supported, if some extensions
only work some of the time.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 7:24 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
 IMHO, the two basic questions that user will have are:

 1. Will the plugin X that I use a lot work on host Y that I want to try?
 2. Will the host W that I use a lot work well with the plugin Z I've found?

Hm, I think you may have the wrong tense.  I think the one basic
question that users will have is: Why doesn't this plugin work?

It's a LV2 plugin, this is an LV2 host.  Why doesn't it appear in the
menu?  Or, if it appears in the menu, why does it appear there but not
actually work at all?  Or, why doesn't it look cool like it does in
the screenshots on the plugin's website, or like it does in
other-host-Y?

In other words, how can we convey the answers to questions like these
to users who haven't actually bothered to read any documentation
beforehand?  (i.e. all users)  And how do we do that without being
really annoying about it (e.g. having half the plugins in the menu pop
up an error dialog when you try to select them)?


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 8:28 PM, David Robillard d...@drobilla.net wrote:
 On Sun, 2009-11-08 at 20:23 +, Chris Cannam wrote:
 Hm, I think you may have the wrong tense.  I think the one basic
 question that users will have is: Why doesn't this plugin work?

 This is a problem that hosts (can, and) should express to the user in
 clear terms.

Yes, that's what I meant.  I was fishing for ideas for how a host
might do this without being a complete pain in the arse for the user.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis p...@linuxaudiosystems.com wrote:
  [X] This plugin was discovered but can't be used without hacking this
 host and recompiling because its uses an extension that isn't
 currently supported.

 That kind of PITA? :)

That kind of PITA, for every new plugin that is installed, but perhaps
the bigger problem is what to do about optional extensions.  The
plugin may run without them, but for all you know, it may run in a way
that is not really satisfactory for most real users of it.  Warn them
at install time and they'll certainly have forgotten by the time the
plugin actually gets used, or at least will be unable to recognise the
symptom.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

On Sun, Nov 8, 2009 at 8:53 PM, Chris Cannam
can...@all-day-breakfast.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis p...@linuxaudiosystems.com wrote:
  [X] This plugin was discovered but can't be used without hacking this
 host and recompiling because its uses an extension that isn't
 currently supported.

 That kind of PITA? :)

 That kind of PITA, for every new plugin that is installed, but perhaps
 the bigger problem is what to do about optional extensions.  The
 plugin may run without them, but for all you know, it may run in a way
 that is not really satisfactory for most real users of it.  Warn them
 at install time and they'll certainly have forgotten by the time the
 plugin actually gets used, or at least will be unable to recognise the
 symptom.

Also -- are you, like me, bored with LADSPA plugins crashing your host
in tedious, obvious ways?  How about an LV2 plugin that expects a
particular extension but doesn't really need it so marks it as
optional, then turns out not to have been tested without it -- and,
wouldn't you know, every host except yours happens to support that
extension?  Wouldn't you love to be the first host to run the untested
code path in production?

(I freely admit that this is a sort of FUD, but it happens to be a FUD
that is playing on my own mind at the moment.  Reassure me.)


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

[LAD] dynmanifest, was Re: List of LV2 hosts, plugins and features, add yours here

[Chris Cannam]

On Sun, Nov 8, 2009 at 8:57 PM, Stefano D'Angelo zanga.m...@gmail.com wrote:
 2009/11/8 Nedko Arnaudov ne...@arnaudov.name:
  * Dynmanifest support in version 5 (and maybe even for latest git) is
   for an old version of dynmanifest.

 Git version is for the current version ;-)

What is dynmanifest?  I can't see it in the wiki.

(changing subject line to avoid polluting thread)


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

Re: [LAD] dynmanifest, was Re: List of LV2 hosts, plugins and features, add yours here

[Chris Cannam]

On Sun, Nov 8, 2009 at 9:03 PM, Nedko Arnaudov ne...@arnaudov.name wrote:
 Chris Cannam can...@all-day-breakfast.com writes:
 On Sun, Nov 8, 2009 at 8:57 PM, Stefano D'Angelo zanga.m...@gmail.com 
 wrote:
 2009/11/8 Nedko Arnaudov ne...@arnaudov.name:
  * Dynmanifest support in version 5 (and maybe even for latest git) is
   for an old version of dynmanifest.

 Git version is for the current version ;-)

 What is dynmanifest?  I can't see it in the wiki.

 (changing subject line to avoid polluting thread)

 http://lv2plug.in/ns/dev/dyn-manifest.lv2/dyn-manifest.html

 (first hit in google)

I see.  I understand from this that it's a dynamic manifest generator.

What is a dynamic manifest generator?


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

Re: [LAD] timers

[Chris Cannam]

On Sun, Nov 8, 2009 at 2:46 PM, Ray Rashif schivmeis...@gmail.com wrote:
 2009/11/8 Adrian Knoth a...@drcomp.erfurt.thur.de
 [...]
 [0] http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat

 Holy shit, wait, is that one a demonstration of a useless use of reply in
 e-mail? Good one!

It's certainly a candidate for weirdest irrelevant flame interjected
into an otherwise reasonable thread.

 On a serious note, someone has got to enforce a way to stop topics like these 
 from being posted to LAD.

No, this is fine for LAD.  Emanuel is a developer and he had a
question that's relevant to developers.  The thread digressed a bit,
but in a gentle enough way, and we all know how to ignore a thread if
we don't want to read it.

This is not such a high-traffic list, at least when you weed out the
stupid flames.


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

Re: [LAD] How to develop guis for LV2?

[Chris Cannam]

2009/11/7 Jörn Nettingsmeier netti...@folkwang-hochschule.de:
 This was a hangover from LADSPA, which had confusing and contradictory
 claims about what should/shouldn't be used to identify ports.

 I still don't think there's consensus there.

 can you elaborate on this?

 archive links would be good, too.

I think Steve may be thinking of the inflammatory subject of how you
identify plugins, not ports.  I'm pretty sure LADSPA ports are always
by number.


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

[LAD] Vamp plugin SDK v2.1 released

[Chris Cannam]

Version 2.1 of the Vamp plugin SDK is now available.

  http://www.vamp-plugins.org/

Vamp is a plugin API for audio analysis and feature extraction plugins written
in C or C++.  Its SDK features an easy-to-use set of C++ classes for plugin
and host developers, a reference host implementation, example plugins, and
documentation.  It is supported across Linux, OS/X, Windows, and Solaris.

A documentation guide to writing plugins using the Vamp SDK can be found at
http://www.vamp-plugins.org/guide.pdf.

Version 2.1 is a maintenance release which contains a number of bug fixes
and a new set of skeleton source code files for use by plugin developers.
All of the fixes are relevant to host code only: there is no need to recompile
or re-link any plugins that have been linked with 2.0 against the new release.


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

[LAD] Sonic Annotator v0.4 released

[Chris Cannam]

Sonic Annotator is a utility program for batch feature extraction from
audio files.  It runs Vamp audio analysis plugins with specified
parameters on audio files, and writes the result features in a
selection of formats, in particular as RDF using the Audio Features
and Event ontologies, or as simple CSV files.

Version 0.4 is now available.

For more details and for downloads, please see

 http://www.omras2.org/SonicAnnotator

Sonic Annotator was developed at the Centre for Digital Music, Queen
Mary, University of London.  It was funded by the EPSRC through the
OMRAS2 project and is Free Software published under the GNU General
Public License.


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

[LAD] Rubber Band library v1.4 released

[Chris Cannam]

Rubber Band is an audio time-stretching and pitch-shifting library and
utility designed for musical applications. It allows you to change the
tempo and pitch of an audio recording independently of one another.

  http://breakfastquay.com/rubberband/

This maintenance release contains a fix for a hang when faced with
some very peculiar stretch factors, and a fix for some incorrect
threading condition usage.


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

Re: [LAD] is this a compiler issue??

[Chris Cannam]

On Wed, Aug 19, 2009 at 4:42 PM, Conrad
Berhörsterconrad.berhoers...@gmx.de wrote:
 Additionally i have read some things about denormals and SSE. It seems, that
 the Problem only obtain on the AMD processor

My impression was that Intel CPUs slow down more than AMDs for
denormal handling. But my experience is quite limited, my memory is
not always the best, and I haven't had an AMD for a few years. Am I
wrong?


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

Re: [LAD] GTK+ vs QT for new Open Source Project.

[Chris Cannam]

On Fri, Aug 14, 2009 at 2:36 PM, Ray Rashifschivmeis...@gmail.com wrote:
 How about Juce? =p http://www.rawmaterialsoftware.com/juce/

Or NUI: http://www.libnui.net/

... I've never tried this, would be interested in impressions from
anyone who has.


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

Re: [LAD] GTK+ vs QT for new Open Source Project.

[Chris Cannam]

On Thu, Aug 13, 2009 at 8:29 PM, David Robillardd...@drobilla.net wrote:
 Gtkmm is quite nice for the more C++ minded.  Much nicer standard C++
 style than the cracked out preprocessed pseudo-C++ insanity that is Qt,
 at any rate.

As Pedro says, Qt just contains a code generator; you still end up
with C++.  I don't think the differences between Qt and libsigc++
signal/slot mechanisms are all that much to be worried about --
libsigc++ gets you purer C++ but Qt involves less typing,
particularly of those pesky angle brackets.  They both work.  Good
material for endless pub arguments, but not worth getting in a froth
about when you're actually coding.

(I generally use Qt, and I would say that Qt4 is a very fine library
in general. Not much wrong with GTKmm either though.)


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