This is a simple applet for controlling the LASH Audio Session Handler.
When you run it it will appear as a small LASH icon in your
"notification area" or "system tray" (if your desktop manager is
compatible with freedesktop.org's "System tray" standard,
http://www.freedesktop.org/Standards/systemtray-spec). This is typically
somewhere in the panel in KDE or GNOME. There is also a front end for
the WindowMaker dock (or compatible window managers).
Changes since 0.2.0:
* A DockApp front end (thanks to Nedko Arnaudov)
* A "Recent" submenu for restoring recently saved sessions
* A "Connect" submenu for connecting and disconnecting JACK ports
* Doubleclicking session directories in the file selection dialog
restores the session instead of going into the directory
* The message window is removed
Get it at http://dino.nongnu.org/glashctl
--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
"Ivica Ico Bukvic":
>
> So, if I understand this correctly, there is no API out there that simply
> translates common GUI VST calls into any of the libre toolkits which are
> also available on Linux, other than the full-fledged Wine implementation? If
> so, that *really* sucks.
>
Well, probably maybe. Its hard to know what GUI toolkits closed source
software use. And it doesn't matter very much either until there is a
big enough marked for commercial vst plugins on linux, which might never
happen because we have better standards than vst for fitted for linux
audio: The trouble of getting various x toolkits to work with each other
is probably more easely solved by using dssi or just making jack programs
out of the plugins. Besides, ladspa is a much more supported standard than
vst on linux, and for most vst plugins, it probably doesn't require that
much work to make them support ladspa as well as vst.
I think it boils down to vst plugin developers not having much interest
in linux audio. Thats where the work needs to be done I think.
Hi list.
In my quest for good audio related documentation for the Linux platform, several things
strike me:
1. It is very scattered around the internet.
2. It has no unified structure
3. It is, in some cases, downright ugly. ;)
Don't take this as critisism of webdesigning skills on a community wide basis, I know
most of the people responsible for the websites have better things to do than to put
days or weeks designing their content to please the eye. As everyone knows already,
content is king and webdesign is for sissies. ;)
However, a non-cluttered look and feel should make a newcomer more inclined to find what
they seek, a link-farm of some sort would enable people to delve further into the world of
linux audio and so on and so forth. It seems to me that most places throughout the Linux
audio community are scattered like islands in a very big ocean with nothing to bridge them.
I was thinking about a top row somewhat like the OSTG-bar on slashdot.org and the like,
with maybe 6-10 of the most central sites in the linux audio community. Any rating of
these sites will not be done by me, that's for sure. ;)
The thought was to incorporate this bar on as many sites as possible, with a central link
repository of some kind. How do you feel about such an idea?
I'm willing to implement it, it there's any interest.
Regards,
Mathias
Hi All,
This is a request for information about which bit(s) of software
people would recommend for a particular musical workflow. I build
my synthesizers in Puredata and I have an uc33 controller to do knob
tweaking via midi. This Christmas my girlfriend is getting me a USB
midi keyboard and I'd like to start writing some 'live' tracks using
that. Puredata's strong point is not sequencing and notation, so what
I need is an application that I can send midi notes and controller data
through, which will remember them and pass them on to Puredata. Ideally I
could go back after playing a track live, and shift notes around, modify
controller envelopes etc. I am happy to do something like use vmidi
loopbacks or whatever. I'm on Debian and my preference is for something
that won't pull in too many wacky dependencies, but please don't let that
stop you suggesting something. I use Fluxbox and mostly Gtk based apps.
Thanks very much for your time!
Best,
Chris.
-------------------
chris(a)mccormick.cx
http://mccormick.cx
Just reporting on status of hooking up VOIP to JACK. I'm sure there
are many wondering.
I found twinkle softphone to work very well with oss2jack. (I'm on
linux-2.6.18-rt1). Twinkle unfortunately does not separate the UI from
the core, but it's the only piece of software I've found that works.
I hope we can get the LAD VOIP channel up and running again.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
The irony of this is killing me. I had a singing capacitor in my
notebook computer, which I was able to solve using a load generator at a
low scheduling priority. However, that same capacitor is what had
triggered me to get a higher-end sound card in the first place.
Now this higher end sound card has quite a loud hum when the phantom
power for its mic pre-amps is on. Interestingly, when I mix the signals
from both pre-amps by connecting them both to the same outputs in JACK,
the noises from the Mics cancel each other out.
The load generator has no influence on the hum; however, the sampling
rate does. The higher the sampling rate the higher pitched the hum is.
The inverse is true for buffer size: The larger the buffer, the lower
pitched the hum.
My current theory is this: Jack causes a surge of power in the CPU
through an interrupt. This surge gets transformed into current in the
grounding cable through electromagnetic induction, which in turn induces
a current in the microphone pre-amps, which causes the hum. The hums can
cancel each other out because... uh, not the slightest on that one.
Help appreciated.
Carlo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
xjadeo-0.4.0-rc1 - X Jack Video Monitor
http://xjadeo.sourceforge.net/
Xjadeo is a simple movie player that synchronizes video to an external
time source such as jack transport. It is intended to aid sound
composition to a video clip.
This is a rewrite of the previous 0.1 release and a
conclusion of the ongoing development during the last year.
New Features include
* displays: Xv, x11+imlib2
* fullscreen and letterbox video
* improved video file reading via ffmpeg
* on screen display
* configuration file
* LASH - session management
* optional GUI - qjadeo
* remote control interface
* Midi Time Clock quarterframe sync
* documentation
* OSX support (experimental)
Release Notes:
Mixing ffmepg and Xv may produce unexpected effects on some
architectures. Please report them as those are the main reason for this
release-candidate: http://xjadeo.sourceforge.net/doc/ar01s03.html#problems
Although there are many new Features, only the on-screen-display might
have an impact on the perfomance of xjadeo. since 0.3.13 xjadeo
uses gettimeofday(3) for it's internal timekeeping. - it appears that
using clock(3) was a major-bug in the original xjadeo code, though not
harmful.
The default xjadeo configuration is to run with a low profile:
Additional Features need to be enabled explicitly (LASH is an
exception). Performance highly depends on the Codec and geometry of the
video file: the -K, -k arguments allow to seek many file formats - but
is intended only for preview!
http://xjadeo.sourceforge.net/doc/ar01s03.html#video_formats
There are open ends in osX support: This version includes workarounds
for use with ffmpeg on PPC. , but they might not work for all versions
of ffmpeg. - Are you an intel-mac user who succeeded to run 'make test'
in the ffmpeg svn src? - give us a wink :)
http://packman.links2linux.org/package/xjadeo/ provides SuSE-RPMs for
i586 and also for x64-64bit. many thanks! We are pleasantly surprised,
since we expected serious video-Codec and xjadeo-Xv problems for 64 bit
architecture. We have not tested any of the RPMs ourselves. - imlib
display + mjpeg codec should work though.
A beta-devel debian package can be built from source and the
xjadeo.spec.in is intended for FC4 RPMs.
robin /at/ gareus /dot/ org
luisgarrido /at/ users /dot/ sourceforge /dot/ net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFb2SXeVUk8U+VK0IRAksdAJ9UzrecVjOOQuwWtCWfmh9EjggflACgga56
yTXu6ToamWx+UmNw+yyl5Dg=
=HwID
-----END PGP SIGNATURE-----
I found
http://repos.opensuse.org/home:/appleonkel/SUSE_Linux_10.1/i586/kernel-rt-d…
on the internet while looking for info on how to patch a realtime kernel
in suse 10.1. I'm having some problems with it (it didn't boot; I used rpm
-i ... to install it) and so if anyone has any experience with this or
advice for SUSE 10.1 (I'm leaving suse soon anyway -- heading to DeMuDi)
then I'd appreciate. I understand that patching a kernel for suse 10.1
with a realtime patch is non-trivial.
Any help appreciated.
Jonty
alsa.opensrc.org shows no "recent changes" in 2006.
I recently spent some time updating the USB Midi page
http://alsa.opensrc.org/USBMidiDevices
and now it says last modified 2005 :-(
I *think* my changes are on the page, but the dates are wrong?
Hope it didn't lose all that work I did.
Who runs that site? What happened? Any backups?
--
Paul Winkler
http://www.slinkp.com