Hello all,
A number of system here, including the ones at the Casa
del Suono are to be upgraded in the coming weeks.
At the moment they all run Fedora 8, so the first choice
would be to go for Fedora 11. But:
* None of them will run Gnome or KDE.
* Most will be headless anyaway.
* I want access/privilege control to be based on
user and group ID and nothing else. Privileges
will never depend on the user having a local
login or desktop session.
* I'm prepared to have to spend some time configuring
udev, pam, /etc/fstab etc. etc. etc.
* What I certainly *do not want* is some parallel
access control system that would interfere with
the above, or that could modify/bypass/enhance
in any way what has been configured there.
* I'm *not* really prepared to have to waste any time
reconfiguring the Kit family. Consequently I don't
want to see any of them.
So what distro should I go for ? Having to spend weeks
compiling everything from source is not an option.
Anyone able to point in the right direction will receive
my eternal gratitude which could be expressed in quantities
of fine Italian food and drinks if the occasion arises.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Here's a story that may give you all a good chuckle:
Last weekend Robin Gareus, our LAO guru has contacted me inquiring why there
was a ~1hr linuxaudio.org server downtime that took place that Sat. morning.
Luckily we now have an UPS that gives us almost 2 hours of offline power.
Hence, the server went through this unscathed. Yet, the network
infrastructure was also down so even though the server remained up, there
was no way of reaching it.
So, I went investigating what happened, and this is the reply I got from our
on-campus support:
Squirrel fried in transformer. Campus and part of downtown was out of power
on Saturday morning before the game. [this was a football game we had in
town that day with 10K+ visitors]
:-)
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
In the new jack API the function jack_client_new ist deprecated.
Actually it's not only deprecated:
Apps using it don't play any sound,
as I've experienced with alsaplayer, and fluidsynth for example.
I'm thus inviting
1. to change all apps which still use jack_client_new to use this instead:
//jack_client_t*
jclient = jack_client_open( name, //jack_options_t
JackNullOption, //jack_status_t * status
NULL
);
2. to make the new jackd work with jack_client_new for some time
still, until most apps have adjusted their code
Thanks for the advertence.
Hi,
i would like to know if somebody has already thought about a (unified)
way to save or export the settings of ladspa plugins (or vst,lv2..)
I'm familiar with the idea of LASH, but i want to share plugin settings
between different sessions. A typical use case:
After recording songs with my drumset, the gate-plugin applied to
basedrum and snare has most times (nearly) the same setting.
At the moment this is a quite painful task: Ardour is able to save the
settings, but you can't export these or exchange them between other
applications.
In addition, ardour's ladspa plugin dialog can just save the settings,
changing an already saved settings is not possible. This results in a
heap of saved settings and old revisions..
It would be great to export these settings, it could be implemented as a
feature in applications like ardour2 ,jackrack or hydrogen.
After exporting the setting to a plain text file (or xml), sharing the
file with other people or between your computer would be no problem.
What are your thoughts on this? What are the disadvantages?
Thanks,
Sebastian
Hi,
I'm looking into doing some real time MIDI programming with either C++
or Common lisp.
I would specifically not schedule anything but deliver everything as
"play it right now" notes.
Is it necessary to use realtime scheduling the way JACK does?
Or is it ok to use normal "user mode" programs?
Your expert advice much appreciated!
Carlo
Completely agree that SYSEX is where this kind of functionality should reside.
This use of 0x7d is a bit antiquated, no? The reassignment of 0x00 to indicate 3 byte
SYSEX ID means there is a bit more flexibility in the system. Currently the following
are assigned:
0x00 0x00 0xXX American group
0x00 0x01 0xXX American group
0x00 0x20 0xXX European group
0x4X Japanese group (with holes)
0x5X Japanese group (with holes)
0x00 0x04 Japanese group
Getting a registration requires it be paid for, pretty ludicrous for what purports to be
an open standard. I would suggest that Open Source developers should simply take
one of the unassigned values for its own first digit, agree between themselves who
get the next two digits for their apps and SYSEX then be sent with 3 byte ID.
SLab hijacked 0x53 about 10 years ago for this purpose and bolted on a three more
digits for personal identification and there is little reason why this should not be done
again, this time in line with the current MMA SYSEX ID defs as above? If open source
goes and squats on 0x7d then everybody can go and haggle over which app gets the
next two digits.
There is probably going to be some complaints that SYSEX require an extra two
bytes and how that is going to degrade system performance at 31.25KHz, which
probably needs a pre-canned response as it is a non-issue.
This discussion is perhaps better aimed at LAD rather than LAU: LAU justs wants it
to work, LAD can horsetrade on the details.
It is possible that the MMA will take an issue with this since it does not actually fit
within the new SYSEX ID specs (0x7d has not been assigned in the new definition)
but I am pretty sure that if open source applications restrict themselves to their own
set of second and third digits then the MMA will not be so daft as to assign that
number to any manufacturer. For the apps that eventually go commercial then
it is their job, as a part of the commercialisation, to formally request their own ID
from MMA and then to recognise both of them if desired - the MMA assigned one
thanks to paying $$$ for the number, and the squatted ID for compatibility purposes.
Now, to tie this back into the original subject: this does not really help with assigning
MIDI controllers back to app controls as now the surface has to be configured to
generate more complex SYSEX messages, neither easy nor even possible with some of
them, but the argument of applications getting screwed by using the same number
is actually very easy to avoid, admittedly as long as it is done unanimously. Perhaps
linuxaudio.org might want to pick up the gauntlet of assigning the open sourced
digits?
Regards, nick
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
> Date: Mon, 5 Oct 2009 19:19:17 +0200
> From: fons(a)kokkinizita.net
> To: linux-audio-user(a)lists.linuxaudio.org
> Subject: Re: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
>
> On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
>
> > The MMA requires that you use a registered manufacturer ID, but only for
> > commercial products. There is a special ID = 0x7D that is intended for
> > educational or development use only, and should never appear in a commercial
> > design.
>
> Where it is silently assumed that 'educational' and 'development'
> implies 'not distributed', or at least 'never used together with
> any other app using the same ID'.
>
> If two or more open source programs use 0x7D and they happen to
> see the same MIDI stream then one of them will be screwed.
>
> Ciao,
>
> --
> FA
"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer
> Date: Mon, 5 Oct 2009 19:19:17 +0200
> From: fons(a)kokkinizita.net
> To: linux-audio-user(a)lists.linuxaudio.org
> Subject: Re: [LAU] So what's the deal with controlling the aeolus organ?stops via midi
>
> On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
>
> > The MMA requires that you use a registered manufacturer ID, but only for
> > commercial products. There is a special ID = 0x7D that is intended for
> > educational or development use only, and should never appear in a commercial
> > design.
>
> Where it is silently assumed that 'educational' and 'development'
> implies 'not distributed', or at least 'never used together with
> any other app using the same ID'.
>
> If two or more open source programs use 0x7D and they happen to
> see the same MIDI stream then one of them will be screwed.
>
> Ciao,
>
> --
> FA
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…
Hello *,
I am electronic engineer and used the AD1983, AD1984 and AD1988 in some
of my projects. Unfortunately Analog Devices is droping the porduction
next month and there is no replacement.
Please, can someone recomment other manufacturers for High Definition
Audio CODECS which works PERFECTLY with Linux/ALSA?
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
<http://www.tamay-dogan.net/> Michelle Konzack
<http://www.can4linux.org/> Apt. 917
<http://www.flexray4linux.org/> 50, rue de Soultz
Jabber linux4michelle(a)jabber.ccc.de 67100 Strabourg/France
IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947
ICQ #328449886 Tel. FR: +33 6 61925193
Hi,
I am writing a ladspa host, some kind of modular synth with a python front-end.
In terms of the scheduling algorithm, I was just going to do a topological sort
and then run each plugin from the sources to the sinks. If there is a loop (does
this even make sense?), well i'm not sure what to do there, perhaps it is up to
the script to specify the order.
The other thing I noticed is that plugins are expected to completely fill and/or
drain their buffers (ports). Doesn't this mean it's impossible to make a resampling
plugin with LADSPA ?
Simon.
Fall is upon us.
Summer is gone. Trivial speaking, as it marks yet one's another
birthday, mine that is. It also marks the approaching bankruptcy of this
funny F&D release code-names. One can also think as the last and stable
release before a probable next generation do break all loose. Automation
and full MIDI control is popping up over the horizon. So take all
children home and be prepared for the worst. Nah, don't be that afraid.
With some help from good friends, everything can and shall be arranged.
No second thoughts. No hard feelings. Meanwhile...
Qtractor 0.4.3 (fussy doula) released!
Release highlights:
* Audio send/return aux. inserts (NEW)
* Mixer peak meters gradient eye-candy (NEW)
* MIDI System Exclusive (SysEx) setup manager (NEW)
* MIDI Playback/Queue timer resolution option (NEW)
* MIDI Instrument definitions from SoundFont 2 files (NEW)
* MIDI Output bus default instrument (NEW)
* Buses dialog manager update (FIX)
* Plugin references by label (FIX)
* First audio metronome beat/bar (FIX)
* Ghost clip selections (FIX)
* Overlapping MIDI clips (FIX)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.4.3.tar.gz
- source package (openSUSE 11.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.3-1.rncbc.suse111.sr…
- binary packages (openSUSE 11.1):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.3-1.rncbc.suse111.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.4.3-1.rncbc.suse111.x8…
- binary packages (Ubuntu 8.04 LTS):
http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu804_…http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu804_…
- binary packages (Ubuntu 9.04):
http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu904_…http://downloads.sourceforge.net/qtractor/qtractor_0.4.3-1.rncbc.ubuntu904_…
- user manual (ever still outdated):
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- External preset files are not removed nor deleted from the file-system
anymore.
- Connections support for UTF-8 encoded client/port names.
- Force track and clip properties dialog widget to be modal as it should
from their beginning dawn.
- Audio effect send/return aux. inserts are implemented as special
pseudo-plugins (Plugins/Inserts).
- Reset play-head position on auto-backward and keep playback rolling
when continue past end transport option is not set.
- MIDI clip editor (aka piano-roll/matrix aditor) gets better on the
virtual piano keyboard eye-candy side of things ;).
- Plugins are now also referenced by label, avoiding plugin index
clash/misses eg. when plugin object file/path changes or is moved
externally.
- Keyboard focus is now cleared/reset from the main toolbar time and
tempo spin-boxes when editing gets finished (eg. Enter key is pressed).
- First audio metronome beat/bar now played back correctly (fixes bug
#2841437).
- Client to/from port (dis)connections now found consistent as good
ol'QjackCtl behavior (fixes bug #2834657).
- All dirty open MIDI clip editors are now prompted to save before the
main application closes (fixes bug #2835516).
- Mixer level meters get their long deserved gradient look.
- Fixed any ghost clip selections that were haunting the main track
view, specially after undo/redo.
- Increased tolerance on reading corrupt MIDI files (SMF).
- A MIDI SysEx manager is being finally introduced, in some primordial
rather basic form though. MIDI System Exclusive (SysEx) event strings
may now be freely assigned to MIDI output buses only, allowing for
proper setup of external outboard MIDI equipment. Each bus may have an
unlimited SysEx queue that gets sent out on every connection change (see
View/Buses.../MIDI/SysEx...).
- A default MIDI instrument name may now be assigned to any MIDI output
bus (see View/Buses.../MIDI).
- More legacy headers, stdio.h and stdlib.h, are yet again necessary to
build with gcc/g++ >= 4.4 (as patch noted by Alexis Ballier on Gentoo
bug report #274168, thanks).
- Bus manager dialog (View/Buses...) gets new columns on the left pane
buses list as for displaying number of channels and bus mode.
- Crash when updating bus probably fixed (bug #2811630).
- Fixed glitch displaying beat snap/grid lines on MIDI clip editor,
incidental to clips located at absolute zero time.
- Overlapped MIDI clips were rendering garbled note events to DSSI/VSTi
plugins, now fixed.
- New MIDI Playback/Queue timer (resolution) option is now available
(see View/Options.../MIDI).
- MIDI instrument definitions may now be imported from plain SoundFont
files.
Cheers && Enjoy.
--
rncbc aka Rui Nuno Capela
rncbc at rncbc dot org
http://www.rncbc.org
On Monday, October 5, 2009, Fons Adriaensen wrote:
> On Mon, Oct 05, 2009 at 07:00:40PM +0200, Pedro Lopez-Cabanillas wrote:
> > The MMA requires that you use a registered manufacturer ID, but only for
> > commercial products. There is a special ID = 0x7D that is intended for
> > educational or development use only, and should never appear in a
> > commercial design.
>
> Where it is silently assumed that 'educational' and 'development'
> implies 'not distributed', or at least 'never used together with
> any other app using the same ID'.
>
> If two or more open source programs use 0x7D and they happen to
> see the same MIDI stream then one of them will be screwed.
The only devices or programs that would be screwed are those bad or poorly
designed/written.
In addition to the manufacturer ID, there should be enough additional bytes to
uncertainly identify a particular model among others using the same
manufacturer ID. The device (soft in this case) receiving a message should be
able to distinguish between legitimate and spurious messages using the model
ID bytes, checksums and/or some other mechanism.
Regards,
Pedro