Hello everyone!
Well this would have been "Hallo zusammen". But maybe it's the same thing
with other non-English languages.
I have a text in ISO-8859-1 (or whatever), so it's german. I use ispell on
this document, but it displays all umaltuts and such as a strange combination
of characters. One of them si always a dash "-", so spellchecking is miserable
work.
Can anyone of you help me here? Suggestions? A Trick?
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
Sorry. I just renamed the file so it got a ".txt" AT THE END AND ALL WAS WELL.
sILLY THING. :-)
bEST,
jULIEN
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
Hi there --
I have a commercial CD available for pre-order, for my
progressive/psychedelic metal project called Alhazred (the same that
is linked on the Rosegarden website). The music was produced with
Windows and Linux software. I used Ardour, Rosegarden and Hydrogen on
the Linux side and Reaper and some commercial sample packages on
Windows. All of the final mixing and pre-mastering was done on Linux.
Final mastering was done by Ty Tabor of King's X fame at Alien Beans
Studio.
Details are here:
http://www.alhazred.com
-- Brett
------------------------------------------------------------
"In the rhythm of music a secret is hidden;
If I were to divulge it, it would overturn the world."
-- Jelaleddin Rumi
Andy,
If you don't need the keyboard then I'd also recommend a Behringger BFC2000,
which has 8 motorized faders and 8 encoders and is well supprted under
linux. It's also fairly cheap considering the featureset. I'm pretty sure
there are a number of users in this list.
-michael
On Tue, Jul 28, 2009 at 4:37 PM, andy baxter <
andy(a)earthsong.free-online.co.uk> wrote:
> Hi michael,
>
> Thanks for the info about the remote25. It looks good (just skimming
> through the review in 'sound on sound'), but I don't really want to get
> another device with a keyboard when I've just bought one.
>
> What I really want is a 'bare bones' device with just some encoders,
> buttons, and an lcd screen. An x-y pad would be nice as well but not
> essential.
>
> andy
>
> michael noble wrote:
>
>> Hi Andy,
>>
>> I'm not sure exactly if it is what you need, but I would have thought that
>> any class compliant midi controller with encoders and some facility for
>> controller banks will serve your purpose. The novation remote25 which I have
>> has 8 encoders, 8 knobs, 8 sliders, an x/y pad, joystick and 16 buttons,
>> plus instant recall of any of 64 stored presets of controller mapping. To be
>> honest that's all overkill for me as the only thing I use beside the
>> keyboard are the encoders and the banks, but it serves its purpose. Editing
>> the controllers is not as direct as you seem to wish for, but setting up a
>> new controller with the editing mode takes about 15 seconds and I've done so
>> in live situations when needed. To my knowledge many midi controllers offer
>> similar capabilities.
>>
>> As for displaying the current level of a synth or software based parameter
>> on the controller lcd, that all depends mostly on whether the software
>> implements midi feedback or not. Without knowing your specific software its
>> difficult to say what the status of support is.
>>
>> -michael n
>>
>>
>>
>> On Tue, Jul 28, 2009 at 1:28 PM, andy baxter <
>> andy(a)earthsong.free-online.co.uk <mailto:andy@earthsong.free-online.co.uk>>
>> wrote:
>>
>> Hello,
>>
>> I have just bought a second hand keyboard, (edirol PCR-500) which has
>> loads of knobs and sliders on it. The trouble is that all the
>> knobs are
>> pots, not rotary encoders; encoders would be much more useful I think
>> because it would mean that if you press a button to switch to a new
>> synth or effects patch, the correct defaults for it could be
>> automatically loaded to each of the knobs when you switch. Without
>> that,
>> it seems like whenever you switch to a new instrument you would
>> have to
>> spend a while tweaking all the knobs to get the right basic sound.
>>
>> What I would like is a device with a couple of rotary encoders on it
>> (you only have two hands), maybe 16 buttons, and a character LCD
>> screen.
>>
>> The way it would work is (something-like):
>>
>> - one of the buttons would be for loading new instruments. To
>> switch to
>> a new instrument, you would press the button and then turn either
>> encoder. The LCD would show which instrument you were choosing from a
>> list, and you would press the button again to make the switch.
>> - most of the buttons would be for accessing different midi controls.
>> You could assign a midi control to an encoder by pressing the
>> button for
>> that control first, then pressing a button underneath the encoder you
>> were assigning.
>> - having done this, that encoder would be bound to that midi control -
>> turning it would send out midi messages for that control, and also
>> update a display on the LCD saying what the level of that control is
>> currently set at.
>> - loading a new instrument would automatically set the right default
>> levels for each controller that that instrument used.
>>
>> Does anyone know of anything like this that's already being made?
>> If so
>> I might get hold of one and see if I can hack it to work with
>> linux; if
>> not I'm thinking of having a go at making my own some time.
>>
>> cheers,
>>
>> andy baxter.
>> _______________________________________________
>> Linux-audio-user mailing list
>> Linux-audio-user(a)lists.linuxaudio.org
>> <mailto:Linux-audio-user@lists.linuxaudio.org>
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>>
>>
>>
>>
>> --
>> networking practice for sound environments ::
>> http://nowhere.iamnobody.net
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Linux-audio-user mailing list
>> Linux-audio-user(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>>
>>
>
>
--
networking practice for sound environments :: http://nowhere.iamnobody.net
Hello LAU!
I try to run xwax on ubuntustudio 8.10 on a Panasonic CF-T2 subnotebook
(1Ghz/512MB). Everytime I start real time audio apps like jack the graphic
gets very slow and freezes for some seconds, also the audio playback is like
timestretched and sounds filtered.
I guess it has something to do with interrupts shared by graphic and sound
(sound comes from a Maya44 USB sound card).
Can anybody give me a hint how to check or alter interrupt settings or do
you have any other ideas...?!
Thanks in advance!
Martin
Many thanks Albert,
I be glade you like it,
The Compressor guitarix use, is hardly based on your Compressor Faust
code, I only rework it to make it work with 1.channel :-)
So many thanks to you for sharing your know how with us.
hermann
I have replace the link on the guitarix project page to your
Faust example page now.
Am Montag, den 27.07.2009, 16:50 +0200 schrieb Albert Graef:
> hermann wrote:
> > guitarix is a simple Linux Rock Guitar amplifier and is designed
> > to achieve nice thrash/metal/rock/blues guitar sounds.
>
> Cool stuff. Congrats on the new release. :)
>
> > : Albert Graef
> > http://www.musikwissenschaft.uni-mainz.de/~ag/ag.html
>
> Also see http://q-lang.sourceforge.net/examples.html#Faust for some of
> my own Faust examples.
>
> Albert
>
I would like to make a personal project. Buy in thinkgeek.com a Korg Nano Digital Music Controllers (http://www.thinkgeek.com/electronics/musical-instruments/af36/) and make it available for Linux, and make MIDI programming like I make in my several MIDI devices. I have no experience in USB MIDI devices and I want to ask if I can spend with no doubt the 50$ that costs.
For instance, USB MIDI keyboards are available in Linux like is explained in http://wiki.archlinux.org/index.php/USB_Midi_Keyboards
aconnect -i
client 72: 'MK-361 USB MIDI keyboard' [type=kernel]
0 'MK-361 USB MIDI keyboard MIDI 1'
...but I don't know if this is usefull for all USB MIDI devices like the ones that I say.
Thanks,
Joan Quintana
Hey:
Unless you check a dodgy email with a Windows email app or surf the web
using a Windows
browser, you should be OK.
I've tried editors for some other controllers I have (Evolution UC-33e and
Novation Xio 25) and
they all work well
cheers,
ernie
On Mon, Jul 27, 2009 at 12:07 AM, Norval Watson <norv2001(a)yahoo.com.au>wrote:
> thanx Ernie! I am a bit scared of Wine - will I get a virus?????
> Norv
>
> *******************************************
> My art, blog, films, music, photos, tweets -
> http://www.norvalwatson.com
>
>
> *From:* Ernie Dulanowsky <ernst(a)pulsewidth.ca>
> *To:* Norval Watson <norv2001(a)yahoo.com.au>
> *Cc:* Linux Audio User <linux-audio-user(a)lists.linuxaudio.org>
> *Sent:* Monday, 27 July, 2009 4:05:30 PM
> *Subject:* Re: [LAU] USB MIDI devices
>
> Hi,
> FYI: The librarian software for the Korg Nano controllers works well under
> Wine...
>
> cheers,
> ernie
>
> On Sun, Jul 26, 2009 at 6:55 PM, Norval Watson <norv2001(a)yahoo.com.au>wrote:
>
>>
>>
>> Hi Joan,
>> My Korg padKONTROL works very well with Linux.
>> Connect to computer with USB, power on, open JACK connections and there it
>> is.
>> I have not tried the librarian software at all.
>> HTH
>> Norv
>>
>>
>>
>>
>> ----- Original Message ----
>> > From: Joan Quintana <joan_quintana(a)yahoo.com>
>> > To: Linux Audio User <linux-audio-user(a)lists.linuxaudio.org>
>> > Sent: Monday, 27 July, 2009 10:47:48 AM
>> > Subject: [LAU] USB MIDI devices
>> >
>> >
>> > I would like to make a personal project. Buy in thinkgeek.com a Korg
>> Nano
>> > Digital Music Controllers
>> > (http://www.thinkgeek.com/electronics/musical-instruments/af36/) and
>> make it
>> > available for Linux, and make MIDI programming like I make in my several
>> MIDI
>> > devices. I have no experience in USB MIDI devices and I want to ask if I
>> can
>> > spend with no doubt the 50$ that costs.
>> >
>> > For instance, USB MIDI keyboards are available in Linux like is
>> explained in
>> > http://wiki.archlinux.org/index.php/USB_Midi_Keyboards
>> >
>> > aconnect -i
>> >
>> > client 72: 'MK-361 USB MIDI keyboard' [type=kernel]
>> > 0 'MK-361 USB MIDI keyboard MIDI 1'
>> >
>> > ...but I don't know if this is usefull for all USB MIDI devices like the
>> ones
>> > that I say.
>> >
>> > Thanks,
>> > Joan Quintana
>> >
>> >
>> >
>> > _______________________________________________
>> > Linux-audio-user mailing list
>> > Linux-audio-user(a)lists.linuxaudio.org
>> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>>
>>
>>
>>
>> ____________________________________________________________________________________
>> Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
>> Show me how: http://au.mobile.yahoo.com/mail
>>
>> _______________________________________________
>> Linux-audio-user mailing list
>> Linux-audio-user(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>>
>
>
>
> --
> ++++++++++++++++
> Ernie Dulanowsky
> www.pulsewidth.ca
> ++++++++++++++++
> oblique: Make an exhaustive list of everything you might do<http://twitter.com/oblique/statuses/2853272434>
>
>
> ------------------------------
> Access Yahoo!7 Mail on your mobile. Anytime. Anywhere. Show me how<http://au.rd.yahoo.com/mail/mobile/tagline/*http://au.mobile.yahoo.com/mail>
> .
>
--
++++++++++++++++
Ernie Dulanowsky
www.pulsewidth.ca
++++++++++++++++
oblique: Mechanicalize something
idiosyncratic<http://twitter.com/oblique/statuses/2852275325>
On Sat, 25 Jul 2009, Brent Busby wrote:
> In addition to the question I posted earlier about PREEMPT_RCU, I've
> found still other kernel config options that are not covered in most of
> the extant howtos for setting up low latency kernels, because they are
> recently added in the unpatched kernel. (Or at least, they're more
> recent than most of the howtos...)
>
> I've been researching these options, mostly by googling (and
> googling...and googling) the Linux Kernel Mailing List archives, and
> also by looking at the config used by 64Studio, since it seems the
> prevalent opinion is that they are stable as a rock. With the latter
> approach of checking against 64Studio's config, I've had little luck
> though, because their distro currently comes in a 2.1 "stable" version
> that is based on Debian "etch", with a 2.6.21 kernel that predates the
> existence of some of the config options I'm asking about; and a 3.0
> "beta" version that uses a newer kernel, but should also probably be
> taken with a grain of salt, because 64Studio is still working the bugs
> out of it, and because it seems to have options turned on that the LKML
> archives have warned strongly against. So, most of the information I've
> gleaned has been from the LKML.
I tried out the 64Studio stable version last fall, and had a lot of troubles
with it. The 2.6.21 based kernel wouldn't even boot on my box, so I ended up
booting up with the 2.6.24 based -rt kernel that I was using on Fedora 8 /
CCRMA. There were too many libraries and apps that were way too out of date
for my tastes, so I abandoned the whole experiment.
> I might as well collate these questions here, for what good it may do.
> The kernel I'm configuring is 2.6.29.6 with matching RT patches (-rt23),
> though all of the options listed here are actually present even in the
> unpatched 2.6.29.6 kernel.
>
>
>
> PREEMPT_RCU :
>
> This was the one my original question was about in the earlier post.
> In the newer kernels (even mainline ones, without any RT patches), there
> is a choice of "RCU Subsystem", with one option being "classic", and
> other being "preemptable". The choice would seem obvious for low
> latency, except that the help text warns that a preemptible RCU is
> likely to expose serious kernel bugs that may render the system
> completely unstable. (This is *not* the same setting as the various
> CONFIG_PREEMPT options that have been present in the mainline kernel for
> awhile now. This is something new, and it appears in menuconfig as a
> separate setting.) I think I've mostly gathered from reading through
> the whole process of debugging that the kernel gurus went through that
> as of last year or so, this is now considered mostly stable, after
> having been subjected to a utility called 'rcutorture', and having fixed
> many lockups. I'd still be interested in anything anyone else can
> contribute about it though, especially if they're using it and they
> also think it is stable.
There was a time when PREEMPT_RCU was unstable, and most of the -rt kernel
releases would fix one RCU bug while adding another. These times are now past,
however. PREEMPT_RCU has been completely stable for me on AMD and Intel (both
multicore) for about a year now.
> GROUP_SCHED :
>
> This one is interesting, and I don't know what to make of it, other than
> that the LKML seems to have decided in the last two months or so that it
> slows your system down and makes latencies worse.
> The thing that's confusing about it though is that it's
> described as a mechanism for grouping high priority tasks by group.
> It's implied (though not spelled out specifically) that they even mean
> by this Posix groups, because in one document I read, it says that
> enabling this will cause you to be unable to get realtime as a non-root
> user unless you are setup in a group specified in limits.conf. Hmm!
> That sounds an awful lot like what we've just been calling pam_limits
> for years now. Are we doing this with a kernel config option now? (One
> which apparently doesn't work?)
> The 3.0 (beta) version of 64Studio turns this on. Then again,
> looking at their kernel config, they seem to turn everything on, and
> that might be why it's considered beta. (The 2.1 stable version of
> 64Studio seems to have a kernel old enough that it never had that
> option as a choice.) Anyone have any feedback about this? It's only in
> the past two months that the kernel gurus have decided that it's bad,
> but they're actually considering marking it broken from what I've read.
Here's another vote for completely broken! Every time I set up a box with the
-rt kernel, I start with the distro's .config and tweak from there. And every
time, I can't make realtime low-latency audio a reality until I disable
GROUP_SCHED.
> CGROUPS :
>
> This sounds cool, but I'm reasonably sure it's not actually necessary.
> Documentation I've read suggests that this allows for letting
> applications (or users) define CPU and memory pool affinity for tasks,
> so that one could arbitrarily tie down particular threads or tasks to a
> given processor core, or region of memory (or something like that).
> However, the thing that makes me somewhat sure I don't positively need
> this is that the same documentation also says that if you want to use
> it, you need to create a new subdirectory under /dev, mount a new
> pseudofilesystem under it, and then this module will populate that space
> with dynamic configuration data about these affinity groups for running
> tasks. I have neither seen any distro (even ones made for musicians)
> that has set any such thing up out of the box, nor have I ever seen a
> realtime howto that tells people to do it themselves. It sounds like
> there's a lot of infrastructure necessary for this that's not common in
> distros yet. (Though I see that regular Debian "lenny" turns this on in
> the kernel without actually providing the special /dev support for it,
> which I presume they're thinking you'll setup yourself if you're
> interested.) Still, comments welcome...
As far as I can tell, CGROUPS doesn't affect realtime latencies enough to make
any sort of difference for realtime audio. It does, however, mess with the
scheduler, even without setting up the affinity groups. I've noted some
strange scheduling behavior: When running multiple instances of the same CPU
bound task (like burnP6, mprime, dd, or your favorite stress tester), the tasks
usually start off fairly evenly distributed between the cores, and then the
affinity seems to drift, lumping these tasks on one half of the cores while
leaving the other half mostly idle. On a core2quad with CGROUPS enabled, I
generally have to run 12 instances of burnP6 to keep utilization of all four
cores pegged at 99-100%. I wouldn't go as far as to say that CGROUPS is
broken, but I fail to see the usefulness on a production audio system with the
IRQ and other realtime priorities tuned properly, especially now that the core
scheduling features for -rt are stable.
> --
> + Brent A. Busby + "We've all heard that a million monkeys
> + UNIX Systems Admin + banging on a million typewriters will
> + University of Chicago + eventually reproduce the entire works of
> + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
> + James Franck Institute + we know this is not true." -Robert Wilensky
I've also run into a handful of config options that either help or hurt
realtime performance, depending on the specific hardware:
NO_HZ (seems to work properly on most hardware these days)
PCI_MSI (some PCI devices seem to add more latency with MSI)
RTC_DRV_CMOS (this depends on your particluar RTC hardware)
HPET_EMULATE_RTC (this depends on your particluar HPET hardware)
X86_ACPI_CPUFREQ (creates TSC drift between cores on Intel)
And of course, there's all kinds of profiling, stats, testing, and debugging
options that make any realtime load suffer. Occasionally, you'll find a device
driver that's just plain bad for -rt performance, but I've been running into
this problem a lot less these days.
Equally as important for low-latency are the scheduling priorities. After a lot
of google, lkml, and trial and error, I've settled on the following for
rock-solid low-latency audio:
99 FF migration
99 FF posixcputmr
98 FF IRQ-8 (realtime clock)
97 FF audio IRQ (in some cases means ieee1394 or specific USB port)
80 RR JACK
All audio and MIDI apps should run at a lower realtime priority than JACK. All
other IRQ- and sirq- threads should be set to
SCHED_OTHER. To set this up, I've added the following to my /etc/rc.local:
---
# set all irq threads to sched_other
for irq in `pgrep 'IRQ-'`; do
chrt -o -p 0 $irq;
done
# set all softirq threads to sched_other
for sirq in `pgrep 'sirq-'`; do
chrt -o -p 0 $sirq;
done
# set high prio IRQs
chrt -f -p 98 `pgrep IRQ-8` # rtc
chrt -f -p 97 `pgrep IRQ-16` # hda-intel
---
And of course, there's those pesky BIOS options. Some of the newer Intel CPU
features like to generate interrupts that the kernel can do absolutely nothing
about. I had to disable C1E, CPU TM function, execute disable bit, and one of
the ACPI options (can't remember which one) to get my core2quad to work.
Disabling video interrupts (only an issue on older hardware) always seems to
help. AMD systems seem to require much less (if any) BIOS tweaking for -rt.
Please, anyone, correct me if I'm wrong on any of this. Most of this knowledge
is gained from four years of following -rt development and tuning -rt kernels
on a variety of hardware. I'm always adding to my bag of tricks when it comes
to tuning realtime machines ;-}
Cheers,
--ww
