[This has been announced on LAA already, but I gather crossposts are
expected.]
We'd like to announce the first alpha release of QSynth, an attractive
Qt front-end to fluidsynth. QSynth is brought to you by Rui Nuno
Capela, developer of qjackctl, together with Richard Bown and Chris
Cannam of the Rosegarden team.
QSynth provides a simple front and configuration interface to the
fluidsynth software synthesiser to allow persistent storage of
fluidsynth configuration (and soundfonts) as well as providing visual
feedback and front panel controls for software synthesiser
parameters. QSynth can be used either as a standalone player or in
conjunction with any compatible sequencers. For more details,
screenshots, mailing list details and to download the source code
please visit:
http://qsynth.sourceforge.net
Requirements are Qt3.1.1 and libfluidsynth.
Please let us know how you get on with it!
Chris
>But you do have it recompiled for the right CPU architecture
>and not only moved?
Yes of course.
>BTW: There is a prefech bug on AMD processors - try to run it recompiled
>with less optimization, newer kernels have workarounds.
I will try that... but I get the freezes only with jack. ALSA applikations
run
just perfect in rt mode.
>Another thing to try is to run memtest86 (SuSE has it in Lilo menu)
>let it run for a while (full night)
I will do... and if nothing helps I will get a new mainboard ;-)
- Stefan
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
On Tuesday 18 November 2003 20.57, Stefan Nitschke wrote:
> >ping is answered = IRQs live.
> >Could you please try this.
> >Start rt_monitor in a text console CTRL-ALT-F1
> >
> >Start your client, return to console - what does rt_monitor print?
> >
> >(It could be the memory leak and mlockall(FUTURE) problem,
> >As I do not check that yet.
> >Another alternative is a fast forking client - they are hard to stop)
>
> OK, I tested it. There is no output at all from rt_monitor.
> I used the following:
> - starting rt_monitor in a console as root
> - ssh login from remote machine
> - starting jack
> - starting a jack client
What client? Any client?
>
> after a few seconds the machine was froozen and no output
> from rt_monitor.
Hmm...
> I assume its a hardware bug. On my Inspiron 8500 with nearly
> the same linux-2.4.19.SuSE kernel (plus patch for speed-step)
> I dont have any freezes at all.
But you do have it recompiled for the right CPU architecture
and not only moved?
BTW: There is a prefech bug on AMD processors - try to run it recompiled
with less optimization, newer kernels have workarounds.
Another thing to try is to run memtest86 (SuSE has it in Lilo menu)
let it run for a while (full night)
/RogerL
--
Roger Larsson
Skellefteå
Sweden
1. A short summary of changes
Ecasound's emacs mode, ecasound.el, has been updated to
version 0.8.3. Due to severe bugs found in the native Python
ECI implementation, the C implementation has been again set as
the default. Minor interoperability problems with older JACK
releases and Ecasound have been fixed. A bug that caused builds
against an external libreadline to fail, has been fixed.
Also recording problems with the WinTv 401Dbx and other
bt878-based devices have been fixed. This release is compatible
with the upcoming alsa-lib-1.0 releases.
---
2. What is Ecasound?
Ecasound is a software package designed for multitrack audio
processing. It can be used for simple tasks like audio playback,
recording and format conversions, as well as for multitrack effect
processing, mixing, recording and signal recycling. Ecasound supports
a wide range of audio inputs, outputs and effect algorithms.
Effects and audio objects can be combined in various ways, and their
parameters can be controlled by operator objects like oscillators
and MIDI-CCs. A versatile console mode user-interface is included
in the package.
Ecasound is licensed under the GPL. The Ecasound Control Interface
(ECI) is licensed under the LGPL.
---
3. Changes since last release
Full list of changes is available at
<http://www.wakkanet.fi/~kaiv/ecasound/history.html>.
---
4. Interface and configuration file changes
None.
---
5. Contributors
Patches - Accepted code, documentation and build system changes
Mario Lang (ecasound.el updated to 0.8.3, doc typo fixes)
Junichi Uekawa (ecasound makefile bug, doc generation
using Hevea)
Kai Vehmanen (various)
Bug Hunting - Reports that led to bugfixes (items closed)
Hirendra Hindocha (2) -- recording problems with WinTv 401dbx,
ecacontrol.py bugs
Stefan Bundt (1) -- ecacontrol.py breaks under heavy load
Dave Phillips (1) -- errors in EIAM help
Junichi Uekawa (1) -- compability bug with older JACK versions
---
6. Links and files
Web sites:
http://www.eca.cxhttp://www.eca.cx/ecasound
Source packages:
http://ecasound.seul.org/downloadhttp://ecasound.seul.org/download/ecasound-2.3.1.tar.gz
Distributions with maintained Ecasound support:
Agnula - http://www.agnula.org
Debian - http://www.debian.org
FreeBSD - http://www.freebsd.org/ports/audio.html
Gentoo Linux - http://www.gentoo.org
PLD Linux - http://www.pld.org.pl
SuSE Linux - http://www.suse.de/en
Contrib Packages and Add-On Distributions:
AudioSlack for Slackware - http://www.audioslack.com
PlanetCCRMA for RedHat/Fedora
- http://www-ccrma.stanford.edu/planetccrma/software
Thac's RPMs for Mandrake - http://rpm.nyvalls.seApps.kde.com packages for Mandrake/Redhat/SuSE
- http://apps.kde.com/rf/2/info/id/2146
Note! Distributors do not necessarily provide packages for
the very latest Ecasound version.
--
http://www.eca.cx
Audio software for Linux!
Hi,
I've written preliminary OSS driver for JACK. Patch for jack 0.80
attached.
This is by no means final, this is something pre-alpha, but seems to
work at least with alsaplayer. It's likely to contains errors in jack
driver implementation. All comments/patches/anything is welcome..
If you are compiling with OSS Lite, please comment out the non-S16
formats.
RedHat RPMs and patch available at http://www.sonarnerd.net/linux/ ,
SuSE 9 packages coming.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
what would all this mean for LADSPA?
1) there would need to be a way to associate plugins+GUIs since we
probably don't want them in the same object.
- could be done using LRDF or a dir search path combined with the
plugin ID.
2) the GUI would have to declare which toolkit it was using so that
the host could ensure support for it (i.e. fire up a thread that
will run the equivalent of gtk_main or QApplication::exec()) and
ask the relevant toolkit thread to call the primary entry point to
the GUI. how does it declare this? a well known symbol? is it a
char* or a function call? is it in the LRDF entry, or the filename,
or what?
3) adopt a standard for how the entry point is to be
called. presumably it should get a pointer to the plugin instance,
but what (if anything) else? oh yes, a return value that provides
a way to terminate the GUI.
4) the names of toolkits would have to be standardized and possibly
include version information. "GTK+:2.2" or "Qt:3.1" might work, for
example.
5) a small library (which i have more or less started already) to
provide simple C functions to offer per-toolkit support. a host
would look at the pluginGUI toolkit, call the support function
with the .so name, and the right things would happen. the library
needs an ancillary function to kill the GUI when the time is
right.
6) [ only if we really wanted hosts to have a "real" handle on the
plugin GUI window ] the library would need to contain a way to
pass in an X "Window", and wrap it up as a native drawing area
for each toolkit. i would prefer not to do this for now, if ever.
--p
>BUT, I think a userspace daemon that starts at boot time and protects
>against lockups (rt_monitor) would be a very good thing to have.
>
Yes indeed, but on my XP machine which freezes after a few seconds
after a client had connected to jack even rt_monitor did not helped,
the machine keeped totally locked. Ping is still answered but thats it.
- Stefan
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
These updates makes it possible to use windows vst plugins in
linux applications getting very descent realtime performance.
I have successfully ran vst plugins in ardour with 2.66 ms latency.
Sources:
http://www.notam02.no/arkiv/src/
Linux Vst Compatibility Page
http://80.61.20.184/vst/
Tutorial:
http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/
Mandrake binaries: (not the latest versions (yet))
http://rpm.nyvalls.se/sound9.1.html
Vstserver 0.2.7 -> 0.2.8:
-------------------------
-Added SCHED_FIFO priority and locking all mem (mlockall) to the
processing thread. Can be used without being root by for example
using the givertcap program by Tommi Ilmonen
http://www.tml.hut.fi/~tilmonen/givertcap/
To turn off realtime priority, start the vstserver with either
the "-NRT" or "--nonrealtime" flag.
vst ladspa plugin v0.1.5 - stable
----------------------------------
-Fixed the worst nonrealtimeness for the default mode.
When using realtime priority on the vstserver, it
should not be necesarry to set LADSPAVST_RT to "1".
--
Can this get applied? We discussed it in September, and I thought it
was going to be applied, but it never was.
It includes defines for:
LADSPA_HINT_MOMENTARY
LADSPA_HINT_RANDOMISIBLE
Taybin