Folderol wrote:
>On Sat, 3 Feb 2007 01:01:18 -0500 (EST)
>Larry Troxler <lt(a)westnet.com> wrote:
>
>>yn isn't RT safe? Could you elaborate or point to a link? I remember
>>reading something about this, and was hoping to use it for live
>>performance.
>>
>>
>I have heard several comments to this effect, and also that the code
>in Zyn is 'a nightmare' however I have not heard anything specific that
>one can really get a handle on.
>
>While I agree the GUI is poor and could do with quite a lot of work, I
>don't know about the rest, although there are changes I would like in
>the way voice banks are managed.
>
>This all causes me quite a lot of concern. I find that Zyn gives
>unparallelled results, and conceptually most closely matches my grasp
>of sound. I am concerned about talk of unspecified jack problems, and
>also the lack of any visible development by the originator.
>
>
Zyn will occasionally just pop itself out of the JACK graph, I'm not
sure why. Paul Nasca had talked about upgrading Zyn's JACK support, but
I don't think he ever got around to it.
Personally I don't mind the GUI. Zyn is a rather "deep" synth, I
certainly wouldn't want to see all of its controls in one panel or even
two. However, I will agree that its interface design does make it
problematic to program. Fortunately its included sounds work beautifully
for my purposes.
Finally though, Zyn is open-source and GPL'd, so whoever wants to pick
up the torch is more than welcome to do so. I have no idea how its code
looks, and I'm not likely to make the effort to find out (IANALAD), but
surely there's a fledgling (or not-so-fledgling) Linux audio developer
out there who wants to make a significant contribution to the Linux
audio workplace ? A stable JACKified Zyn seems to rank highly on users'
wish-lists.
>I, personally, would be willing to expend a great deal of effort to
>help revive Zyn, and would be quite happy to put my hand in my
>pocket as well.
>
>
Developers, are you listening ? The man is offering his time *and* his
money. And are any other users out there who are willing to pony up some
dough for a bounty on this item ? (Assuming of course that the task is
actually do-able within a reasonable time).
Synth development in Linux has seen a severe slowdown over the past year
or so. We need things like stabilized Zyn, Om (or whatever DR wants to
call it these days), and AMS. Or does everyone plan on waiting for
better VSTi support ?
Best,
dp
hallo,
supose i´ve opened a sound with the wave module:
>>> import wave
>>> sound=wave.open(filename,'rb')
now this is strange:
>>> sound.getnframes() != len(sound.readframes(sound.getnframes())
True
Why so?
thanks in advance,
Claire
taken from http://www.arnoldarts.de/drupal/?q=node/532 :
"One step back, two ahead!"
After almost two years of silence I managed to put together a new
release of JackMix. The name explained: Comparing to jackmix:0.1.0
some experimental features are dropped. On the other hand this release
is the first to use scons for the buildsystem and qt4 for the toolkit.
Download and installation
Download the source here:
http://www.arnoldarts.de/drupal/files/downloads/jackmix/jackmix-0.2.tar.gz
After unpacking (tar xzf jackmix-0.2.tar.gz && cd jackmix-0.2) call
QTDIR=<path to your qt4-dir> scons configure to configure and
afterwards call scons to compile the app. Calling scons install will
install the binary in the chosen bin-directory but you will probably
test JackMix before doing that...
If your qt4 is installed in /usr/include/qt4 and /usr/lib/qt4 (as it
is on gentoo) you need to add qtlibs=/usr/lib/qt4 to the
configuration-command above. I will probably change/extend the
qt-check in the future but for now this has to be used.
Usage
Be sure to have a jackd running, preferable via qjackctl which also
has a nice window to connect inputs and outputs like the back of your
rack.
Next start jackmix. If all is well it will present you with a top-row
of controls, a big matrix in the middle and some controls on the
right. The top controls are the input gain, the right controls are
output gain. The matrix in the middle controls the levels sent from
the various inputs to the outputs.
If you are tired of the simple potis for each channel and want easier
mixing into stereo busses there is help available. Just select the
potis you want replaced by using "Select" from the context menu of
each control and then use "Replace" in the top-left control you want
replaced. If all is working JackMix will choose the biggest possible
replacing control (current available controls are mono-to-mono,
mono-to-stereo and stereo-to-stereo). You can fill the empty places
from the "Edit"-menu.
Adding and removing of input- and output-channels is also done from
the "Edit"-menu.
Please note that if no jackd is running, JackMix will start but not
show any controls. You can tell JackMix to create new channels, but
nothing will happen. Restart JackMix after starting jackd and go on
with your work.
Changelog
Changes since 0.1:
-Using scons instead of autotools/make.
-Using qt4 instead of qt3.
-Dropped the potis borrowed from the kde-project. They where hard to
port to qt4 and the ones from qjackctl are much nicer and where easier
to port.
- The ability to connect faders is dropped. For future releases this
will be replaced by VCA-groups similar to bigger mixing-consoles.
Have a nice week,
Arnold
--
visit http://www.arnoldarts.de/
---
Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich
verhindern könnte, würde ich mir noch heute einen Stapel Brenner und
einen Sack Rohlinge kaufen.
The authors are proud to announce the release of Aqualung 0.9beta7.
Aqualung is an advanced music player originally targeted at GNU/Linux,
today also running on other operating systems such as FreeBSD and
MS Windows. We are striving to create one of the finest music players
available, with respect to sound quality, stability, features and
ease of use.
This release is the latest in a series of beta releases on our way to
the future stable release of Aqualung 1.0. It adds significant new
functionality as well as important bugfixes.
The ChangeLog for this release is listed below.
Homepage: http://aqualung.sf.net
Enjoy,
Tom
2007-02-05 Tom Szilagyi <tszilagyi at users dot sourceforge dot net>
* Aqualung 0.9beta7
http://aqualung.sf.net
This release introduces important new features and bugfixes.
Main reasons for upgrading:
* CD Audio support, complete with CDDB, CD-Text, etc. You can play
Audio CDs directly, or rip them to WAV, FLAC, Ogg Vorbis or MP3
(CBR/VBR, gapless via LAME) complete with tagging, on the fly.
* Revamped Music Store Builder: better operation, greater flexibility.
* Support FFmpeg library enabling the recognition of numerous formats
e.g. AC3, AAC, WMA, WavPack, and the soundtrack of many video files.
* Replaygain support for APEv2 tags.
* Ability to set looping range when looping a single file. Should be
useful for people playing along a recording, trying to learn phrases
of a song.
* Adding music to the playlist is now a non-blocking, interruptible
background operation.
* Drag-and-drop files from external sources (Nautilus, Konqueror, etc)
into the Aqualung playlist.
* Several critical memory leak fixes.
* Numerous GUI refinements; fixed some rare bugs in engine, too.
* Support for building against the new FLAC 1.1.3 API.
* Aqualung operates correctly on bigendian systems (32 and 64 bit).
* Running natively on MS Windows. A port of TAP-plugins is included
in the installer. See http://aqualung.sf.net/win32 for more.
NEW LIBRARY DEPENDENCIES:
All of these are optional; Aqualung will build without them,
disabling the functionality they provide.
* libcdio >= 0.76 is required for CD audio support.
http://www.gnu.org/software/libcdio/
* libvorbisenc for ripping into Ogg Vorbis.
http://www.xiph.org/ogg/vorbis/
* libmp3lame for ripping into MP3.
http://lame.sourceforge.net/
Hi everyone,
I'm pleased to announce the release Tranches and Tapeutape.
(my first release !!! )
Tapeutape is a midi-controlled virtual sampler.It is highly
configurable,lets you create instruments/kits/setups and is designed for
live performance.It works on Gnu/Linux with the jack sound server.
There's a command-line and a gui version.
It can be found at http://www.hitmuri.com/Tapeutape
An example of what can be done with it :
http://www.hitmuri.com/Tapeutape/demo_tapeutape.ogg
Tranches is a midi-controlled multi-(inputs|outputs) live beat
repeat|redirect tool for the jack sound server on Gnu/Linux !!! There's
a command-line and a gui version.
website : http://hitmuri.com/Tranches/
audio example : http://www.hitmuri.com/Tranches/demo_tranches.ogg
Regards,
Flo
Which algorithm/library/program is used for sample rate conversion by
cdrecord in Linux? Other programs? I assume there is a library to
perform this function, which is used by most utilities, xmms, amarok,
cdrecord, audacity, etc. Is there any easy way to find this out?
I have just done a simple test burning some sound recorded as a WAV file
at 48,000 Hz to a CD (at 44,100 Hz of course), and think I have noticed
a small reduction in quality.
Thanks - jon
> On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote:
> Further to that, something constructive: perhaps you could try telling
> your customers why *you* chose linux, rather than trying to find reasons
> to tell them *they* should.
My reasons, from back in about 2000, were "cost" and "interesting".
First off the license costs were not hard to sell. And secondly that I
personally wanted to program in Linux. I thought it would be interesting
--- and it has been fun. Also the company was kind of a crapshoot and I
wanted the professional experience on my resume if I needed to go get
another job. Embedded Linux sounded good to me.
I want to stick with Linux and hoped there were some measurable
performance differences to tout. Sounds like there aren't, really.
And now for some more kind of Dilbert-esque background for the curious...
A couple of years ago, we tried answering this question by measuring the
time between a midi impulse on a rigged midi cable and audio output on
an oscilloscope. We tested Receptor vs Windows 2000 running VStack. The
Receptor was not more responsive but was less jittery in its reponse.
We engineers didn't feel that the results were carefully enough
generated to be publicly announced, but we felt that our hunch was being
confirmed.
Then I made some perhaps loose comments about how Linux is less bloated
than Windows. True, but not quantifiable.
Then there is the general (and vague) perception among many in the music
biz that Windows is not for pro audio.
All of these factors led our non-tech people here to start saying that
our OS was better. Being an engineer, and not being able to quantify
"better", I would cringe when they would say that and qualify endlessly.
But I also couldn't prove anything either way, so I kind of left it.
As time has passed, I have found that I was naive about the costs of
Wine (VST compatibility, Linux (hardware compatibility, especially USB
and firewire audio/midi devices) and the costs of getting programmers
productive on Linux as a development platform.
Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA
drive support and our Wine is getting old (vinegar? %). Our code could
do Windows pretty easily. Should I push for that, or move to a newer Linux?
There you have it. Life in the software business.
By the way, I appreciate all of the comments. I expected it might be a
loaded question! ... mo
> "Frank Smith" <frsmith(a)gmail.com>
> Nice point and this is the strength of OS. the problems are addressed
> far quicker than in Prop' software.
Yes, that's good. Microsoft doesn't give a hoot about professional
audio. We can actually tweak the OS, and Wine, to improve performance of
our specific application.
We got an improvement of Wine's CRITICAL_SECTION implementation in
(using futexes) that helped DFH perform during heavy use of a particular
drum.
- mo
