Linux-audio-dev June 2004

linux-audio-dev@lists.linuxaudio.org

99 participants
93 discussions

[linux-audio-dev] errors building midishare

by Ciccolella Lazzaro Nicolò

hi, for being able to try the linux port of mythical ircams "open music" I trying to compile from source (CVS) the grams "midishare" unfortunately, with some build errors. My box: slackware 9.1/current, kernel 2.6.6, gcc 3.3.3 every aid is a lot appreciated Lazzaro Follow the errors: make[1]: Entering directory `/opt/sources/midi/midishare/linux-dev/midishare-linux/linux/kernel' gcc -O6 -Wall -D_LOOSE_KERNEL_NAMES -DMODVERSIONS -D__Pentium__ -DCONFIG_KERNELD -DMODULE -D__KERNEL__ -DLINUX -I/lib/mod ules/`uname -r`/build/include/ -I../../common/Headers -c -o msLoader.o msLoader.c In file included from /lib/modules/2.6.6/build/include/asm/processor.h:18, from /lib/modules/2.6.6/build/include/asm/thread_info.h:16, from /lib/modules/2.6.6/build/include/linux/thread_info.h:21, from /lib/modules/2.6.6/build/include/linux/spinlock.h:12, from /lib/modules/2.6.6/build/include/linux/capability.h:45, from /lib/modules/2.6.6/build/include/linux/sched.h:7, from /lib/modules/2.6.6/build/include/linux/module.h:10, from msLoader.c:41: /lib/modules/2.6.6/build/include/asm/system.h: In function `__set_64bit_var': /lib/modules/2.6.6/build/include/asm/system.h:193: warning: dereferencing type-punned pointer will break strict-aliasing r ules /lib/modules/2.6.6/build/include/asm/system.h:193: warning: dereferencing type-punned pointer will break strict-aliasing r ules msLoader.c: In function `prnt': msLoader.c:79: error: structure has no member named `tty' msLoader.c:84: error: request for member `write' in something not a structure or union msLoader.c:85: error: request for member `write' in something not a structure or union msLoader.c: In function `MidiReset': msLoader.c:130: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at /lib/modules/2.6.6/build/include/linux/module.h:51 3) msLoader.c: In function `myopen': msLoader.c:141: warning: `MOD_INC_USE_COUNT' is deprecated (declared at /lib/modules/2.6.6/build/include/linux/module.h:50 1) msLoader.c: In function `myclose': msLoader.c:150: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at /lib/modules/2.6.6/build/include/linux/module.h:51 3) make[1]: *** [msLoader.o] Error 1 make[1]: Leaving directory `/opt/sources/midi/midishare/linux-dev/midishare-linux/linux/kernel' make: *** [kernel] Error 2

19 years, 9 months

[linux-audio-dev] Traps in floating point code

by Erik de Castro Lopo

Hi all, People who play around with floating point code (especially on x86) quickly learn about the evils of comparing the equality of one floating point value with another. There are other related evils with floating point one of which I was bitten by just recently and I thought I'd share it with y'all. If it helps just one person from spending 20 odd hours chasing an elusive bug like I did, I will have acheived something. The evil I speak of is the difference between 32 and 64 bit floating point representations (types float and double) and the x86 CPU's internal 80 bit representation. The most common trap is something like: if (x == y) do_something (); where x and y are say double flotaing point numbers. Also lets just say that the value of x is already in the CPU's FPU register as a result of a previous operation and the other y, is not. What happens is that the result of the previous operation can have a full 80 bits (part mantissa, part exponent and a sign bit) of precision while y, loaded from memory does not have this extra precision. The comparison therefore fails, even though when printed out (or when compiler optimisation is switched off) the two values are equal. This is the reason why the above if statement is better written as: if (fabs (x - y) < 1e-20) do_something (); The reason I am writing this email is that I was recently bitten by a similar problem. I was keeping a running index into a table, and keeping the integer part separate from the fractional part which was kept in a double floating point: double fractional = 0.0, increment = 0.1; int integer = 0; for (;;) { /* Bunch of other code. */ fractional += increment ; integer += lrint (floor (fractional)); fractional -= floor (fractional); } The above code can produce very odd results for certain values of increment. The problem in this case manifested itself in the integer/fractional losing counts when compiled with gcc-3.4 while the same code had worked perfectly with previous versions of the compiler. The problem seems to be caused by the fact that the other code in the loop was pushing at least some of the relevant values out of the FPU stack into double floating point variables and that when they were reloaded they had lost precision. The fix in this case was this: for (;;) { /* Bunch of other code. */ fractional += increment ; rem = fmod (fractional, 1.0); /* floating point modulus */ integer += lrint (round (fractional - rem)); fractional = rem; } which is far more robust. HTH, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "The X-files is too optimistic. The truth is not out there." -- Anthony Ord

19 years, 9 months

[linux-audio-dev] Linux Audio Blog (continued)

by Jan Weil

Greetings Linux Audio world, the Linux Audio Blog has its own subdomain now. Please find it at http://linuxaudioblog.jawebada.de The RSS feed is available at http://linuxaudioblog.jawebada.de/index.rss While the old links are still valid I'm planning to restructure the rest of my site somewhen in the future. Please update your bookmarks and your feed aggregator's configuration. Contributors are welcome! You can easily contribute to the Linux Audio Blog via an email gateway now (i. e. you *do not* need yet another account). If you are interested please read http://linuxaudioblog.jawebada.de/about/how_to_contribute_to_the_linux_audi… and http://www.jawebada.de/index.cgi/blog/software/autoformat.html Send me an email and I will add you to the list of known posters. Happy coding Jan -- Jan Weil The Linux Audio Blog: http://linuxaudioblog.jawebada.de

19 years, 10 months

[linux-audio-dev] writing gig files (was: giga files and large soundfonts)

by Christian Schoenebeck

Es geschah am Mittwoch, 30. Juni 2004 15:59 als James Stone schrieb: > I was wondering if anyone has any knowledge about generating giga or akai > compatible files? You know we discussed that several times on the LinuxSampler list. At the moment libgig is only capable to read, not to write gigs. Extending libgig with write support would probably take me a week, so it's not that much. But I would only do so if there are people who are definitely willing to develop an instrument editor for the Giga format or extend an existing one. The Giga format is more powerful than the Akai format, so I would definitely prefer that instead of Akai, but the Giga format has some drawbacks: * most important it's based on RIFF, thus it has (officially) a file size limit of 4GB * it's proprietary * it has many relicts in the format which are simply unused nowadays, means there are dirty redundancies * it's binary only, so you can't easily adjust articulation informations with a simple ASCII editor * the unknown fields in the format = relicts (which aren't necessary to know about when you just read the gig) might cause that the original Gigasampler to not accept the patch file anymore after editing / creating it or at least could cost us some time til it actually accepts it. So like with any proprietary format, at the moment I simply can't guarantee that it will also work right away with the original Gigasampler (I'm quite optimistic though) That's why we came to the decision that it might be better to define our own sampler patch file format (maybe XML based) before we implement write support e.g. for the Giga format. What are your opinions? CU Christian

19 years, 10 months

[linux-audio-dev] ardour 0.9beta17.1 released

by Paul Davis

"Less SNAFU's, Less bytes, More Features" This release is more or less identical to yesterdays 0.9beta17, but its only about 3MB instead of 35MB+, and looping while running in sync with JACK is sort-of working. Packagers please take note. Next release expected in less than 8 days but more than 5, and it will hopefully contain the last of the major bug fixes and redesigns before 0.9 is released. --p

19 years, 10 months

[linux-audio-dev] ardour 0.9beta17 botch up

by Paul Davis

something went wrong with "make dist" and the file that was uploaded was abnormally large. it will be corrected around lunchtime (EST) today. sorry for the confusion.

19 years, 10 months

[linux-audio-dev] Ardour 0.9beta17 is 38 Megs????

by J_Zar

Sorry for the wrong (maybe) post... Trying the Ardour download of beta 17 I noticed 38.6 Mb of source code while nightly tarball is 1.7 Megs... Some package error maybe or all is ok??? I don't think autoconf/automake script generation will require 36 Mb.... Cheers, -- J_Zar Gianluca Romanin ---------------- see you at OpenJay.Org

19 years, 10 months

[linux-audio-dev] Knobs / widget design

by Thorsten Wilms

Hi! With the recent talk about plugin guis and stuff I think it's well fitting to present a knob design experiment I created for a LDrum redesign. SVG vector graphics (prefered by Peter and me) http://wrstud.uni-wuppertal.de/~ka0394/forum/04-05-02_knobs_02.png 3d rendering variatios http://wrstud.uni-wuppertal.de/~ka0394/forum/04-05-02_knob_3d_1-2-3.jpg Please see this as exemplaric, not finished work. The basic idea is to combine graphical clearness (Abletone Live ...) with enough plasticity to make it look 'touchable'. And generaly about knobs: If you ask me, radial is the only right way of mouse control for knobs. Gives the special advantage that you can have large value changes with small pointer movement close to the knob, or more precision if you move the pointer away. Not to forget that a knob says 'turn me'. Requiring linear movement then means telling one thing while meaning something else (bad communication practice). --- Thorsten Wilms

19 years, 10 months

[linux-audio-dev] JackMix 0.0.3

by Arnold Krille

Hi all, as I had some time at LinuxTag, at least in the train-travels, I managed to work a little further on JackMix. The result is another (test-)release: JackMix v0.0.3 Get it from http://roederberg.dyndns.org/~arnold/jackmix/ Have a nice day, Arnold -- Get my public-key from pgp.mit.edu or pgp.uni-mainz.de --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a rm / -rf. Or ask your administrator to do so...

19 years, 10 months

Re: [linux-audio-dev] swh plugins and fixing undenormalize

by eviltwin69＠cableone.net

I have a denormal fix without a branch but you probably don't want to see it ;-) It's pretty simple, just OR the bits of the exponent together which gives either 0 (denormal) or 1, typecast that to float, and then multiply the original float by that (0.0 or 1.0). Voila, no branch, but it is messy looking ;-) Jan On Thu, 24 Jun 2004 11:03 , Tim Blechmann <TimBlechmann(a)gmx.net> sent: >> Since the problem is denormalised numbers, has anybody thought of >> adding a small DC offset (1e-15) or alternating the >> addition/subraction of a small value? >of course it is possible to add a small dc offset ... but what if we are >working in a feedback loop? or even worse with a high pass filter? >if you alter addition/substraction and send it throuth a low pass filer? >the denormal problem is not a trivial one, but afaik a macro like this >is the only one working for sure... > >cheers .... tim > >-- >TimBlechmann(a)gmx.de','','','')">TimBlechmann(a)gmx.de ICQ: 96771783 > >After one look at this planet any visitor from outer space >would say "I want to see the manager."

19 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev June 2004