Hi
I just installed kernel 2.6.0-test3 on my laptop. I looked around in
/proc and saw all kinds of promissing things showing up there.
/var/log/messages even showed my Evolution USB keyboard. Very nice. But
since I'm fairly new to the kernel2.6.0/build-in-ALSA I'm hoping for
some pointers just to get started.
1) I didn't do any configuration of ALSA. Is that needed? If so how do I
do it now that ALSA is compiled in?
2) Where can I expect my devices to show up? For now I have an onboard
soundcard (i810) and the Evolution keyboard. I would like to route the
incomming midi to csound, but later also to either Muse or Rosegarden4.
Is that a matter of having the softsynth or sequencer read from
/dev/midi00 (or somthing like that)? And do I simply tell the sound
generating software to direct its output to the appropriate device, say
/dev/audio?
3) I noticed somethiing jack showing up. Is jack supported? If so, to
what extend?
4) What would be a nice program use for figuring out what midi-events
the knobs on the Evolution sends?
Hope some of you could find the time to either explain me a bit or send
me in direction of some useful documentation. Thanks in advance.
--
peace, love & harmony
Atte
Hi all
I believe this question is an old one, but can someone show me the best way to find the ideal size an number of audio buffers of my sound card.
I have read lot of web pages on this subject, but I didn't understand everything, although I use linux audio apps for years now. I always end trying one by one the values until I found an acceptable one (for example, the fluidsynth configuration). The problem is, each time I had to use another PC, I don't know how to quickly find this values.
I remember years ago, Cubase was testing the sound card to find the best values (something about ASIO drivers).
Is there a Linux app that can deduce this values?
regards
GuyCLO~
-----------------------------------------------
#219055 http://counter.li.org
-----------------------------------------------
http://perso.wanadoo.fr/guy.clotilde/index.html
-----------------------------------------------
Change your Linux PC in a Rythm Station with holborn's GMORGAN:
http://perso.wanadoo.fr/guy.clotilde/GMORGAN/index.html
-----------------------------------------------
Hello all,
I received the RME HDSP Digiface PCI card I'd ordered, but for some
reason they only sent (and charged me for) one of the two Frontier
Tango24 8-channel A/D-D/A convertors I'd requested. So, this got me
thinking "maybe I only need 8 channels of I/O, and can do the rest in
Ardour".
Many musician friends using Macs say they do most of their stuff in the
computer nowadays. One guy said he'd probably not even have a mixer,
just preamps, although how would you do headphone monitor mixes?
I was wondering what people's opinions are on this:
Should I get the other Tango24 while they're still going cheap,
or spend the 300 pounds elsewhere?
A long-term glint-in-the-eye idea was to one day get a CLM DB8000S:
http://www.clmdynamics.com/db8000_frame.htm
...8-channel M&S-mic-pre/limiter/A-D for input to the HDSP, so giving
16in/8out, or 24in/16out with a pair of Tango24s. But is this amount
of channels overkill for a project studio? I won't have even eight mics
for some time yet, although I will eventually need to be mixing lots of
recorded tracks.
I'm also wondering that mixing like this:
Ardour tracks--> D/A--> mixer+FX--> A/D--> Ardour--> D/A--> monitors
...seems rather convoluted; would it compromise quality or sync (comb
filter effects, etc.) to be adding the extra A/D conversions? But I
suppose that's how everyone records to ADAT machines with analogue
desks.
However, If I can do more stuff internally in Ardour, that's good.
Trouble with that is, that I would miss the hands-on twistability of
an analogue console where each channel's parameters are laid out for
the tweaking. Can Ardour be used to route FX sends out of one ADAT
channel directly to analogue outboard, then back in again?
I don't even have a mixer yet, nor proper monitors, although the recent
'how to build a studio' thread helped lots:
http://eca.cx/lau/2003/06/0170.html
What I'd really like is a simple fader box with 16 or 24 moving faders,
and little else, to save my mouse-miles when mixing. But all the control
surfaces I've seen are either way too complicated (with lock-in unfree
software) or don't have moving faders.
Any ideas without spending $20,000 on a digital desk?
Malc
Hi
News on v0.11
---------------------
This version, fix the problem appeared in v0.10 when compiles with older
versions of FLTK. Also the bug reading config file and other minor bugs has
been solved.
Small new edit functions and patterns has been added.
Availabe in:
http://personal.telefonica.terra.es/web/soudfontcombi/http://www.telefonica.net/web/soudfontcombi/
Thanks and sorry ...
Josep
>I dont think so...
>IMHO, reiserfs is slower than ext3
>I use it with rezound
I never said ext3 was slow :)
Both are fast, and your results may vary depending on what kernel and subsequent patches you have. Speeds for ext3 can vary depending on what mode (writeback, ordered, or journaled) you are using. Even though ext3 is very fast, reiserfs generally has better throughput and latency timings in my experience, which I personally find to be much more important than raw read/write times when working with audio.
-Reuben
I have a midiman uno usb device. I am not sure if I am using it
correctly or not. I compiled and installed ezusb2131 and usb-midi (not
realizing usb-midi is in the kernel) I load the ezusb2131 with:
modprobe ezusb2131 vendor_id=0x763 product_id=0x110
I then cat the firmware into the device.
I then load usb-midi. This is how I do it manually when hotplug does
not work correctly.
dmesg list that I have a /dev/midi02 now.
My first question is if I am setting up the above correctly?
My second question is how do I use it besides with muse, csound, and pd?
Muse does not detect the device. I have to add a new raw midi device in
the midi configuration of muse. That is ok but should it be detected.
I can't get it to work with other sequencers at all because most of them
don't allow you to add raw midi devices. Now csounds and pd will listen
to a raw midi device.
The way I have been using it is through muse. Then I set up any other
synth in muse.
Thanks,
Jeremiah
Running alsaconf version 0.9.0 under Red Hat 9.0 with the Planet CCRMA
kernel and ALSA setup...
In running alsaconf to try to configure ALSA for my system's sound card
(reported as an "ens1371 Ensoniq 5880 AudioPCI (rev 03)"), I get the
following errors:
/usr/sbin/alsaconf: line 340: let: a=(>>2) & 0x3f: syntax error: operand
expected (error token is ">>2) & 0x3f")
/usr/sbin/alsaconf: line 341: let: b=(( & 0x03) << 3) | (( >> 13) &
0x07): syntax error: operand expected (error token is "& 0x03) << 3) |
(( >> 13) & 0x07)")
/usr/sbin/alsaconf: line 342: let: c=(>> 8) & 0x1f: syntax error:
operand expected (error token is ">> 8) & 0x1f")
/usr/sbin/alsaconf: line 349: let: v=((>>8)&0xff)|((&0xff)<<8): syntax
error: operand expected (error token is ">>8)&0xff)|((&0xff)<<8)")
These come from the following function:
# convert ISA PnP id number to string 'ABC'
convert_isapnp_id () {
let a='('$1'>>2) & 0x3f'
let b='(('$1' & 0x03) << 3) | (('$1' >> 13) & 0x07)'
let c='('$1'>> 8) & 0x1f'
strs='@ABCDEFGHIJKLMNOPQRSTUVWXYZ'
echo ${strs:$a:1}${strs:$b:1}${strs:$c:1}
}
which is only called here:
# list isapnp cards
while read driver cardvendor carddevice data vendor func; do
if expr $driver : 'snd-.*' >/dev/null ; then
if [ "$last_driver" != "$driver" ]; then
echo $driver.o
last_driver=$driver
fi
id1=`convert_isapnp_id $cardvendor`
dev1=`swap_number $carddevice`
id2=`convert_isapnp_id $vendor`
dev2=`swap_number $func`
echo "ISAPNP: $id1$dev1=$id2$dev2"
fi
done < $MODDIR/modules.isapnpmap >> $1
}
This suggests that there's some problem with the "cardvendor" value...
but here I fall off the edge of my knowledge.
Does this look familiar, and is there a way to fix it?
off topic but hilarious - the SCO 419 scam....
-------- Original Message --------
DEAR SIR/MADAM:
I AM MR. DARL MCBRIDE CURRENTLY SERVING AS THE PRESIDENT AND CHIEF
EXECUTIVE OFFICER OF THE SCO GROUP, FORMERLY KNOWN AS CALDERA SYSTEMS
INTERNATIONAL, IN LINDON, UTAH, UNITED STATES OF AMERICA. I KNOW THIS
LETTER MIGHT SURPRISE YOUR BECAUSE WE HAVE HAD NO PREVIOUS
COMMUNICATIONS OR BUSINESS DEALINGS BEFORE NOW.
MY ASSOCIATES HAVE RECENTLY MADE CLAIM TO COMPUTER SOFTWARES WORTH AN
ESTIMATED $1 BILLION U.S. DOLLARS. I AM WRITING TO YOU IN CONFIDENCE
BECAUSE WE URGENTLY REQUIRE YOUR ASSISTANCE TO OBTAIN THESE FUNDS.
IN THE EARLY 1970S THE AMERICAN TELEPHONE AND TELEGRAPH CORPORATION
DEVELOPED AT GREAT EXPENSE THE COMPUTER OPERATING SYSTEM SOFTWARE KNOWN
AS UNIX. UNFORTUNATELY THE LAWS OF MY COUNTRY PROHIBITED THEM FROM
SELLING THESE SOFTWARES AND SO THEIR VALUABLE SOURCE CODES REMAINED
PRIVATELY HELD. UNDER A SPECIAL ARRANGMENT SOME PROGRAMMERS FROM THE
CALIFORNIA UNIVERSITY OF BERKELEY DID ADD MORE CODES TO THIS OPERATING
SYSTEM, INCREASING ITS VALUE, BUT NOT IN ANY WAY TO DILUTE OR DISPARAGE
OUR FULL AND RIGHTFUL OWNERSHIP OF THESE CODES, DESPITE ANY AGREEMENT
BETWEEN AMERICAN TELEPHONE AND TELEGRAPH AND THE CALIFORNIA UNIVERSITY
OF BERKELEY, WHICH AGREEMENT WE DENY AND DISAVOW.
IN THE YEAR 1984 A CHANGE OF REGIME IN MY COUNTRY ALLOWED THE AMERICAN
TELEPHONE AND TELEGRAPH CORPORATION TO MAKE PROFITS FROM THESE
SOFTWARES. IN THE YEAR 1990 OWNERSHIP OF THESE SOFTWARES WAS TRANSFERRED
TO THE CORPORATION UNIX SYSTEM LABORATORIES. IN THE YEAR 1993 THIS
CORPORATION WAS SOLD TO THE CORPORATION NOVELL. IN THE YEAR 1994 SOME
EMPLOYEES OF NOVELL FORMED THE CORPORATION CALDERA SYSTEMS
INTERNATIONAL, WHICH BEGAN TO DISTRIBUTE AN UPSTART OPERATING SYSTEM
KNOWN AS LINUX. IN THE YEAR 1995 NOVELL SOLD THE UNIX SOFTWARE CODES TO
SCO. IN THE YEAR 2001 OCCURRED A SEPARATION OF SCO, AND THE SCO BRAND
NAME AND UNIX CODES WERE ACQUIRED BY THE CALDERA SYSTEMS INTERNATIONAL,
AND IN THE FOLLOWING YEAR THE CALDERA SYSTEMS INTERNATIONAL WAS RENAMED
SCO GROUP, OF WHICH I CURRENTLY SERVE AS CHIEF EXECUTIVE OFFICER.
MY ASSOCIATES AND I OF THE SCO GROUP ARE THEREFORE THE FULL AND RIGHTFUL
OWNERS OF THE OPERATING SYSTEM SOFTWARES KNOWN AS UNIX. OUR ENGINEERS
HAVE DISCOVERED THAT NO FEWER THAN SEVENTY (70) LINES OF OUR VALUABLE
AND PROPRIETARY SOURCE CODES HAVE APPEARED IN THE UPSTART OPERATING
SYSTEM LINUX. AS YOU CAN PLAINLY SEE, THIS GIVES US A CLAIM ON THE
MILLIONS OF LINES OF VALUABLE SOFTWARE CODES WHICH COMPRISE THIS LINUX
AND WHICH HAS BEEN SOLD AT GREAT PROFIT TO VERY MANY BUSINESS
ENTERPRISES. OUR LEGAL EXPERTS HAVE ADVISED US THAT OUR CONTRIBUTION TO
THESE CODES IS WORTH AN ESTIMATED ONE (1) BILLION U.S. DOLLARS.
UNFORTUNATELY WE ARE HAVING DIFFICULTY EXTRACTING OUR FUNDS FROM THESE
COMPUTER SOFTWARES. TO THIS EFFECT I HAVE BEEN GIVEN THE MANDATE BY MY
COLLEAGUES TO CONTACT YOU AND ASK FOR YOUR ASSISTANCE. WE ARE PREPARED
TO SELL YOU A SHARE IN THIS ENTERPRISE, WHICH WILL SOON BE VERY
PROFITABLE, THAT WILL GRANT YOU THE RIGHTS TO USE THESE VAULABLE
SOFTWARES IN YOUR BUSINESS ENTERPRISE. UNFORTUNATELY WE ARE NOT ABLE AT
THIS TIME TO SET A PRICE ON THESE RIGHTS. THEREFORE IT IS OUR RESPECTFUL
SUGGESTION, THAT YOU MAY BE IMMEDIATELY A PARTY TO THIS ENTERPRISE,
BEFORE OTHERS ACCEPT THESE LUCRATIVE TERMS, THAT YOU SEND US THE NUMBER
OF A BANKING ACCOUNT WHERE WE CAN WITHDRAW FUNDS OF A SUITABLE AMOUNT TO
GUARANTEE YOUR PARTICIPATION IN THIS ENTERPRISE. AS AN ALTERNATIVE YOU
MAY SEND US THE NUMBER AND EXPIRATION DATE OF YOUR MAJOR CREDIT CARD, OR
YOU MAY SEND TO US A SIGNED CHECK FROM YOUR BANKING ACCOUNT PAYABLE TO
"SCO GROUP" AND WITH THE AMOUNT LEFT BLANK FOR US TO CONVENIENTLY SUPPLY.
KINDLY TREAT THIS REQUEST AS VERY IMPORTANT AND STRICTLY CONFIDENTIAL. I
HONESTLY ASSURE YOU THAT THIS TRANSACTION IS 100% LEGAL AND RISK-FREE.
--
|\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,_ HTTP 503: Too Busy
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) fL
"Do not meddle in the affairs of cats, for they are
subtle and will piss on your computer."
-- Bruce Graham
Musicians say No to RIAA Persecution and Prosecution of Music Lovers!
Sign the petition at http://www.copyleftmedia.org.uk/justsayno/
.::. www.iriXx.org .::. www.copyleftmedia.org.uk .::.
Version 2.3.0 of the GPLed musical score editor NoteEdit is available:
http://rnvs.informatik.tu-chemnitz.de/~jan/noteedit/noteedit.html
New features:
- score layout : braces (piano staffs), brackets (staff groups),
continued/discontinued bar rules.
Note! NoteEdit does its best to export the score layout. But
depending on your typesetting system the score layout possibly
changes (see below)
- Hungarian GUI translation (thanks to Peter Breuer <comp(a)suselinux.hu>)
- end bar
- multi repeats
Note! The multi repeat influences the replay but the signature
is only exported to MUP. (Perhaps some gurus can sometimes
explain to me how to export this into to different typesetting
systems).
- UTF8 text coding in "*.not" files. This sould enable correct restore
of Russian (Cyrillic), Greek, Hebrew, ... texts.
Note! It does not mean it exports Russian, (Cyrillic), Greek,
Hebrew, ... texts to MusiXTeX, LilyPond, ABC music, ...! I'm afraid
I'd need a native language speaker with some C++ programming
knowledge to solve this.
Note further! This implies a small version incompatibility if
you wrote lyrices and titles containing non-ascii characters :-(
Please correct them on NoteEDit score and store them again.
Note futher! I'm not quite sure whether this disturbs the
KDE-2.x/Qt-2.x compatibility.
- the # --> B / B --> # tool influences only the selected part (if any)
this is especially usful after Midi import if the score
has some B and some # parts.
- bugs fixed, among them:
+ correct replay of dal segno al coda
+ correct MusiXTeX export of ending repeat close symbol
+ cleanup rests works (again)
Problems exporting score layout
===============================
MusiXTeX actually accepts either completely continued or completely
discontinued bar rules. If you specify a mix of partial
continued and partial discontinued bar rules NoteEdit
produces some statements of the musixdbr.tex package
by Rainer Dunker. NoteEdit produces a warning and gives
advice to install this package. Otherwise MusiXTeX will fail.
PMX is a preprocessor to MusiXTeX and therefore the same problems apply.
ABC music cannot deal with nested braces in brackets. NoteEdit will warn you.
LilyPond can deal with braces and brackets. It changes the staff
rules according to some LilyPond inherent rules. I was
told it is possible to break these rules. But I assume
they are there for good reasons. NoteEdit will warn you
if a LilyPond rule will change the staff rule policy.
MUP has no limitations.
--
J.Anders, Chemnitz, GERMANY (ja(a)informatik.tu-chemnitz.de)