I just started to learn some C++. Currently I'm working on some Qt MIDI
I've found some code which makes life for me much easier. The code is
licensed under a MIT license and can be found here:
The free Qt version I use is under GPL.
I wonder if I'm allowed to distribute a Qt application as a GPL
application even if I include the classes mentioned above, or if I need
to implement my MIDI connectivity by myself.
Any opinion is much appreciated.
Thanks & best regards
this is the first public tarball of dssi_convolve, a DSSI wrapper around
you need libconvolve-0.0.5.tgz for this, too (fixed some minor bugs)
- no GUI yet. Send OSC commands directly to load a responsefile. If you
use the included test_dssi_convolve.om patch in om-synth (you need
latest cvs for this), you can use sclang [supercollider3] like this to
send it stuff:
a = NetAddr("localhost", 16180);
a.sendMsg("/dssi/test/Convolve_0/configure", "rtprio", "0");
a.sendMsg("/dssi/test/Convolve_0/configure", "responsefile", "/home/tapas/sound/ResponseFiles/room/Thick Room.wav");
The included om patch provides stereo input and stereo output. A copy of
the stereo input is delayed (by 0.68s which is just the delay introduced
by dssi_convolve at a samplerate of 48khz and a partition size of 16384)
and mixed back into the output. Both input signals are also mixed
together and fed into the single convolution input. The stereo
convolution output is mixed into the stereo patch output. While this
kinda abuses the convolution to do stuff it shouldn't it still sounds
configure keys understood:
"responsefile" value: filename. load the specified responsefile
"rtprio" value: the desired SCHED_FIFO prio for the worker thread. when
0 is specified SCHED_OTHER is used.
- the convolution runs in a lower prio thread and a huge buffer [default
16384] is used to decouple the convolution size from the hosts
periodsize. This introduces 2*partition size frames additional latency
which is reported on the "latency" control output. The partition size
can be changed by altering the DEFAULT_PARTITION_SIZE in the source
code. A configure key for this will be added.
- loads only in om, not in jack-dssi-host. [any clue?]
- might have problems loading mono files. not tested.
- SConstruct broken. Use the Makefile
- might lock up your boxen. so if this is a problem for you, inspect the
source first and fix all bugs ;)
- millions more i'm sure. if you find any please let me know :)
- Different channel versions (mono, 4 channel, 6 channel). This provides
always a single input only but the loaded response files may then be
mono, stereo, 4-channel or 6-channel.
- Realtime mode (where partition size == hosts buffer size -> no
additional delay). Need to figure out some DSSI specifics to find out
how to discover host buffer size before initial configure call is done
(which might load a responsefile and for which the partitioon size needs
to be specified)
TODO's might take a while due to my limited time atm [studying]. Help
appreciated. Drop me a mail.
Feedback is most welcome.
P.S.: yes i will remove the audio rate gain input port in the next
realease. I don't need it and i figure it might confuse DSSI host apps
that try to figure out themselfes how to hook it up.
Snd-ls is a distribution of the sound editor Snd. Its target is
people that don't know scheme very well, and don't want
to spend too much time configuring Snd. It can also serve
as a quick introduction to Snd and how it can be set up.
0.9.4.0 -> 0.9.5.1
-Upgraded SND to V7.15 from 17.8.2005. Many important changes.
-Various improvements in the user-interface.
-Upgraded snd to V7.15 from 12.8.2005. Many important changes.
-Various other things.
-Upgraded various rt-stuff.
-Upgraded various rt-stuff++
-Removed jack_set_server_dir guile-binding from rt-engine.scm, because its
removed from the newer versions of jack.
On Fri, 12 Aug 2005, R Parker wrote:
>> s. subject. down for me for quite a while already.
And still seems to be. :( I guess Benno is still the admin contact for
the site -- anyone got a more recent email address for him?
> Please somebody fix the server. I'm experiencing
> extreme lad mailing list archive withdrawl syndrome
> (elmlaws) disease.
Fortunately the web archives are hosted on a different server:
links, my public keys, etc at http://eca.cx/kv
we are trying to use linphone for a project,i dont know whether it supports
echo cancellation or not,i think it is not there in linphone.
can we integrate the echocancellation module given at
http://home.arcor.de/andreadrian/echo_cancel/draft-aec-03.txt to the
linphone..or can we seperate out the echo cancellation module in Speex and
use it with linphone? which will be better and easier?
"This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged
information. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
Any unauthorized review, use, disclosure, dissemination, forwarding,
printing or copying of this email or any action taken upon this e-mail is
strictly prohibited and may be unlawful."
The first official release (0.1.1) of JAPA is now available at
Changes w.r.t. the 0.0.1-alpha release:
- now uses anti-aliased fonts (via Xft/fontconfig)
- added /etc/japa.conf
- added 80dB range
- added 440Hz log scale
- some bugfixes
Many thanks to the alpha testers, in particular Lukas Erni.
JAPA is a 'perceptual' or 'psychoacoustic' audio spectrum
analyser. This means that the filters that are used to
analyse the spectrum have bandwidths that are neither
constant (as in JAAA), nor proportional to the center
frequency (as in a 1/3 octave band analyser), but tuned
to human perception. With the default settings, JAPA uses
a filter set that closely follows the Bark scale.
In case you didn't know, the high res timers patch (which Ingo calls "a
critical piece of RT infrastructure") has been merged into Ingo's RT
preempt patch. So I think it's safe to assume it will be going in the
mainline kernel too.
This is great news for Linux audio as sub HZ timers enable lots of cool
features. We will be able to send a MIDI clock that is as solid as you
get from dedicated hardware.
i played around with extra buffering the input/output of libconvolve
(new tarball  and updated jack_convolve  (understands the
--partitionsize=frames argument now which makes it use the specified size
for the partition size instead of the jack buffersize), and like
expected this doesn't do CPU usage any good.
Easy to see in this example:
jack_buffersize = 1024
partitionsize = 2048
Now the convolution code is executed only every second jack process()
cycle. If the previous DSP usage was like 20% in every process cycle
then it's ca. 25% in every other cycle now (estimate).
The solution to even out the load is to use an extra thread .
For best performance i would assume that the DSSI needs an extra thread
with RT scheduling (if available) and an RT prio which should be lower
than all the other jack and midi threads of i.e. the DSSI host and other
So i got basically two questions:
a] is it possible to use threading in a DSSI?
b] would a RT prio of 1 (for the convolution thread) be an OK
compromise? It will be lower than all audio stuff on a typical jack
system? What is jackd's default RT prio again?
 - http://tapas.affenbande.org/?page_id=5
 - yes, i'm aware that this needs again some extra buffering ;) But
this whole larger-partitionsize-than-jack-buffersize-thing is all about
trading latency for cpu niceness. If the convolution is used as non RT
effect [like i.e. in a DAW for prerecorded material], then latency
doesn't matter as long as the host compensates for it.
 - i'll probably be offline from the 12th on, as i can't pay my phone
bill, so be quick with answers ;)