Saw this announced on the Linux Musicians site, thought it may be of
interest to some folks here. (Sorry if it's a repost).
https://www.coursera.org/course/audio
Instructors are professors Xavier Serra and Julius O. Smith III, two
very well-known DSP worthies.
Course syllabus :
Week 1: Introduction; basic mathematics
Week 2: Discrete Fourier transform
Week 3: Fourier transform properties
Week 4: Short-time Fourier transform
Week 5: Sinusoidal model
Week 6: Harmonic model
Week 7: Sinusoidal plus residual modeling
Week 8: Sound transformations
Week 9: Sound/music description
Week 10: Concluding topics; beyond audio signal processing
Best,
dp
Hi!
Alexander Carot contacted me to spread the news:
Starting in April 2016, three research assistant positions (PhD
candidates welcome) will be available within the Soundjack project. If
interested, please contact Prof. Carôt (a.carot(a)inf.hs-anhalt.de).
(copy-pasted from <http://www.soundjack.eu/jobs.html>)
I've been told one is TV-L13, the other is 75% and the third is 50%
(money equivalent can be found here [0])
The project will be about making music in a distributed environment,
contract will last three years (no idea if extendible).
Working from home is negotiable and even considered part of the project.
Candidates are expected to speak English, German is explicitly NOT
required.
Feel free to forward to interested parties.
Cheers
[0]
https://de.wikipedia.org/wiki/Tarifvertrag_f%C3%BCr_den_%C3%B6ffentlichen_D…
Hello,
I want to propose the follow flag for raptor in liblrdf library:
#if RAPTOR_VERSION >= 20000
raptor_world_set_flag(world, RAPTOR_WORLD_FLAG_WWW_SKIP_INIT_FINISH, 1);
#endif
before raptor_world_open() is called (explicitly or implicitly),
for example after raptor_new_world() in lrdf_init().
That flag avoids to call curl_global_init() (not thread-safe) in
raptor_www_init() and curl_global_cleanup() in raptor_www_finish().
Rare but possible (I'm lucky), if raptor is compiled with curl support,
I have experienced the follow crash during Rosegarden startup:
#0 0x00007ffff0a84f39 in lh_insert () from /lib64/libcrypto.so.1
#1 0x00007ffff0a087ba in OBJ_NAME_add () from /lib64/libcrypto.so.1
#2 0x00007ffff0a94cf8 in OpenSSL_add_all_ciphers () from /lib64/libcrypto.so.1
#3 0x00007ffff0a94cae in OPENSSL_add_all_algorithms_noconf () from /lib64/libcrypto.so.1
#4 0x00007ffff1acf20c in ?? () from /usr/lib64/libcurl.so.4
#5 0x00007ffff1ad605a in curl_global_init () from /usr/lib64/libcurl.so.4
#6 0x00007ffff22cc0fa in raptor_www_init () from /usr/lib64/libraptor2.so.0
#7 0x00007ffff22c9ef0 in raptor_world_open () from /usr/lib64/libraptor2.so.0
#8 0x00007ffff22c63f1 in raptor_new_uri () from /usr/lib64/libraptor2.so.0
#9 0x00007ffff5d26701 in lrdf_read_file_intl () from /usr/lib64/liblrdf.so.2
#10 0x00007ffff5d27626 in lrdf_read_file () from /usr/lib64/liblrdf.so.2
#11 0x00000000004d8d79 in Rosegarden::LADSPAPluginFactory::discoverPlugins() ()
The code is a simple lrdf_init, for-loop of lrdf_read_file, lrdf_cleanup,
and curl seems useless to read/manipulate rdf files for LADSPA plugins.
I have recompiled raptor without curl support
--with-www=xml
to use libxml, so the only work in raptor_www_init() is to set
world->www_initialized = 1;
without the call for curl_global_init().
Some updates on <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
zita-ajbridge-0.6.0
- Added -S option, disables resampling but of course
requires word-clock sync.
- Auto selection of best resampler filter lenght.
- Cleanup and bug fixes.
zita-mu1-0.2.2
- Bugfix: will now exit when zombified or when
jackd terminates.
- Added proper license headers and GPL3 copy.
I also completely replaced the code in Jack1 that
calculates the proper running order of clients.
The previous algorithm failed to do this in some
cases. It could not be 'fixed' easily as it was
basically using the wrong algorithm.
Affected files are
modified: include/engine.h
modified: include/internal.h
modified: jackd/clientengine.c
modified: jackd/clientengine.h
modified: jackd/engine.c
There seems to be no interest from the Jack devs,
but if anybody wants to test this I can either
provide the modified files or a patch against
git commit 5af5815c47630b77cc71c91a460f8aa398017cf7
(current HEAD).
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
I've run across a phenomena that puzzles me.
It appears that each time I start the jack server on an usb card,
jack_iodelay will report a different "extra loopback latency". I've
seen this phenomena on a behringer x32, and just verified it on a rme
babyface.
For instance with jack1 at 64/2 on the babyface, I come up with values
of 232,233,234, and 266. With jack2 I saw 231, 233, 248, 318, 335. A
run with jack1 at 2048/3 came up with 2589, 2590, 2633, 2634, and 2667.
I also tested with jack_delay, which also comes up with different
values when I restart the server. Note that on consequent invocations
without restarting the server the values stay the same for the 2
utilities.
Maybe not a huge problem and I suppose I'll set the latency
compensation somewhere in the middle of the results, but still I'm
curious of the mechanism behind this phenomena.
FWIW, I don't think I've ever seen this on my pci cards, but I'll run
some tests when I get to the hardware and find some extra time.
--
Joakim
hi richard, paul, stefan and fellow LADders,
the Debian folks currently are a bit at a loss of the proper
interpretation of the LADSPA_PROPERTY_REALTIME property.
ladspa.h says:
> /* Property LADSPA_PROPERTY_REALTIME indicates that the plugin has a
> real-time dependency (e.g. listens to a MIDI device) and so its
> output must not be cached or subject to significant latency. */
the discussion started about a year ago (see [760758]), and it seems
that there are two opposing interpretations of that property:
#1 setting the property indicates to the host, that the plugin must not
be used in a non-realtime environment.
this means that a plugin that has this property set, must not be used
for batch processing, e.g. because it uses wall-clocked input (like
MIDI-devices) that simply won't deliver proper input when running at a
speed that is decoupled from wall clock.
OR
#2 setting the property indicates to the host, that the plugin can be
run at a lower (timing) priority; so the host can deliberately add
latency without compromising the usefulness of the full processing
chain. that would be mostly for plugins that do not do any input ->
output processing, but only take input (e.g. metering, recording).
that's just a quick summary. there's more arguments in the bugreport
[760758].
personally i lean towards #1 (as i don't see much use cases for the
second interpretation), but given that someone as deeply involved into
linux audio as fons favours #2, i would like to ask the creators of
LADSPA for their canonical view.
thanks for your insights,
gfmadsr
IOhannes
[760758] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760758
Hello again! I come back to you all with a *kind of* new release of the
website, because the project doesn't really have releases, it just stays
there...
https://musical-artifacts.com/ is a place to collect free 'musical
artifacts', that is, pre-sets, configuration files, soundfonts, etc. make
them searchable and taggable and give credit to authors.
This **release** features a new redone design which encourages browsing
through all the tags, apps, and categories. So give it a try! The site
currently has ~100 artifacts, but it's growing steadily as I add them and
the first people are starting to contribute!
The full changelog is here: https://diasporabr.com.br/posts/799925
The code and more info is here:
https://github.com/lfzawacki/musical-artifacts
As always, feedback and contributions are welcome!
Hi all,
I'm currently doing accessibility features to GSequencer the resulted
code will be published as GSequencer v0.6.0.
If you want to contribute feel free to contact me by email.
http://gsequencer.orghttps://github.com/gsequencer
bests Joël