There have been a few edits on our "deveopment"-wiki
apps-devel.linuxaudio.org !
sorry for the confusion:
http://apps.linuxaudio.org is the "real" site.
http://apps-devel.linuxaudio.org/ is our *test server* that we use to
experiment with PHP, plugins, designs, software updates, etc - it's
actually a 1:1 mirror, but not intended for the public. - we ought to
set up a jailed webserver behind openvpn for testing, but we're just not
there yet :(
robin
> a configuration option
Build configuration, or DSSI configure() ?
The latter would fix it, while (it seems?) the former
would mean distros having to choose between better
sound and project compatibility on behalf of their
users, which is not much of a choice.
If you do mean the latter, then your previous fix
seems better - a user can always choose to
downgrade, or a packager find creative ways to
provide both.
I suppose a packager could include libraries built both
with and without the option... but that's a
compatibility minefield (with other ad-hoc packages
from other distros).
Hoping you did mean DSSI configure,
Chris
Hi all,
If you're thinking of packaging hexter 0.6.0 for your
favorite distribution, please wait for version 0.6.1.
I've been talking with Anthony Green about his efforts
to package hexter 0.6.0 for Fedora, and it seems I made
a mistake.
hexter 0.6.0 can sound radically different from hexter 0.5.9,
depending on the patch used, and I didn't want anyone's
existing projects to break if they upgraded. So I changed
the way hexter 0.6.0 installs: it installs as hexter6.so, while
hexter 0.5.9 installs as hexter.so, so the two versions can
coexist.
This works well enough for people who install from source,
but Anthony pointed out that this makes things difficult for
people packaging hexter for distributions. For most distros,
when one upgrades, the old files are removed, meaning
hexter.so would disappear and existing projects would
break. Distros with something akin to Gentoo's SLOT
mechanism can have multiple versions installed
simultaneously, but the majority of hexter users will have
no need for anything but the latest version.
What I'm going to do with version 0.6.1 instead is make
it install as hexter.so, just like 0.5.x versions, and add
a configuration option which will optionally make it sound
like 0.5.9. Problem solved: existing projects can easily
be made to sound like they originally did, and everyone
can have the latest and greatest hexter installed.
Expect 0.6.1 sometime this coming week. Thanks,
Sean Bolton
*About:
Mammut will FFT your sound in one single gigantic analysis (no windows).
These spectral data, where the development in time is incorporated in
mysterious ways, may then be transformed by different algorithms prior to
resynthesis. An interesting aspect of Mammut is its completely
non-intuitive sound transformation approach.
*Homepage:
http://www.notam02.no/arkiv/doc/mammut/
*Screenshot:
http://www.notam02.no/arkiv/doc/mammut/mammut.png
Changes 0.57 -> 0.59
---------------------
-Added workaround for rare sound corruption bug.
-Added the "Redo it!" buttons. (The same as pressing "Undo" + "Do it!")
-If playing while pressing a "Do it!" or "Redo it!" button, continue
playing after processing as well.
-Added the "Random Phases" toggle button in the "Multiply Phase" dialog.
Checking this button will freeze the sound. Thanks to Tim Blechman for
the idea.
-Fixed looping which wasn't turned off if using a different sampling rate.
-Added "make install" and "make uninstall"
-Fixed animation bug. (should allways be shown now)
-Fixed a couple of more int->uint32 time variable cases. Hopefully, the
animation stuff shouldn't stall the machine anymore.
Hi everyone,
As I said yesterday when I said the migration to linuxaudio.org was
postponed till 1st April, there are still a few issues asking for
comments.
It has been suggested by a few people(Ivica Ico Bukvic, Jan Weil) that
the email addresses linux-audio-xxxxx(a)linuxaudio.org was kind of
redundant. The following suggestions were made :
¤ just switch the names to announce(a)linuxaudio.org,
dev(a)linuxaudio.org, and user(a)linuxaudio.org.
¤ Make aliases : linux-audio-dev(a)linuxaudio.org -> dev(a)linuxaudio.org
To this Leonard Ritter replied that this could lead to more spam.
IMO, since we are working on a spamassassin+mailman interfacing, it
should not be a problem. The aliases seem the solution that could make
everyone happy since both type of addresses would work and the lists
would keep their "historical" names.
Ready, steady... FLAME !
__________________
Marc-Olivier Barre,
Markinoko.
PS : please reply to both lists (I'll try to be swift on moderating
users that are not registered on both lists) so everyone can enjoy
your comments :-)
On 3/5/07, nescivi <nescivi(a)gmail.com> wrote:
> Hi Esben,
>
> Monday, March 5, 2007, 3:47:08 AM, you wrote:
>
> ES> It would be nice with some recording guidelines for LAC. Both for
> ES> video and for audio.
>
> ES> Maybe post a mail to linux-graphics-dev;).
>
> ES> I'm talking about issues such as telling the participants to use big
> ES> text on the slides. Maybe also, if the person is on the right side,
> ES> maybe a vector overlay could be done, cheaply.
>
> I will inform the authors.
> But also note, the slides will be available as pdf's from the LAC
> website as well. So there are readable versions of the slides
> available.
>
> ES> It's also wise to position the camera such that there is little
> ES> movement other than the speaker. This would save bandwidth and allow
> ES> us to use higher resolution. Also, to not move the camera is nice.
>
> ES> Also, to not allow questions from the audience without a microphone;).
>
> This we always try, but sometimes the questions are so burning that
> they can't wait for the microphone...
>
>
> ES> There are also many issues recording the speaker.
>
> Any tips are welcome.
> As far as I understood from Jörn there were some problems to multiplex
> the audio stream with the video stream, so they had to use the
> mic-input from the camera. If you know of a good solution where we can
> do the multiplexing with the audio stream from the mixing desk
> properly, then please share your experience!
>
> sincerely,
> Marije
Jörn is very welcome to raise the issues he has on this list.
Eventually someone will give a good hint ;-) I'm sure a lot of people
far away from berlin would like to be able to give a helpful hand.
And I would be surprised if there was no way to multiplex an audio stream...
Cheers,
__________________
Marc-Olivier Barre,
Markinoko.
New releases of JAAA and JAPA and the libraries they depend on
are now available at
<http://www.kokkinizita.net/linuxaudio/downloads>
jaaa-0.4.1: bugfixes.
japa-0.2.0: bugfixes, white and pink noise generators now built-in.
clalsadrv-1.2.1: bugfixes. This version should now work correctly with
ALSA's default multi-client device.
clxclient-3.3.2: bugfixes.
There are also some (essential) bugfixes to the HOA-NF filter
code.
--
FA
Lascia la spina, cogli la rosa.
Hi People,
On trying to deal with wave files in python, I came across this article:
http://209.85.165.104/search?q=cache:vMIuboZw0BwJ:scipy.mit.edu/tutorials/w…
the original pdf http://scipy.mit.edu/tutorials/wave.pdf is not available...
The signal scaling is just beyond my understandings, and I can´t find
any explanation on the web about it. What is the role of that in the
programm? Anyway, I will write here what it does to the audio signal
that I don´t understand. By catching code lines in functions it looks
like this:
''''
mono signal, a list, say a 200Hz sinusoid with 2 seconds):
signal=[math.sin(2*math.pi*200*(x/44100.0)) for x in range(88200)]
'''
tmp = list( signal )
min_tmp = min(tmp)
max_tmp = max(tmp)
scalar = (2**16 - 1.0) / (1.0 * (max_tmp - min_tmp)) * volume #for 16
bit, it could be 8 or 32
tmp = map( lambda x: int(scalar*(x-min_tmp)), tmp)
signal = tmp
if samp_width != 1:
signal = map( lambda x: x - 2**(samp_width*8 - 1), signal )
#and then they pack the code, conv_code is 'B' for 8 bit, 'h' for 16
bit, 'i' for 32 bit:
f.writeframes( struct.pack( conv_code, signal[i] ) )
Ok. This struct thing I don´t fully understand, but I already know it
has to do with C data strings.
But the previous part simply doesn´t make sense, and I can´t find any
reference to this things on the web.
I would really appreciate if anyone could explain me what is happening
and/or point me some writings about that.
One disturbuing thing about using this script is that sometimes it
outputs a wave file with start and end out of center (zero amplitude),
even when the singal list had fadings. It seems that it has to do with
signals that goes beyond the [-1,1] closed interval, but I don´t know
why.
thanks guys,
Claire
I normally wouldn't reply but this is way off. If there is prior art
then the patent can be thrown out. This is what PubPat is doing and
what was attempted with the Microsoft FAT patent (and succeeded in
Germany).
If Microsoft took out a patent on something that was implemented
previously in ALSA code but they did not steal the code from ALSA they
are not required to GPL anything. GPL is a license based on copyright.
As long as they don't copy the code they're not breaking any laws and,
unless someone can prove that they copied the code, they ar enot
required to reveal it.
Jan
On Fri, 2007-03-02 at 14:37 +0100, Nick Copeland wrote:
> If Microsoft patent any capabilities that are present in the ALSA codestream
> them ALSA itself is exempt from the patent. This is written into the patent
> laws, they cover the possibliity that somebody had a product that was later
> patented by some other, wiser party. If the company in potential infringment
> can prove prior implementation then they are exempt.
>
> The exact wording of the exemption would probably require legal
> interpretation, however if Microsoft have patents applied for that cover
> features already implemented by ALSA then not only are implementations of
> the ALSA driver exempt (prior implementation can be proven based on driver
> distribution dates to precede the patent application) but at the same time
> there is a seperate issue that if Microsoft did take out a patent of an ALSA
> capability then under the terms of the GPL they may legally be required to
> make their code publicly available as it arguably must have been based on
> the open sourced capabilities.
>
> Regards.
>
> >From: "Marc-Olivier Barre" <mobarre(a)gmail.com>
> >Reply-To: A list for linux audio users
> ><linux-audio-user(a)music.columbia.edu>
> >To: "Linux Audio Dev List" <linux-audio-dev(a)music.columbia.edu>,"A list for
> >linux audio users" <linux-audio-user(a)music.columbia.edu>
> >Subject: [linux-audio-user] Open letter to Steve Ballmer
> >Date: Fri, 2 Mar 2007 12:09:25 +0100
> >
> >Hi,
> >
> >Since Microsoft recent audio related patent "that looks a lot like
> >ALSA", I thought this could be interesting :
> >
> >http://www.showusthecode.com/
> >
> >In short it's an open letter to Steve Ballmer asking him to show the
> >code and patents that Linux supposedly copied from Microsoft (haha,
> >what a joke...)
> >
> >Happy reading,
> >__________________
> >Marc-Olivier Barre,
> >Markinoko.
>
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
--
Jan 'Evil Twin' Depner
http://myweb.cableone.net/eviltwin69
"Life should NOT be a journey to the grave with the intention of
arriving safely in an attractive and well preserved body, but rather to
skid in sideways, chardonnay in one hand, chocolate in the other, body
thoroughly used up, totally worn out, and screaming 'WOO HOO, what a ride'"
Announcing a new release of the hexter DSSI plugin.
http://sourceforge.net/project/showfiles.php?
group_id=104230&package_id=134428
hexter is a software synthesizer that models the sound generation of
a Yamaha DX7 synthesizer. It can easily load most DX7 patch bank
files, accept patch editing commands via MIDI sys-ex messages, and
recreate the sound of the DX7 with greater accuracy than any other
open-source emulation (that the author is aware of...) hexter
operates as a plugin for the Disposable Soft Synth Interface (DSSI).
New features in version 0.6.0 include:
* Implemented the LFO, amplitude modulation and pitch modulation
(many thanks to Jamie Bullock)!
* Added TX7-style performance parameters, allowing configuration
from the GUI of pitch bend range, portamento time, and
sensitivity and assignment of the modulation wheel, foot
controller, pressure (both channel and key), and breath
controller.
* Added DX7 patchbank loading code from Martin Tarenskeen, allowing
hexter to load a number of additional patch file formats.
* Partially implemented portamento. For now, the curves and times
are wrong, but the plumbing is there.
More information about hexter and DSSI can be found at:
http://dssi.sourceforge.net/hexter.html
hexter is written by Sean Bolton, and copyright (c)2007 under
the GNU General Public License, version 2 or later.