Hello, lists.
Not long ago I tried KX Studio 10.04.1 (updated LiveDVD) and installed it from stratch.
I am very glad to see linuxsampler, included to this distro. Of course, there is more notable things, but it is most for me.
2) Missing dependies: jack-netsource-gui from zenity.
3) Also, disk content's size is less then 2 Gb, so some packages would be nice included to disk: MuseScore, Aeolus, Ingen.
4) Needs packaging Cinecutie; cinelerra doesn't support unicode (very critical for russian and like users), not speaking about GUI. I don't see any reason to use cinelerra instead cinecutie. Both cinecutie and cinelerra have own PPA, maintained by Akirad.
Now a question: what is difference between kernels: linux-preempt from general ubuntu 10.04 repo and lowlatency/realtime kernels from kxstudio? There are two things, that caused me to be interested with kernel from standard ubuntu repository:
1) problems with Nouveau drivers at realtime kernel (nouveau module not found, though I have installed headers) and
2) When I select lowlatency driver, it goes into mode, specified with video= parameter, only after some time, when splash already appeared with theme, not specified through default.plymouth alternative.
Drumstick is a C++ wrapper around the ALSA library sequencer interface using
Qt4 objects, idioms and style. ALSA sequencer provides software support for
MIDI technology on Linux. Complementary classes for SMF and WRK file
processing are also included. This library is used in KMetronome, KMidimon
and KMid2, and was formerly known as "aseqmm".
Changes:
* New visibility attribute for all public classes allowing client programs to
be compiled with hidden visibility if desired.
* Better error reporting for all the utilities.
* Subdirectory "tests" renamed as "utils".
* Utility "smfplayer" renamed as "guiplayer" and enhanced with a new interface
design and support for Cakewalk WRK files.
Copyright (C) 2009-2010, Pedro Lopez-Cabanillas
License: GPL v2 or later
Project web site
 http://sourceforge.net/projects/drumstick
Online documentation
 http://drumstick.sourceforge.net/docs/
Downloads
 http://sourceforge.net/projects/drumstick/files/0.4.0/
On Tue, 2010-07-06 at 10:57 +0100, Daniel James wrote:
[snip]
> I notice
> http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_sup…
> doesn't mention USB or MIDI at all.
>
> Cheers!
>
> Daniel
Hi all :) hi Daniel :)
I'll read this link tomorrow, I just did a short test, right after the
postman did give me the ordered equipment. Please take a look at all the
tests I did here.
The Terratec's MIDI might be ok, but ...
spinymouse11.2@suse11-2:~> cat .alias
alias cpu-o="su -c\"cpufreq-set -gondemand\""
alias cpu-p="su -c\"cpufreq-set -gperformance\""
spinymouse11.2@suse11-2:~> cpu-p
Password:
spinymouse11.2@suse11-2:~> uname -a
Linux suse11-2 2.6.31.6-rt19 #1 SMP PREEMPT RT Wed Nov 18 16:59:26 CET
2009 x86_64 x86_64 x86_64 GNU/Linux
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI
20:0 USB Device 0x170b:0x11 USB Device 0x170b:0x11 MIDI 1
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -i16:0 -o16:0
> SUCCESS
best latency was 0.98 ms
worst latency was 1.42 ms, which is great.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i16:0 -o16:0
> SUCCESS
best latency was 0.99 ms
worst latency was 1.11 ms, which is great.
Then I run glxgears and Firefox with windows always on top and moved the
Firefox window while running the tests.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -i16:0 -o16:0
> SUCCESS
best latency was 0.98 ms
worst latency was 4.15 ms, which is great.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i16:0 -o16:0
> SUCCESS
best latency was 0.99 ms
worst latency was 1.11 ms, which is great.
Then I tested if the hrtimer might change something, I dunno if the test
will use it automatically.
spinymouse11.2@suse11-2:~> su
Password:
suse11-2:/home/spinymouse11.2 # chgrp audio /dev/hpet
suse11-2:/home/spinymouse11.2 # sysctl -w dev.hpet.max-user-freq=64
dev.hpet.max-user-freq = 64
suse11-2:/home/spinymouse11.2 # modprobe snd-hrtimer
suse11-2:/home/spinymouse11.2 # cat /proc/sys/dev/hpet/max-user-freq
64
suse11-2:/home/spinymouse11.2 # exit
Firefox and glxgears still on top of the windows and I moved the Firefox
windows again during the test.
Note that I now used the -R switch for both tests.
pinymouse11.2@suse11-2:~> alsa-midi-latency-test -Ri16:0 -o16:0
> SUCCESS
best latency was 0.99 ms
worst latency was 1.08 ms, which is great.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i16:0 -o16:0
> SUCCESS
best latency was 0.99 ms
worst latency was 1.12 ms, which is great.
Just for comparison one test for the Swissonic USB MIDI device, without
running glxgears or Firefox or moving any window. HPET still enabled.
spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw20 -i20:0 -o20:0
> SUCCESS
best latency was 1.17 ms
worst latency was 2.23 ms, which is great.
Now a final comment to those tests.
When I used the USB MIDI device + HPET the audible result wasn't usable
for music, but I had the impression that half of the jitter would solve
this issue.
If the results of the test are correct and if nothing would change when
running JACK and doing hard disk recording too, then I guess the PCI
MIDI could be ok.
I don't have much time today, perhaps tonight or tomorrow I'll mount the
new HDD and restore my 64 Studio's. When it's done I'll record some
music and additionally I'll ask Achim, http://achimjaroschek.com/ , to
stress the computer by playing the Roland drums and some hardcore
Classic or hardcore Jazz on the keyboards.
It's not only that he plays with all those music giants like Jasper
van't Hof, Peter Brötzmann etc., but he once throw his Apple through the
window and he always advise me not to make music using the computer
anymore.
I've got a good feeling, that around 1ms (when the -R switch is set)
would be good enough to make music, but again, even if the test says
2.23 ms for the USB device should be great, the USB device is unusable
for serious musicians, it results in music that might be done by am
idiot without any sense for music.
I couldn't use the USB device + HPET even for the simple Pop-Rock I
sometimes make.
Cheers!
Ralf
I once did a MIDI extension for SpeechBasic to program a real time MIDI
sound sampler on BASIC for the C64, for example
$1810 LDA $DEO6
$1813 LSR
$1814 BCC $1810
$1816 LDA $DE07; read MIDI event byte, usually followed by RTS
This are 6 bytes of code, to get a MIDI data byte from the UART.
I did an experiment by the signature that makes Adrian going wild.
Some lines for a signature are spam and I do agree.
How many lines of code are used by ALSA MIDI to do the same? Lets say
not per USB, but PCI.
I wonder if MIDI on Linux could become better and if audio could need
less resources when for Linux audio and MIDI, the concept might vary to
the usual Linux concept.
Some very elaborate Mac and Win audio apps do not need much resources or
much bytes.
I hope at least one person would understand that I'm not nagging. I try
to understand Linux code, but it's very long and hard to understand, not
comparable with the 4 lines above or even not comparable to longer code
for professional Atari sequencers.
Is there really a reason, I might not understand, to make Linux audio
that complicated?
Please, I guess some will write that I'm the only one having issues with
ALSA MIDI and JACK, but c'mon ;) ...
Cheers!
Ralf
PS: Latest ALSA MIDI latency tests fortunately did show that USB most
times is useless, see also the 64 Studio lists archives, but PCI MIDI
most times seems to be very good. Perhaps, if you should agree, there
could be an advice on Linux audio web sides to prefer PCI MIDI.
On Mon, 2010-07-05 at 10:15 +0200, Ralf Mardorf wrote:
> -------- Forwarded Message --------
> From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
> To: Clemens Ladisch <clemens(a)ladisch.de>
> Cc: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
> Subject: MIDI jitter - Today for 4 of 4 tests my USB device did pass all
> tests with success
> Date: Mon, 05 Jul 2010 10:14:21 +0200
> I'm very sceptic regarding to the ALSA MIDI latency test, OTOH the PATA
> might have caused 7 ms and IIRC 19 ms too and visually interpretation
> might mistake because it's hard to find the start of waveforms in the
> noise.
I guess (don't know), that 7 ms and 19 ms are caused by a broken HDD,
but when I did the visually test the HDD wasn't broken, I did it a long
time ago.
So the visually test around 4 ms and ALSA MIDI latency test around 4 ms
from today might be correct results for my computer and at least when I
got 4 ms for the visually test, the audible result was unusable for
music, anyway, I still have got some hope.
To be continued ASAP.
On Sun, 2010-07-04 at 22:14 +0100, Dan Mills wrote:
> You could probably hack a multi serial port card to do multiple midi
> ports (Change the rock to give a suitable divider for 31250 baud
> (4MHz?), add current loop interfaces)...
If one is fine with programming on Linux ;).
Hi!
I am trying to fix a problem in beast, where an algorithm (subnormal
cancellation and the associated unit test) will work on "normal" computers, but
not on AMD64, because denormals are treated as zero on this platform with the
compiler options we are using (-ffast-math and others).
So ideally I need a snippet of code (maybe assembler) that will just return
whether the processor/platform will have subnormals, like on x86, or not,
like on AMD64, by querying the processor status registers.
Is there some code around for this?
Cu... Stefan
--
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
Hello all,
A few days ago someone posted a pointer to some
python/numpy audio related code. I wanted to keep
this message and have a look at it later, but my
fingers were too quick... And I don't find that
message in the archives (it could be on LAU as
well).
If anyone still has that message, please send me
a copy !
TIA,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
Cheers for the reply & the commit!
Its a help anyway, I was at 12 errors, now down to 6 errors. (+ 5 warnings).
All the errors seem to be of the same kind. (Something due to accessing
array[2] ?)
I've never written a .vapi and dont really understand all the fancy tricks
you do...
So best job is probably to post the error output after running the command..
command: valac --pkg jack main.vala // my main.vala is just a single
printf statement, no JACK code
jack.vapi:48.36-48.44: error: syntax error, no expression allowed between
array brackets
public int get_aliases(ref string[2] aliases);
^^^^^^^^^
jack.vapi:48.36-48.44: error: syntax error, no expression allowed between
array brackets
public int get_aliases(ref string[2] aliases);
^^^^^^^^^
jack.vapi:270.41-270.47: error: syntax error, no expression allowed between
array brackets
public void get_read_vector(ref Data[2] vec);
^^^^^^^
jack.vapi:270.41-270.47: error: syntax error, no expression allowed between
array brackets
public void get_read_vector(ref Data[2] vec);
^^^^^^^
jack.vapi:271.42-271.48: error: syntax error, no expression allowed between
array brackets
public void get_write_vector(ref Data[2] vec);
^^^^^^^
jack.vapi:271.42-271.48: error: syntax error, no expression allowed between
array brackets
public void get_write_vector(ref Data[2] vec);
^^^^^^^
On Sat, Jun 26, 2010 at 10:25 PM, alberto colombo <vala(a)albx79.it> wrote:
> Hello,
>
> I created a bug to track progress on Jack bindings:
> https://bugzilla.gnome.org/show_bug.cgi?id=576777. I have just committed
> the latest version I had on my HD (dated November 2009), which should
> fix quite a few bugs compared to the version in that email.
>
> Please note that I didn't have the means or the time to test all the
> bindings, therefore expect some memory errors on some functions I
> haven't used. It gives plenty of warning now (it should be updated for
> vala 0.9), but it should compile.
>
> Also, the binding are for version 0.116. If you need features from
> 0.118, they'll have to be added.
>
> Regards
> Alberto
>
> On Sat, 2010-06-26 at 16:04 +0100, Harry Van Haaren wrote:
> > Hey all,
> >
> > I'm learning Vala at the moment, primarily with the intention to develop
> > apps
> > which support JACK audio output. I'm gonna work towards GStreamer based
> > audio routing, and JACK Transport to Start/Stop my app.
> >
> > For the while, I hope to have a play around with JACK using Vala. So I
> went
> > looking for bindings and found the following:
> > http://www.mail-archive.com/vala-list@gnome.org/msg02266.html
> >
> > I've read the replies, installed Jack.vapi into /usr/share/vala/vapi
> > but I cant seem to get rid of some certain errors whenever I compile.
> >
> > Are others using this binding successfully?
> > Any tips / info I should know about when using Jack & Vala?
> > Cheers, -Harry
> > _______________________________________________
> > vala-list mailing list
> > vala-list(a)gnome.org
> > http://mail.gnome.org/mailman/listinfo/vala-list
>
>
>
Hey all,
I'm learning Vala at the moment, primarily with the intention to develop
apps
which support JACK audio output. I'm gonna work towards GStreamer based
audio routing, and JACK Transport to Start/Stop my app.
For the while, I hope to have a play around with JACK using Vala. So I went
looking for bindings and found the following:
http://www.mail-archive.com/vala-list@gnome.org/msg02266.html
I've read the replies, installed Jack.vapi into /usr/share/vala/vapi
but I cant seem to get rid of some certain errors whenever I compile.
Are others using this binding successfully?
Any tips / info I should know about when using Jack & Vala?
Cheers, -Harry
