Is there a way of saving the "special parameters" in Rosegarden with the
project? Specifically I'd like to be able to save the "recording
filters" channel values under "track parameters" but can't figure out
how to do it.
cheers,
Iain
On Sat, 2012-02-25 at 07:04 +0000,
linux-audio-user-request(a)lists.linuxaudio.org wrote:
> Message: 27
> Date: Fri, 24 Feb 2012 20:59:11 -1000
> From: david <gnome(a)hawaii.rr.com>
> Subject: Re: [LAU] Linux 3.2.0-rt Kernels on Debian Repos!
> To: linux-audio-user <linux-audio-user(a)lists.linuxaudio.org>
> Message-ID: <4F4886BF.7040504(a)hawaii.rr.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 02/24/2012 08:16 PM, hermann wrote:
> > Am Freitag, den 24.02.2012, 20:05 -1000 schrieb david:
> >> And the
> >> decision
> >> to replace a "known working product" with a "flaky experimental
> >> product"
> >> makes me question their project management abilities, too.
> >
> > It seems you believe that all the work witch need to be done to make
> a
> > project like debian alive, is done by some auto-magic ? :-))
>
> No, it's not. It's done by people, who make mistakes such as replacing
> a
> known working product with a flaky experimental one.
Hi all :)
please, this shouldn't dwindle into a flame war.
I completely agree with David, but ...
Sometimes I get the impression that the Linux "pro-audio" users and
developers community suffer from Stockholm syndrome, since even "our
community" tend to back up that "pulseaudio" often is a good default,
while it easily could kept optional. Regarding to the NVIDIA issue I'm
perplexed. Some Linux users bought NVIDIA graphics and everything was ok
with the nv driver. It's a silly argument to say, they should buy Intel
now. Should we pollute our children planet with hazardous waste, just to
back up a mistake that easily could be corrected?
Since I'm working for childcare again I've got the money to trash my AMD
mobo and to buy an Intel mobo, but IMO this would be a paradox. Linux
should stand off a thoughtless throwaway society.
Primary components shouldn't be replaced by software that is marked as
experimental and known as not working for many users, if there's
software that's stable.
Regards,
Ralf
Hi
For my own needs I have create a simple jack LADSPA Host/Browser witch
load/switch a single plug-in and create a interface for it.
I use it for quick checks and testing purpose.
Maybe it will be useful for one of you to.
http://sourceforge.net/projects/guitarix/files/web/sila-0.1.tar.bz2/download
greets
hermann
I didn't receive a digest until now, so I'll reply to
http://lists.linuxaudio.org/pipermail/linux-audio-user/2012-February/083601…
We could use the vesa driver, I didn't experienced the vesa driver
neither bad for audio, nor bad for MIDI hardcore-real-time, but it's odd
regarding to the supported resolutions ;), hence I didn't tested it
much.
On my machine, an ASUS M2A-VM HDMI with an integrated ATI Radeon
X1250-based graphics, Athlon dual-core 2.1GHz, I unmounted the HDMI
thingy and mounted a NVIDIA GeForce 7200GS. Using the nv driver I get
the perfect Linux MIDI DAW. Using the nouveau driver I can use it around
two minutes with a slow motion performance for the DE and then I need to
push the reset button, since everything is frozen. I needed to replace
the ATI with the NVIDI, because the integrated ATI can't be used with 3D
acceleration. I don't need 3D acceleration for the kernel-rt, but I wish
to have it supported for a "regular" kernel, since I wish to be able to
google the earth, if I wish to do, to produce 3D animations, if I wish
to do etc.. There's no 3.2.0-rt on my machine, latest kernel I use is
3.0.x.
I didn't decide to use NVIDIA. When I bought my hardware I didn't have
the money to buy Intel, I decided to get ATI, since I used NVIDIA
before. Much of my machine is from bulk garbage.
Here NVIDI is a less PITA than ATI is.
A rose is a rose is a rose. Or: Experimental is experimental is
experimental.
It shouldn't be the policy to drop something that works and replace it
with something that currently is "experimental".
The policy shouldn't be Appel"oid", IOW there should be some "elbowroom"
for the used hardware.
When I (we) get my (our) graphics it (they) works OOTB with Linux DAWs!
:p²
Ralfi
I have an RME Multiface-II with PCI-E card, and I'm thinking about
getting another 6 to 10 analog ins and outs. Since there are so many
people here who are also using RME hardware, I wondered what your
thoughts would be on the best way to do this in a way that's friendly to
Linux, Jack, and the Alsatools Hammerfall mixer app. If possible, I'd
like to still be able to run at 96kHz, so if it involves using the ADAT
port, it will probably involve having to use SMUX and only have 4 i/o's.
I've also heard it mentioned that one can add another Multiface and a
second PCI-E card, but I don't know whether that is supported on Linux.
I think there is a way to clock-sync the two if you do that, and I don't
know about seeing them both in the mixer. It'd be really nice if I
could end up with 16 analog i/o's and nice AD/DA converters.
What do you think is the best way to get to that point for a Linux DAW
machine? This is RME, so I'm sure it's got to be possible...
--
+ Brent A. Busby +
+ Sr. UNIX Systems Admin + Vote for Cthulhu.
+ University of Chicago +
+ James Franck Institute + Why settle for the lesser evil?
These are my first netjack experiments, ever.
I followed this reference:
http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack
Here is what I did:
#### sound server side (with local soundcard)
$ jackd -d alsa hw:0,0 -r 44100
$ jack_netsource -H thinkpad
Connected :-)
netjack: at frame 000051 -> total netxruns 1 (1%) queue time= 93121
$ ecasound -i test.wav -o jack,system
[ sound plays ]
^C
#### client side
$ jackd -d netone
NetOne driver started
AutoConfig Override !!!
AutoConfig Override: Master JACK sample rate = 44100
AutoConfig Override: capture_channels_audio = 2
AutoConfig Override: capture_channels_midi = 1
AutoConfig Override: playback_channels_audio = 2
AutoConfig Override: playback_channels_midi = 1
MTU is set to 1400 bytes
$ jack_lsp
system:capture_1
system:capture_2
system:capture_3
system:playback_1
system:playback_2
system:playback_3
$ ecasound -i cdda.wav -f f32_le,2,44100 -o jack,<CLIENT>,<TRANSPORT> -c
for TRANSPORT settings: send sendrec notransport
for JACK CLIENT setting: "system" and "system:playback_1"
The transport stays stuck at position 0.0, and the
'start' command does not start the engine,
which remains in status 'stopped'.
Grateful for ideas where I should go next,
Thanks,
--
Joel Roth
Hello,
I'd like to use controllers, that send OSC via Wifi with synths on Linux.
Is there any OSC receiver available, that can fetch OSC and route it to
aware applications?
Preferably including the capability to convert the incoming messages to
MIDI to be used with Alsa and/or Jack MIDI?
Crude workarounds are welcome too, as long as they somehow do work ;-)
best regards
HZN
New flash! First time I have seen such a thing. On Debian SId (unstable).
The two dkms modules I have:
Vboxdrv.ko built fine!
Nvidia kernel module does not build correctly: Make.log ends with: Building
modules, stage 2.
MODPOST 1 modules
WARNING: could not find /var/lib/dkms/nvidia/295.20/build/.nv-
kernel.o.i386.cmd for /var/lib/dkms/nvidia/295.20/build/nv-kernel.o.i386
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'migrate_enable'
make[4]: *** [__modpost] Error 1
make[3]: *** [modules] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.2.0-1-rt-686-pae'
make: *** [modules] Error 2
make: Leaving directory `/var/lib/dkms/nvidia/295.20/build'
There have been past problems with nvidia stuff compiling for rt kernels which
was fixable in the source. The above looks like something else! Something can
be overridden to get this to modpost?
Anyway, a small step for -rt, a big step for linux audio :-)
(No objection to running nouveau but it is problably no good enough for DAW
software which often has animation, i.e. meters, etc.)
> Message: 6
> Date: Wed, 22 Feb 2012 19:36:47 +0100
> From: hermann <brummer-(a)web.de>
> Subject: Re: [LAU] Linux 3.2.0-rt Kernels on Debian Repos!
> To: David Baron <d_baron(a)012.net.il>
> Cc: linux-audio-user(a)lists.linuxaudio.org
> Message-ID: <1329935807.2158.7.camel@box>
> Content-Type: text/plain; charset="UTF-8"
>
> Am Mittwoch, den 22.02.2012, 19:24 +0200 schrieb David Baron:
> > New flash! First time I have seen such a thing. On Debian SId
> (unstable).
> >
> > The two dkms modules I have:
> >
> > Vboxdrv.ko built fine!
FWIW, it also builds fine on Arch Linux:
spinymouse@oz:~$ ls /mnt/archlinux/lib/modules/3.0-rt/extramodules
vboxdrv.ko.gz vboxnetadp.ko.gz vboxnetflt.ko.gz vboxpci.ko.gz
Arch Linux still provides the nv driver.
Greetings fellow Linux audio folk,
Some unknown handful of you (Julien Classen for sure at one point) may have
used 'jackctl.py' for CLI starting of a JACK server and making JACK
connections.
I've now renamed the project 'CLIJACK' because it appears there's an
unrelated script called 'jackctl.py' in the sources for JACK itself, and I
wanted to avoid any confusion. CLIJACK is a little Python app that serves
as a user-friendly command-line frontend to jackd, jack_connect, and
aconnect. It allows one to quickly and efficiently connect jack ports, alsa
midi ports, jack midi ports, etc. in the manner of QjackCtl, but without
the GUI, and the possible bloat of the packages required by the same. Good
for lean 'n mean systems, etc.
So, CLIJACK is now being released, new title, a bit of new code...I did
some code cleanup today, the biggest changes being:
* From CLIJACK, the jackd server itself can be launched via an environment
variable, CLIJACK_COMMAND. Using this, one can start or stop the server
from within CLIJACK via the 's' command. This of course was the same in
'jackctl.py', however, one had to edit the 'jackctl.py' script itself to
change the jackd command; now, it's modular and removed into the user's
environment.
* Non-critical alerts from jackd do not interrupt the interface of CLIJACK
anymore (example: missing libffado, etc.)
* More sensible killing of the jack server from within CLIJACK, including
sending a killall message....
* More use of newlines to make multi-lined messages prettier and cleaner.
I will eventually get the project correctly packaged onto the Python apps
listings, and sourceforge, etc., but for now, you can download the script
directly from my site if you're interested:
http://www.akjmusic.com/software/clijack-20120223.py
I'd love feedback!
Aaron Krister Johnson
http://www.akjmusic.comhttp://www.untwelve.org