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
Hi,
I am trying to contact the authors of Horgand, who are Nick Holborn and Krzysztof Foltman. The reason is that Horgand is an organ with an exceptional beautyful sound that uses an algorithm that is
nowhere described in books etc. They call it FM synthesis but it is'nt.
Another reason: there are some bugs in their code (version 1.15) that cause an immedient crash if one compiles the program from source code, whereas if installed directly from the Ubuntu repository it
works correctly. So the code base used by Ubuntu must be different from the source code at Github. The reasons of the crash are some buffer overflows, easily found using valgrind.
Does somebody know where I can find these guys? My own email address is:
w dot boeke at upcmail dot nl.
Wouter Boeke
Hi Ralf, thanks for the info.
So Ubuntu uses Horgand version 1.14, not the recent version 1.15. Also, I found some more buffer overflows.
However my main problem remains: I would like to find those authors. Their email adresses in the README alas don't work.
Wouter Boeke
libsoundio is a C library providing cross-platform audio input and output
for real-time & consumer software. It supports JACK, PulseAudio, ALSA,
CoreAudio, and WASAPI.
It is an alternative to PortAudio, RtAudio, and SDL audio.
http://libsound.io/
Hi all.
After upgrading to fc22 during summer, I'm having issues with 32bit jack
clients running in my 64bit jackd.
I'd be thankful for any clues to what's going on, and ways to debug
this. And if others would care to check, and confirm/disprove the same
behavior, please tell me what you get.
Here's what happens:
The 32bit clients connect well, but the callbacks never seem to return,
making jackd send out a steady stream of xruns and errors:
JackEngine::XRun: client = simple_client was not finished, state = Triggered
I'm checking with jack2 installed (jack-1.9.10), with .i686 and .x86_64
versions installed using the standard fedora packages.
The same 32bit clients work well in fc21, fc20, and ubuntu 14.04 (in a
vm on the same hardware). Afaik, nothing has changed vs. the -mixed
flag in jackd, and would expect 32bit clients to run well inside a 64bit
jackd.
Checking with example-clients/simple-client.c from the jack sources:
$ gcc -m32 -g -O -lm -ljack simple_client.c -o simple_client
$ ./simple_client
- results in the noted behavior. Without -m32 everything's fine.
Thanks,
-anders