Hello,
> Second, I noticed there's a click
> between segments when I split then using < X >.
Strange, are you sure you use 0.40.0 ? :D
It would be very helpfull if you could tell me how to reproduce it and/or join
us in #traverso / traverso-devel ml to look into this.
> Also, when I used < E > for
> an external command (SoX - can this be changed?), the clip then becomes
> silent. I typed "reverse" into the box. It did reverse the clip, but like I
> said - silence.
The external processing was a feature request from a user, and given the way
traverso works, I stated that creating a Command class to implement the
functionality was easy.
That turned out to be right, but unfortunately, I didn't get much feedback.
The external processing as such is still a somewhat experimental feature, and
the command has been hardcoded to sox.
If there are more people who would like to see this functionality expended,
please drop a note, with what exactly you want to accomplish, how, which
parameters and so on.
> :) Anyways, then I split the reversed clip and could then hear it. Also, no
We did have these problems long ago, weird you have them still....
But it could be related to the external processing not fully tested...
> JACK transport support?
Please add a wish for this in the bug tracker [1] !
Regards,
Remon
[1] https://savannah.nongnu.org/projects/traverso/
The C* Audio Plugin Suite reincarnates as version 0.4.0.
CAPS is a collection of LADSPA plugins enjoying worldwide favour for
its instrument amplifier emulation. In addition, it provides a
sizeable assortment of acclaimed audio DSP units, sound generators and
effects. CAPS is distributed as open source under the terms of the
GNU Public License.
http://quitte.de/dsp/caps.htmlhttp://quitte.de/dsp/caps_0.4.0.tar.gz
This release sees the addition of the fine work of David Yeh at CCRMA
on the emulation of classic tube amplifier tone stack circuits (more
here: http://ccrma.stanford.edu/~dtyeh/tonestack/ ).
Three new plugins are building on the tone stack: ToneStack and
ToneStackLT offer isolated implementations, while the new AmpVTS unit
combines a refined AmpV and a ToneStack circuit. I'm very grateful to
David for his brilliant contribution, and I'm quite positive that
those who actively use the CAPS Amps will share this sentiment.
Also primarily aimed at the discerning guitarist is the new AutoWah
plugin, offering a versatile rendition of this classic audio effect.
The last new plugin is Eq2x2, a two-channel 10-band graphic equalizer
modeled after an analogue design.
-*-
Beyond the new plugins, this release also brings tons of major
improvements "under the hood". All plugins have been hardened to work
glitch-free in the face of invalid control input. Much effort has
also been spent on further elimination of denormal numbers everywhere.
Parameter smoothing (which is performed in order to prevent zipper
noise) has been refined never to occur at the start of processing.
The build process can now be configured to take advantage of the SSE
and SSE3 extensions on the i686 platform, providing slight performance
gains and automatic denormal protection. The HTML documentation has
been thoroughly updated to reflect all changes. Finally, thanks to
Paul Winkler CAPS now comes with an improved RDF file containing
plugin categorisation.
For the near-complete list of changes please see
http://quitte.de/dsp/caps.html#Changelog
-*-
Don't hesitate to let me know what you think.
Enjoy, and thank you for using CAPS,
Tim
Fellow LADSPA developers,
I've been investigating curious bug reports concerning the use of some
of the CAPS plugins in Ardour.
Most notably, the Eq plugin, a 10-band graphic eq, very often consumes
an inordinate amount of CPU cycles and more likely than not even
produces a silent output signal (or even worse one containing only
samples of inf value).
[I'm talking about Ardour/GTK 0.99.3 (built using 1.4.1 with libardour
0.908.2 and GCC version 4.1.2 20061007 (prerelease) (Debian 4.1.1-16)
and CAPS up to and including 0.3.0]
Even after eliminating each and every possible cause of denormal
numbers in the Eq plugin, the problem persisted. It turns out that it
is quite simply caused by invalid control parameter values.
In order to prevent zipper noise, the Eq unit (like most of the CAPS
plugins) smoothens control parameter input. This is done by sweeping
internal parameters over the duration of an audio block in run() or
run_adding().
In order to prevent an involuntary parameter sweep during the first
call to the plugin's run() after it has been activate()d, the plugin
has to evaluate the current set of control input parameters in
activate(). To prevent problems with unconnected ports, in CAPS an
unconnected port points to the lower bound of that port's range.
Thus, if a host calls activate() before doing connect_port() on all
control inputs, an involuntary parameter sweep is very likely, but at
least it's not starting from garbage parameters.
Now, Ardour will first call connect_port() and then activate(), just
as you'd expect from a well-mannered host (and as is recommended by
ladspa.h).
However, when Ardour calls activate(), the control inputs point at
uninitialized memory (ie. garbage data). A plugin with 10 control
inputs like Eq thus stands a fair chance of running into a value of
nan or inf, causing all sorts of computational mayhem including the
problems described above.
So what to do about this? ladspa.h says nothing about the value of
control inputs at plugin activation time. What it does say is that
plugins should be able to operate on invalid input data without a
glitch, and I'm working on making CAPS resolve the issue gracefully.
But still, if control inputs are unconnected or point to a value out
of bounds, nan or inf at activation time, a plugin cannot perform
correct parameter smoothing. Which would be a loss, no?
So, dear LADSPA host authors, estimated Ardour developers, I'd like to
ask you to make sure your implementation provides plugins with valid
and useful control input data at activation time, preferably the
values intended to be used at run() time.
Cheers, Tim
PS: It'd be nice to see a recommendation to this effect in ladspa.h,
too.
> Since LADSPA does not specifiy that control values are valid at
> activate(), either
As a host developer, I'd like to explain why control values are not
valid at activate().
Imagine a modular plugin system which allows chaining of control
signals. Assume all plugins are activated before any is run...
[A]-->[B]->
'A's control outputs might depend on it's audio input. i.e. 'A' can't
send control signals until run() is called.
Given that, 'B's input ports can't ever be valid during activate.
Best to not access control values during activate. Perhaps helpful if
hosts never provide them... to encourage plugin developers to write
robust code ;)
Jeff
On Thursday, 14 June 2007 00:41, pete shorthose wrote:
> On Thu, 2007-06-14 at 00:42 +0300, Hannu Savolainen wrote:
> > Hi folks,
> >
> > Now it has happened. Open Sound System is finally open sourced.
>
> http://4front-tech.com/hannublog/?p=5
Quote1:
"However the ALSA API is still almost completely undocumented
(after three years of it’s release) so how can anybody expect
that programmers could develop good applications based on it."
Quote2:
"For the above reasons the benefits of OSS are widely ignored:
[...]
* It’s fully documented (OTOH some parts of the documentation
are still under construction)."
Yeah. The ALSA API is also fully documented, but some parts are still in a
work in progress state...
What happened to MIDI/sequencer?
http://4front-tech.com/hannublog/?p=6
Quote3:
"The real problems started few months after that when I tried to
document the sequencer/music interface. [...] Due to lack of
time I gave up but promised to write the documentation later."
Quote4:
"The bad news is that there is no MIDI support in OSS 4.0. There
are few bugs in the MIDI code and we decided to ship OSS 4.0
without it [...] MIDI support will be included in OSS 4.1
(hopefully within this year)."
OK, lets talk about MIDI after some months.
Regards,
Pedro
Traverso 0.40.0 Release Announcement
The Traverso development team is pleased to announce the release of Traverso
0.40.0
Traverso is a cross platform multitrack audio recording and editing suite with
a clean and innovative interface targeted for home and professional use.
Changes in this release:
* Completely revamped User Interface, with many usability enhancements which
is fully themeable.
* Improved input event handler, with many new options
* CD TOC creation, with integrated CD Burning facilities.
* Support for LV2 plugins
* Reduced memory footprint for large projects
* Ported to Windows and Mac OS X
* Command Plugin framework: Extend Traverso's functionality by writing new
Commands.
Source tarball and installers for Linux, Mac OS X and Windows are available
at:
http://traverso-daw.org/
Enjoy!
The Traverso team.
Christian <krampenschiesser@email-addr-hidden> wrote:
> Thanks!
> This is what I meant, but this control is useless for me.
> But I found a way to create this in GIMP.
> I made a circle and cutted it to a controller. Now I could select
> small
> parts of it and set all black colors to red( with
> scriptfu->colors->color convert ).
> It was a lot of work, but worthy!
> so this is what I use right now:
> http://www.krampenschiesser.de/screenshots/ksdrumgui.jpg
just to be clear, phat uses the rendered output of my animated
version of Thorsten Wilms' knob mesh. (i had no creative
input at all, i just made Thorsten's mesh move)
blender creates a sequence of knob sized frames (with an alpha
channel, should that be desired) then, the image magick tool
"convert" is used (eg "convert +append output.png *.png" to
concatenate the frames into a large single image which can be easily
loaded and manipulated programatically.
(as is done in the phat knob and numerous other pixmap knobs derived
from the galan C code)
the method is independent of the code you use so there's no
reason why it shouldn't be useful to you. in fact, it's so simple
that i've duplicated your red knob design. see here for the
blender (.blend) file:
http://www.zenadsl6252.zen.co.uk/flat-red-100-frames.blend
and here for the output:
http://www.zenadsl6252.zen.co.uk/flat-red-100-frames.png
it's trivial to change the number of frames, the colours used or
the frame size and re-render it. you can also adjust the output filter
to sharpen or soften the edges.
i must admit though, that with a minimal design like this, you might
do well to implement it algorithmically with drawing operations.
then you can make run time changes to the appearance.
if you want something more complex or tactile then you could use
Thorsten's knob animation or give me a shout and i'll knock something
out to your specs. (although, bear in mind that my blender skills are
somewhat limited so it won't be a work of art =)
pete.
Hi folks,
Now it has happened. Open Sound System is finally open sourced.
Source downloads are available from http://developer.opensound.com/sources
The actual announcement follows.
Best regards,
Hannu
------------------------------------------------------------------
FOR IMMEDIATE RELEASE
4FRONT TECHNOLOGIES RELEASES THE SOURCE CODE FOR OPEN SOUND SYSTEM
CULVER CITY, CA, June 14, 2007: 4Front Technologies is proud to announce
the release of the source code to Open Sound System (OSS) v4.0. The
software currently runs on Linux, Solaris™, SCO UnixWare™ and FreeBSD
platforms.
OSS is a cross platform API that provides drivers for most consumer and
professional audio devices for UNIX® and POSIX based operating systems,
including Linux. Owing to its open architecture, applications developed
on one supporting operating system platform can be easily recompiled on
any other platform.
Licensing Models:
Open Sound System source code is now available under 3 licenses:
· GNU Public License (GPL) version 2
· Common Development and Distribution License (CDDL) for all operating
systems that have full source code available under the BSD or CDDL licenses.
· 4Front’s commercial license for using Open Sound incompatible with
open source licenses listed above. Commercial licenses are also
available for entities not wishing to use Open Sound System under any of
the above open source licenses
What is being open sourced?
The source code includes drivers for most consumer PCI and USB audio
devices and operating system support, including binary package
generation and sample test programs. Complete documentation and API
specification is also being made available to the open source community.
A device driver kit (DDK) is also available for developers to implement
cross platform device drivers for audio hardware. This eliminates lot of
redundant work that has traditionally been required to support any
hardware under multiple Unix/POSIX operating systems.
Reasons for going Open Source:
OSS has been an open API specification with multiple implementations by
independent developer communities. This has caused problems for
application designers because there are minor differences between the
implementations. The new open source community development model makes
it possible to replace the obsolete and incompatible vendor specific
sound subsystems and OSS implementations with a state-of-the-art
implementation developed by 4Front Technologies. The goal has always
been to standardize audio under POSIX compliant systems and this
includes real time operating systems and embedded systems as well.
"We are open sourcing OSS because this provides a great opportunity for
different communities to work together to provide wider audio hardware
support for all operating systems." said Hannu Savolainen, CTO and chief
architect of Open Sound System.
Industry Reaction:
"It's great to see 4Front releasing OSS under the Common Development and
Distribution License (CDDL). It's something the OpenSolaris™community
welcomes, and it provides an opportunity to improve sound support for
all OpenSolaris™ distributions," says Stephen Lau, OpenSolaris™ board
member.
"Fluendo is excited to see the open source release of 4Front
Technologies advanced OSS implementation for UNIX® and Linux. Getting a
unified and advanced sound system across all major UNIX® and Linux
variants will be a big advantage for developers. We look forward to
working together with 4Front Technologies to make sure the GStreamer
multimedia framework and the Open Sound System integrates perfectly with
each other", says Fluendo Business Development Manager Christian F.K.
Schaller.
"With a long history of successful collaboration with 4Front, Creative
looks forward to working with the Open Sound System community in
ensuring that Creative Sound Blaster Live! and Sound Blaster Audigy
sound cards have stable and well-supported drivers on Linux, Solaris and
BSD. The open source release of Open Sound certainly helps our goal in
providing cross-platform support for our products," said George Thorn,
director of digital media relations
for Creative Labs.
Community Portal
A new web site with source code, API specs and forums for the developer
community has been opened at http://developer.opensound.com
<http://developer.opensound.com/>. For more information and to download
the binary distributions of Open Sound System, visit 4Front's WWW site
at http://www.opensound.com <http://www.opensound.com/>.
--- xxx ---
All trademarks and copyrights belong to their respective owners.
UNIX is a registered trademark in the United States and other countries,
exclusively licensed through X/Open Company, Ltd.
Sun, Solaris, OpenSolaris, Sun Microsystems and The Network Is The
Computer are trademarks or registered trademarks of Sun Microsystems,
Inc. in the United States and other countries.
Open Sound System is a trademark of 4Front Technologies.
Copyright (C) 1996-2007, 4Front Technologies, All Rights Reserved.
Contact: Dev Mazumdar
4Front Technologies
4035 Lafayette Place, Unit F
Culver City, CA 90232
USA.
Tel: (310) 202 8530 E-mail: info(a)opensound.com <mailto:info@opensound.com>
Fax: (310) 202 0486 Web: http://www.opensound.com
<http://www.opensound.com/>
Dear colleagues,
I got in touch with people from teh Institute for Solar and Terrestrial
Physics from Irkutsk, Russia who wrote audio codec.
Please check site www.true-audio.com
Developers from that institute are willing to cooperate with a variety of
Linux audio users and developers who are willing to work further on the
development of that codec, testing and dissemination.
please contact me if you are willing to join that effort and if you can see
place of that codec iin your applications, hardware, projects.
With best wishes,
Vedran Vucic
Linux Center
http://www.gnulinuxcentar.org