Hi there,
I'm lurking around since some years here and try to follow your
discussions here.
Now I'm looking for karaoke systems in software for Linux.
So sth. which shows the karaoke channels of VCDs and DVDs or real
karaoke media. By showing I don't mean dumping it into a
text file, but the way an karaoke system would show it.
I also need some basic realtime equalizer and stuff to e.g. lower
a female voice to allow singing songs made for male voices.
But that is secondary.
Is anything out there, which might help me?
Thanks & Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
Hi All,
I'm getting a bit confused about how mixers and special harware controls (like GPIOs) are implemented in ALSA(0.9.0) :
What is the difference between /proc/asound/dev/controlC0 and /proc/asound/dev/mixerC0 ?
My card (ens1371) does not feature a mixerC0 device, does a call to snd_mixer_open(..) require a such device to exist?
Basically, what for should I open the controlC0 device ? (mixer settings, power management ? )and do I need to implement a mixerCx device ?
Should controlC0 be used for lowlevel settings global to the board, while hwC?D? would be for proprietary hardware control on a given IO ?
Thanks,
Marc.
in a second confirmation (post steinberg) of the tiny size of the
audio marketplace:
Under the proposed transaction, Sun Capital would acquire
approximately 9.8 million shares of Mackie common stock, or
approximately 65% of Mackie's total common stock outstanding, through
the purchase of approximately 7.4 million outstanding shares from
certain selling shareholders and approximately 2.4 million newly
issued shares for a total of approximately $10 million in cash.
that puts their valuation of Mackie at about $15.4M. i know that
Mackie is a niche player, not working at the same level as, say,
Gibson or Fender, but they are one of the preeminent trade mixer
makers and they also make some damn cool products.
!! *products* !! hardware! marketing! people! customers! reputation!
all this could have been yours for a few million :)
of course, there is an interesting question: who are the sellers of
those 7.4 million shares (some 49% of all existing shares)? they
appear to be basically dumping somewhere between half and all their
existing holdings in Mackie. that's quite a sell off.
--p
> the big problem is that writing even a simple WM is not
> trivial. still, i would guess that taking twm and hacking it to
> enforce window sizes and position can't be that hard.
twm would be an awful choice -- the code's completely unreadable
and surprisingly huge. There are plenty of ultra-minimal window
managers around these days that have far better code. Practically
anything written since 9wm (a pivotal app in the window manager
world). Hacking on one of those need not be hard at all.
http://www.plig.org/xwinman/others.html
The newer ones are generally nearer the top.
I wrote wm2 and wmx which have far too particular a look for the
sort of thing you want, but the code's not _too_ bad and I'd be
happy to answer questions (though I haven't the time to work on
any actual coding of this sort). They're in C++ with BSD-style
licensing. They're getting on a bit now though and there are
doubtless easier choices even than wm2 these days.
http://www.all-day-breakfast.com/wm2/
Chris
I use my PC as a multitrack-recorder and the only program I miss from windows
OS is the fruityloops. I tried to ask from fruitydevelopers about linux-support
and the answer I get was:
"(I wrote)do you think that linux users won´t pay for a good program? is
it time, do you have hands full of work in windows versions?
(reflex wrote)These two are probably among the main reasons. Also, you'll
have to admit that Linux isn't as mature a platform as Windows yet."
I´m not a programmer, but If I were, I´d try to do some co-operation with
fruity-developers and do an linux-support to the fruityloops. ´cause it´s
only the question of time&money. Is there anyone who could do something about
this?
or is there any program on linux already which works like fruity?
you can check our conversation on fruityloops-site(click the "linux, why
not?")
http://forum.e-officedirect.com/forum.exe?forumname=Fruityloops_DevelopersA…
I could give my other testicle for the one who does the linuxversion of fruity.
thanks.
,Tomi
_____________________________________________________________
Kuukausimaksuton nettiyhteys: http://www.suomi24.fi/liittyma/
Yli 12000 logoa ja soittoääntä: http://sms.suomi24.fi/
amSynth - Analogue Modelling SYNTHesizer
****************************************
amSynth 1.0-rc2, code-named "jack", is now available!!
Get the source code at http://amsynthe.sourceforge.net/amSynth
Changes in this release:
* you've been waiting for it -- JACK audio output support!!
* completely revised ./configure & build system - will adapt features to
libraries installed, proper 'make install' target...
* launch a virtual keyboard from the amSynth menu!
* transparent per-user installation for first time users
* build fixes galore, now compiles fine on latest GCC versions
Enjoy!
(and any problems with it please get in touch, details on website)
-Nick d-.-b
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
k_jack is a jack reimplementation, and mammut is a very special sound
transformating sound editor.
Download from http://www.notam02.no/arkiv/src/
New in mammut v0.14->v0.15:
---------------------------
-Removed the synth transform. It was not supposed to be there and had no
function.
-Fixed the wobble transform. Segfaulted with mono-files. (Bug found
by Dave Phillips)
k_jack V0.0.0.5 ALPHA - EXPERIMENTAL
-------------------------------------
ABOUT
k_jack currently consists of k_jackd~, libk_jack and libaipc.
k_jackd~ is a jack server external for pure-data.
libk_jack is (supposed to be) a (somewhat) libjack compatible
library.
Jack applications that want to contact k_jackd~ instead
of jackd must (somehow) be linked with libk_jack and
libaipc instead of libjack.
k_jackd~ does not speak with libjack, and jackd does not
speak with libk_jack.
libaipc is a library for audio interprocess communication,
based on code from the vstserver. A preview version is
included with this version of k_jack. (API is not settled.)
By using libaipc for interprocess communication, and letting
PD take care of various low/mid/high-level audio-stuff,
only a few hundred lines of code is currently used for this
implementation of a simple jack system.
k_jackd~ and libk_jack are not based on the jack sourcecode
found at jackit.sf.net, except for protos in the header files.
COMPILE
1. Go into the aipc/src folder and write make to compile up
libaipc.a
2. Go into the library folder and write make to compile up
libk_jack.a
3. Write make to compile up k_jack~.pd_linux.
4. Relink you jack application(s) somehow.
USAGE
1. Start pd with the "-lib k_jackd~" option.
2. Start a jack application linked with libk_jack.
3. Make an object in pd called "k_jackd~ <clientname>".
Correct number of inlets and outlets will be made
automaticly.
That should be it. Later, when things get more stable, point 3
can do point 2 automaticly.
WHY
use k_jackd~ ?
1. Simple. Only the clientname is used, not the portnames.
2. Easy and powerful interface to control the audioflow.
3. Good performance. Shouldn't be necessary to run as root.
TESTED CLIENTS
simple_client, freqtweak, ceres.
BUGS
Crashes pretty often. Does not clean up. Huge risk of not
freeing shared memory in the current implementation: Client
must exit before server, and client must not crash. And
server must not crash.
CONTACT
Send ideas (especially about the k_jackd~ object syntax),
comments (especially about the libaipc API), questions,
code, food, etc. to k.s.matheussen(a)notam02.no
--
I just noticed the announcement from RME about their Hammerfall DSP MADI
PCI card. From the announcement:
"MADI, the professionals' multichannel audio interface, offers 64
channels of 24 bit audio at a sample rate of up to 48 kHz and 32
channels at up to 96 kHz. Transmission is done via a single line, either
coaxial with BNC plugs or with fibre cable. In both cases more than 100
m cable length can be achieved. Hammerfall DSP is fully compatible to
all devices with MADI interface."
This will make seriously high end gear available for use with standard
PC's. As ardour nears readiness, I have been contemplating a total
upgrade of my recording gear but I don't like the idea of Toslink in
general (short cable length), or adat optical in particular (high
jitter), but I do like the idea of optical coupling of audio gear to
computer gear (cleaner electricity for the audio gear). I'm glad I
waited. Availability is predicted to be within the next 6 months. Now
if manufacturers of reasonably priced a/d converters can offer something
with a MADI interface within the next 6 months...
Tom
> >Argh, what's the great thing about standards again. I still prefer mLAN, as
> >it uses generic, consumer i/o cards, and firewire is fitted to almost all
> >laptops without needing expensive audio only hardware.
A single firewire standard would be great, but it hasn't happened yet.
MOTU, Digi, Metric Halo, and Yamaha all have incompatible proprietary
implementations. Plus there is the minor 4 or 6 conductor thing
courtesy of Sony. Starting to look like a mess to me.
> it all still sounds pretty dubious to me,
Me too.
> hopefully, this should echo the fact that i'm with steve: MADI is an
> audio-only system, its expensive, and i don't think it has any
> particular technical benefits over mLAN. its sole advantage at this
> point is that anyone (as i understand it) can implement it without the
> licensing and other uncertainties that surround mLAN at this time.
The gear that uses it is expensive, but it isn't. RME will sell theirs
for the same price as a hammerfall. There is no reason why budget gear
can't use it. Audio-only systems are all that's available right now.
MADI and adat optical exist as open solutions right now. S/MUX support
for adat is spotty. mlan, and 1394 in general, doesn't exist as an open
solution. Sure I would like midi and audio on the same cable, but it's
not available right now. 6 months from now I will go with mlan if it is
openly available. If not then I will go with madi if I can afford it.
Otherwise I will go with adat optical. I have been postponing new gear
purchases for a long time waiting for an open 1394 solution. Eventually
I will have to stop being a cheerleader and actually acquire some gear.
The current favorite, adat optical, simply doesn't impress me. If
development stays on course, and I am ready to start using ardour in 6
months, mlan will be the only solution of the three that will *not* be
available.
Tom
