The build didn't work for me at first.
Workaround:
ln -s /usr/lib64/pkgconfig/slv2.pc /usr/lib64/pkgconfig/libslv2.pc
emerge ingen
stop emerge ingen after src unpack
ln -s /usr/lib64 \
/var/tmp/portage/media-sound/ingen-9999/work/ingen-9999/lv2/lv2/osc/.libs
ln -s /usr/lib64 \
/var/tmp/portage/media-sound/ingen-9999/work/ingen-9999/redlandmm/src/.libs
restart emerge
To Stephane, and the team at Jackdmp.
I'm having a great run with the latest build, highly stable, and just keeps
going all day every day, even when i'm throwing orchestras at it.
I have a suggestion.
A lot of programmes seem to be going through a transition at the moment from
Alsa to Jack in the midi department. And the latest jack midi has been
delightful to use in its native environment.
Is there an opportunity here to include in Jack, a 'virtual' transition port
system of say 32 input and 32 output midi ports, that show in the gui
(Qjackctl) and enable the user to seamlessly link alsa midi into Jack midi?
An example would be, in the Jackmidi tab, a set of 'JAT ports' (32 input, 32
output), and the same in the Alsa tab? (32 input, and 32 output)
Or is something like this, for multiple midi ports, already available?
For us crusty middle aged orchestral chaps writing 'elevator music',
multiple midi ports are a must, and essential to controlling big templates
in various programmes, so any guidance, or feedback on this would be greatly
appreciated.
Alex.
Hello everyone!
First time poster, long time fan.
As a user (one of many) of LinuxSampler I'm/we're in dire need of a friendly
convolution reverb. Unfortunately I've not been able to compile JConv or
figure out how to configure BruteFIR to work with JACK and my collection of
IRs in WAVE and AIFF formats.
Frustrated I took a stab at writing a simple JACK client for the Freeverb3
convolution reverb. But I can't get it to work properly. Could anyone
knowledgeable take a look at it and help us out? I've posted the code of my
(more or less copy-and-paste) attempt here:
http://bb.linuxsampler.org/viewtopic.php?f=7&t=33#p291
TIA
--
Anders Dahnielson
<anders(a)dahnielson.com>
On Feb 15, 2008 5:13 PM, Anders Dahnielson <anders(a)dahnielson.com> wrote:
>
> On Fri, Feb 15, 2008 at 11:50 PM, Reuben Martin <reuben.m(a)gmail.com> wrote:
>
> > On Fri, Feb 15, 2008 at 4:27 PM, Anders Dahnielson
> >
> > <anders(a)dahnielson.com> wrote:
> > >
> > >
> > > On Fri, Feb 15, 2008 at 4:24 PM, Reuben Martin <reuben.m(a)gmail.com>
> wrote:
> > > >
> > > > On Fri, Feb 15, 2008 at 6:48 AM, Anders Dahnielson
> > >
> >
> > > I tried to unmask it (from the Gentoo Pro-Audio overlay) but I could not
> > > even get libdsp to build on my 64-bit system. Both jack_convolve and
> > > dssi_convolve are dependent on libconvolve which is dependent on libdsp,
> I
> > > guess.
> >
> > That's to do with some minor differences when compiling for x86_64.
> > Actually, this *should* be fixed already. I filed a bug for it myself
> > and it was (supposedly) taken care of. Make sure you've synced the
> > overlay.
> >
> > If it still doesn't work, the quick and dirty way to fix it is to add
> > -fPIC to your CFLAGS and CXXFLAGS while building these packages.
> >
>
> Still not compiling. Forgot to include the error I'm getting, here it is:
>
> x86_64-pc-linux-gnu-gcc -D_REENTRANT -D_THREAD_SAFE -D_ISOC9X_SOURCE
> -D_GNU_SOURCE -DUSE_MEMMOVE -DDSP_X86_64 -I. -I../Inlines -I/usr/include -c
> X86.c
> x86_64-pc-linux-gnu-gcc -D_REENTRANT -D_THREAD_SAFE -D_ISOC9X_SOURCE
> -D_GNU_SOURCE -DUSE_MEMMOVE -DDSP_X86_64 -I. -I../Inlines -I/usr/include -c
> X86-64.c
> X86-64.c: In function 'dsp_x86_64_iirf':
> X86-64.c:318: error: inconsistent operand constraints in an 'asm'
> make: *** [X86-64.o] Error 1
Apparently the new ebuild tries to use the x86_64 assembly that comes
with the package. It doesn't compile correctly with gcc 4.
Use the attached ebuild in it's place. Also remember to add -fPIC to
your CFLAGS / CXXFLAGS while building these three packages.
-Reuben
Hi LADs,
After some time in quarantine, meaning that it just passed almost 40
days since its last public appearance, the frivolous debutante has
matured a bit but not that much. Truth is, it is not quite healed and in
fact, it is getting seriously bloated ;)
Qtractor 0.1.1 (futile duchess) has been released!
Qtractor is an Audio/MIDI multi-Âtrack sequencer application, written in
C++ around the Qt toolkit. Its primordial target platform is Linux,
where the Jack Audio Connection Kit (JACK) for audio, and the Advanced
Linux Sound Architecture (ALSA) for MIDI are the main infrastructures to
evolve as a fairly featured Desktop Audio/MIDI Workstation GUI specially
dedicated to the personal homeÂstudio. It sits confortably tagged as for
the techno-boy bedroom home-studio. There's no genre segregation here,
it also applies to techno-girls ;).
Now seriously, it even has its own Wikipedia entry already:
http://en.wikipedia.org/wiki/Qtractor.
Back to business, these are the major highlights for this release:
- Draft user manual, contributed by James Laco Hines.
- Native Linux VST plug-in support.
- Initial DSSI plug-in support (audio effects only atm.)
- User configurable keyboard shortcuts.
- JACK server auto-start.
- Clip fade-in/out relative resizes.
- Auto time-stretch now optional.
- MIDI capture/record input quantize.
- Major plug-in infrastructure rewrite.
- Seamless plug-in drag-and-drop.
Check it out, from the official project web site:
http://qtractor.sourceforge.nethttp://sourceforge.net/projects/qtractor
Direct link for the source tarball download:
http://downloads.sourceforge.net/qtractor/qtractor-0.1.1.tar.gz
The new user manual draft is also made available:
http://downloads.sourceforge.net/qtractor/qtractor-0.1.1-user-manual.pdf
Literal change-log follows. since the last 0.1.0 (frivolous debutante)
alpha release:
- After some great user demand, keyboard shortcuts are finally
configurable, as found provisionally under Help/Shortcuts...,
for the main application menu and for the MIDI editor as well.
- Debian package gets SSE optimization disabled as default.
- At least some transport actions get to be non auto-repeatable
when pressed for much too long, as Play and Record, avoiding
the tumbling imposed from the keyboard.
- For the first time ever, jackd auto-start is now allowed (!).
- OSC service support through liblo gets optional at configure
time, now leading the way to proper DSSI plug-in hosting.
- All plug-in widget controls count are now capped to one hundred.
- Plugin paths setup is now made available on the options dialog,
overriding each of respective default settings, as implicit from
the LADSPA_PATH, DSSI_PATH and VST_PATH environment variables
(see View/Options.../Display/Plugin Paths).
- Clip fade-in/out lengths are now kept relative to tempo changes
and also to clip offset and length changes (clip resizes).
- Automatic time-stretching for all audio clips when session tempo
changes, may now be disabled/enabled as a global session option
(see View/Options.../Audio/Playback/Automatic time-stretching).
- Double-clicking on an empty area (de)selects all clips on track.
- MIDI capture (record) quantization is now an option, possibly
handy for some jerky performance musicians, as the one found
in myself ;) (see View/Options.../MIDI/Capture/Quantize).
- The global options dialog (View/Options...) has seen its Display
tab page being moved back and to the right.
- Major rewrite of the plug-in infrastructure, adding primordial
support for DSSI and native VST plug-in flavors.
- Drag-and-drop of plug-in instances are now allowed intra- and
inter-mixer strip chains, either on tracks or buses.
- Turning track record off while recording is rolling was leaving
the session in a inconsistent recording status, now fixed.
- A random but instant crash upon audition/pre-listening player
onset was hopefully fixed.
Cheers && Enjoy
--
rncbc aka Rui Nuno Capela
Quoting Anders Dahnielson <anders(a)dahnielson.com>:
> Frustrated I took a stab at writing a simple JACK client for the
> Freeverb3
> convolution reverb. But I can't get it to work properly. Could anyone
> knowledgeable take a look at it and help us out? I've posted the code of
> my
> (more or less copy-and-paste) attempt here:
>
> http://bb.linuxsampler.org/viewtopic.php?f=7&t=33#p291
Regarding recording impulses, one should really check Aliki on
http://www.kokkinizita.net/linuxaudio/ (manual and download on the download
page).
Sampo
Hello all,
A few days ago I asked Paul Davis what he knew concerning the AES32
and using the hdspmixer tool to access it's matrix. Currently it
doesn't support it, and given that I haven't been able to contact
anybody who developes hdspmixer or the AES32 driver, he was the only
one who I could find who could at least answer any questions. The
basic answer was "there isn't anybody to fix it for you." :P
So, I've spent the last two days messing with the hdspmixer code and
have confirmed my initial assumption that I have no idea what the hell
I'm doing. I started by trying to fix it so that the hdspmixer would
support cards from both the hdsp and hdspm drivers. I'm sure it could
be done, but the drivers code has diverged enough that it makes it
more work than I really want to do. So I yanked out all code that is
specific to hdsp and made it so that it will compile against the hdspm
code. Basically it's a version of hdspmixer for the AES32 and MADI
cards. (I'm not sure how the channel mapping in MADI works out, so
that's not in it yet)
The good news is that it will compile. The bad news is that it
immediately segfaults. And gdb doesn't really tell me anything useful,
but then again I really don't know how to use it.
Therefor I'm shamelessly soliciting any help that I can get. I really
want to be able to use the AES32, but I'm starting to get in over my
head. The hdspm driver is a bit silly without a functional matrix
mixer for it. I can send the code to anybody who would be willing to
give advice, give me code fixes, fill in the missing bits for MADI,
take over the project, or just provide more confirmation that I really
don't know what the hell I'm doing.
Oh, and as a little bonus I discovered that the hdspm driver only has
a dummy typedef for hdspm_peak_rms_t (as well as a few other
functions) so there is no code for input_peaks, output_peaks,
input_rms, playback_peaks or playback_rms. :P
-Reuben
Dear all,
The Linux Audio Conference 2008 in Cologne (Feb 28th - Mar 2nd 2008)
is just one month away now. The programme is shaping up, concerts are
being organized and coffee is about to be ordered.
To help us with planning the LAC2008 we kindly ask you to register now
at the conference website. This helps us to estimate how many visitors
we may expect, what individuals the audience is made of, and allows to
produce name tags for all attendees so that it becomes easier to
identify each other.
To register, please use the "Registration" form at
http://lac.linuxaudio.org
Also we now have put accommodation info plus some maps of the
conference location online. You can find these on
http://lac.linuxaudio.org under "Visitor Info".
Finally if you're living in Cologne or nearby: We are looking for
volunteers who would like to help out in any way, e.g. to host artists
and paper presenters in their flat. If you want to offer your help,
please contact the LAC2008 orga team at lac(a)linuxaudio.org
The LAC2008 chair is looking forward to have another great conference
with you all.
All the best
--
Frank Barknecht and Martin Rumori
Chairs of LAC2008
Hi,
I was planning to spend some effort at LAC this year to get jack
support in my Video Editor right, and I was wondering what would be
the best model to implement.
My App has a simple timeline that can have an arbitrary number of
tracks, and each track can hold clips at arbitrary positions. Each
clip is one audiofile or audiotrack from a videofile, which does not
make much of a difference. Eventually I also perform operations like
resampling or filters per clip.
Potential Models:
A)
1 Thread that connects to the jack-callback with a ringbuffer, and
that does everything, mixing, effects, disk-IO, etc.
Has the advantage that it is probably not very difficult to implement.
However, compute intensive stuff that is not IO bound happens outside
the jack-thread, which I guess is not optimal.
B)
1 Disk thread+ ringbuffer per clip. Advantage: compute intensive stuff
is in jack-thread. Disadvantage: does not scale to long timelines with
many clips and therefore many threads.
C)
1 Disk thread+ringbuffer per Track. Advantage: could eventually be
implemented such that compute-bound stuff happens in jack-thread, or
at least that "some" of this happens in the jack-thread. The number of
threads is likely to be small enough to handle that.
D)
1-n Single Diskthread(s) for everything, and 1 Ringbuffer per Track.
Make number of Disk-Threads limited, and eventually add more for
multi-core/SMP, and let those feed into per Track Ringbuffers
according to some home-brew scheduling algorithm? Wouldn't waste a
thread per track?
E)
Be lazy and reuse something that someone else has written. ;-)
So, what suggestions can you make about what I should do? I know that
there will be some not so nice corner cases when seeking, the
necessity to reset ringbuffers, scrubbing during playback, etc.....
My "Latency" Requirements are probably fairly moderate, so I could
compromise in that respect.
Another "Use-Case" that I would like to implement is
"Project-Nesting", preferable in "Real-Time", and only additionally by
rendering the nested project into a file. For this I think it would be
ok to have a big enough buffer between the current project and the
embedded project, and do the "on the fly rendering+IO" in the
"Disk-Thread".
what do you think?
Cheers
-Richard
--
Don't contribute to the Y10K problem!
We are jubilous to announce CLAM 1.2 'GSoCket plugged-in release'.
We had to wait for some months to make this release as we had to
redeploy the multiplatform release infrastructure [1]. Thus, the
feature buffer for this release is pretty full. It incorporates both,
the results of the Summer of Code [2] students work and the
involvement of David and Pau with Barcelona Media Foundation Audio
Research Lab[3].
We want to thank the involvement of GSoC students Hernan Hordiales[4],
Bennet Kolasinsky[5], Greg Kellum[6], Andreas Calvo, Roman Goj[7] and
Abe Kazemzadeh, Google Inc, and Barcelona Media audio lab members
for their precious involvement in CLAM.
[1] http://clam.iua.upf.edu/testfarm/
[2] http://clam.iua.upf.edu/wikis/clam/index.php/GSoC_2007
[3] http://www.barcelonamedia.org/index.php/linies/10/en
[4] http://h.ordia.com.ar
[5] http://bennettdoesclam.blogspot.com
[6] http://gregkellum.com
[7] http://ro-baczek.blogspot.com
A summarized list of changes follows. See also the CHANGES files[8]
for details, or the development screenshots[9] for a visual guided tour.
As usual binary packages for Windows, MacOSX and several flavors of Linux
are available to download.
[8] http://iua-share.upf.edu/svn/clam/trunk/CLAM/CHANGES
[9] http://clam.iua.upf.edu/wikis/clam/index.php/Development_screenshots
Summary of changes:
The most exciting feature is the new plugin system (acalvo)
which enables third party algorithms to be distributed separately
from the core binaries. LADSPA plugins support has been enhanced
and a first iteration on FAUST[10] integration. The wiki[11] contains
very nice how-to's that cover most of that.
[10] http://faust.grame.fr/
[11] http://clam.iua.upf.edu/wikis/clam
Most of the GSoC work come as plugins: a SMS Synthesizer (gkellum),
a Voice synthesis/analysis (akazem) and some some cool guitar effects
(hordia). Also not included as plugins but in the main repository
several enhancements have been done on the SMS transformations (hordia)
and the tonal analysis (rgoj).
Some interesting work has been done on the Barcelona Media Audio Lab
on having a system to simulate 3D room acoustics which can be reproduced
on several exhibition systems. Some precomputed room databases are
available to try. Check the wiki NetworkEditor Tutorial for more
information.
Regarding the applications, Network Editor incorporates new usability
enhancements, a new on-line Tutorial and a new Spectrogram like view.
The Annotator received Bennet Kolasinsky attention improving its the
flexibility of its interface, the practical effects are multiple
segmentation and low-level descriptors panes and that we are pretty
close to visualization and auralization plugins.
Enjoy.
The CLAM Team
