Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

[ANN] Qtractor 0.4.1 (funky dominatrix) unleashed!

by Rui Nuno Capela

Hi There are bugs which are resilient. One is never sure whether squashing one doesn't let a plethora of lurking others get loose, like one's skeleton in the closet falling apart. Paraphrasing Linus' Law, after ESR: given enough eardrums all bugs are shallow. Thanks to all the brave souls who keep harnessing the toy to the bone, some of those nasties could be whipped off. At least for the time being ;) Trivially speaking, this dot-release marks the 4th anniversary of Qtractor as an active/personal project and, putting numerology to the side, it is being released on this April, 4th (04/04). But then, I do confess, this was just reckoned as an accidental after-thought, as everything in numerology, I guess :) Although only one developer is still responsible for 99% of the code (that's me!:), there's some outsourcing (kind of) shaping and already pending in its early stages: MIDI event list editing; Windows native VST plugin support, much in the lines of FST/WINE, as in Ardour, perhaps; a new logo and/or splash-screen design is also under this way. Keep in mind that all translations will be asked only after the end of the current alpha phase, whenever it would be an end to it :P Most importantly, there's serious help being needed on drafting the user manual. The current one available is getting outrageously outdated, ever since the 0.2 situation. It's already getting tough to play catch up. And everyone knows about developer(s) not feeling like doing documentation in the first place. Move on. The more participation the better. In general, if you ever feel like, please pick up your favorite line on the ever still TODO list and do step in. You'll be more than welcome: eardrums, which usually come in pairs, just like eyeballs do, are pretty wanted! So dress up your blacky leather and vinyl, put up the spiky collars and whip it, whip it good B) Here we go: Qtractor 0.4.1 (funky dominatrix) unleashed! Release highlights: * MIDI editor snap grid. (NEW) * Multi-clip selection normalize and quantize (NEW) * Audio export & sample-rate conversion (FIXED) * MIDI & audio playback sync (FIXED) * SSE optimization enabled (FIXED) * and a few more fixes and same lurking bugs ;) Same old intro/description: Qtractor is an audio/MIDI multi-track sequencer application, written in C++ on top of Qt Software's Qt4 framework, having JACK and ALSA as its main infrastructures and Linux as native and exclusive platform. Specially suited to the lone-wolf composer, arranger and (re)creative music-maker personal home-studio, it still hopes to evolve as a fairly featured desktop audio/MIDI workstation or at least, a prototypical part of it ;) Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball http://downloads.sourceforge.net/qtractor/qtractor-0.4.1.tar.gz - user manual (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. Features: - Multi-track audio and MIDI sequencing and recording. - Developed on pure Qt4 C++ application framework (no Qt3 nor KDE dependencies). - Uses JACK for audio and ALSA sequencer for MIDI as multimedia infrastructures. - Traditional multi-track tape recorder control paradigm. - Audio file formats support: OGG (via libvorbis), MP3 (via libmad, playback only), WAV, FLAC, AIFF and many, many more (via linsndfile). - Standard MIDI files support (SMF format 0 and 1). - Non-destructive, non-linear editing. - Unlimited number of tracks per session/project. - Unlimited number of overlapping clips per track. - XML encoded session/project description file. - Point-and-click, multi-select, drag-and-drop interaction (drag, move, drop, cut, copy, paste, delete, split) - Unlimited undo/redo. - Built-in mixer and monitor controls. - Built-in connection patchbay control and persistence (a-la QjackCtl). - LADSPA, DSSI and native VST plug-ins support. - Unlimited number of plug-ins per track or bus. - Plug-in presets, programs and chunk/configurations support. - Audio/MIDI clip fade-in/out (linear, quadratic, cubic). - Audio/MIDI clip gain/volume, normalize and export. - Audio clip time-stretching (WSOLA-like or via librubberband), pitch-shifting (also via librubberband) and seamless sample-rate conversion (via libsamplerate). - Audio/MIDI track export (mix-down, merge). - Audio/MIDI metronome bar/beat clicks. - Unlimited tempo/time-signature map. - MIDI clip editor (matrix/piano roll). - MIDI instrument definitions (a-la Cakewalk(tm)) - JACK transport sync master. - MMC control surface enabled. - MIDI Song Position cueuing support. - Configurable keyboard shortcuts. Change-log: - MIDI editor command item execution order has been fixed, correcting the redo/undo adjustment of overlapping note events (probably fixing bug #2723861). - MIDI clip editor (aka. piano-roll/matrix editor) sees one of its most wanted features introduced: visual snap grid, now accessible through View/Snap/Grid option toggle. - Actual non-zero session length gets back to status bar of main application window. - One potential buffer-overflow/memory-corruption crash bug has been fixed, long due on most audio (down) sample-rate conversions and affecting audio export in particular. - MIDI track/channel patch information, ie. bank-select and program-change events, are now being properly set on MIDI track/clip export. - SSE optimization is back in town after being mysteriously disabled since its dawn :/ - Looping and punch-recording now actively mutual exclusive states: setting either one unsets the other off and vice-versa. Also, punch-in/out is now made an undoable command. - Moving tracks, any track, up or down, were leaving MIDI playback and meter monitoring completely out-of-sync, now fixed. - Automatic crash-dump reports, debugger stack-traces (gdb), back-traces, whatever, are being introduced as a brand new configure option (--enable-stacktrace) and default enabled on debug build targets (--enable-debug). - Audio/MIDI drift correction is now progressive, taking a least significant differential approach, on every read-ahead cycle and swallowed on loop turn-arounds, as before. - Improved Edit/Clip/Normalize and Quantize commands, now affecting the whole extended multi-clip selection. - Playback is now being temporarily suspended while either transport rewind or fast-forward rolling is engaged. - A bad and shame-on-me bug was fixed: this was hideously affecting any track/clip playback synchronization, most noticeable after toggling solo/mute track states while playback is rolling and skipping the play-head backward over more than one clip under the same track. - A floating-rectangle flip that showed while dragging new files beyond the left of main track view is now gone. - MIDI note event truncation on both track and clip export has been fixed. Cheers && Enjoy! -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

16 years, 5 months

Re: [LAD] jack_midi in jackd and jackdmp

by hermann meyer

Am Freitag, den 03.04.2009, 20:57 +0200 schrieb Stéphane Letz: > > Now, it work with jackdmp, great, > > > > So the Question comes in mind, why need I to register the midi port as > > first one ? Anyone experience the same behaviour ? Or is it just a > > effekt from a hidden bug ? mmm > > > > regards hermann > > > > _ > > Maybe, but could you extract the "crashing" code in a simpler test > client? It would help. > > Thanks > > Stephane I will do that, but dont get me wrong, speak about a posible bug in my code, not in your's. Jackdmp is realy nice, fast and light, that why I wont be able to run it with my app. And sorry, it will posible take some day's, my work try to eat me . . . thanks hermann

16 years, 5 months

Re: [LAD] Build and get your package in Debian/ Ubuntu (was Re: [LAU] Join the Debian Multimedia Team! (to improve the state of Linux audio))

by Grammostola Rosea

Dennis Schulmeister wrote: > Hi, > > On Wed, 2009-04-01 at 14:48 +0200, Grammostola Rosea wrote: > >>> 3. Documentation - especially man pages which are required for all >>> binaries (even if they just refer to online documentation or info >>> pages). This requirement is often skipped for Ubuntu-only packages which >>> makes me as a user sad. >>> >> Yeah an manpage is required. You can use the app gmanedit for example to >> create one. >> > > I really got accustomed to help2man because creating man pages is a snap > with it. All it takes is the following: > > * A sanely formated text file (w/ optional troff commands) > What is a sanely formated text file and what do you mean with (w/ optional troff commands)? > * Your program's --version string > * Your program's --help string > > That's it. With such tools available there's really no excuse for not > having a man page. > > > > Yours sincerely, > Dennis Schulmeister > >

16 years, 5 months

Re: [LAD] Build and get your package in Debian/ Ubuntu (was Re: [LAU] Join the Debian Multimedia Team! (to improve the state of Linux audio))

by Grammostola Rosea

Dennis Schulmeister wrote: > Hi, > > On Wed, 2009-04-01 at 14:48 +0200, Grammostola Rosea wrote: > >>> 3. Documentation - especially man pages which are required for all >>> binaries (even if they just refer to online documentation or info >>> pages). This requirement is often skipped for Ubuntu-only packages which >>> makes me as a user sad. >>> >> Yeah an manpage is required. You can use the app gmanedit for example to >> create one. >> > > I really got accustomed to help2man because creating man pages is a snap > with it. All it takes is the following: > > * A sanely formated text file (w/ optional troff commands) > * Your program's --version string > * Your program's --help string > > That's it. With such tools available there's really no excuse for not > having a man page. > > > Thanks for the tip! What do you think, should an upstream author take care of the manpage or the package maintainer? \r

16 years, 5 months

Join the Debian Multimedia Team! (to improve the state of Linux audio)

by Grammostola Rosea

Hi, Many of the people of the Linux audio community uses Debian or a Debian based distro (Ubuntu (Studio), 64Studio, Musix, Sidux, Mepis etc. etc.). Most of those distro's uses and rebuild the packages of Debian (unstable). There are a lot of audio packages build by the Debian Multimedia Team, but there are also a lot which are not in Debian yet (and so also not in Ubuntu (Studio), Sidux, 64studio etc.) So there is a need for more people who wants to contribute to the Debian Multimedia Team. Again, you don't have to be a plain Debian user to contribute or to take advantage of it. You will help to improve the state of Linux audio in general (at least the Debian based distro's and their community), which will be good for us all, but also for newbies who are not able yet to build all the packages themselves to enjoy all the nice things Linux audio has to offer. Also note that it is possible to build Debian unstable packages on other distro's then Debian itself (search for Pbuilder on the Internet for instance)! It will also be good for the Linux audio developers and their software. It would be more easy to install, use, test and enjoy the software by the Linux audio community! There are a lot of people these day who has an own (PPA) repo. This is ok, (and maybe it will be a good thing if the Linux audio developers make their packages available as much as possible in a Debian unstable repo/package, so it can be used on Debian and it is easy to rebuild it for Debian based distro's), But to bundle forces and to get safe, stable and quality packages, joining the Debian Multimedia Team will get much better quality packages and you will help far more people then having your solo private repo... *Why the Debian Multimedia Team? * 1) Because they want to improve Debian for music production! 2) Debian has an flexible, fast and easy package management 3) A lot of people use Debian (based) distro's, Debian itself, Ubuntu (Studio), 64studio, Sidux, Mepis etc. 4) You will learn to build quality packages 5) You don't have to become a Debian developer (DD), you can just become and stay a package maintainer. *What can I do?* 1) Build or improve packages for the Debian Multimedia Team. It's recommended to maintain packages you use yourself often. 2) Report bugs and wishes 3) Join the Debian multimedia team mailing list: http://lists.debian.org/debian-multimedia/ *Where can I find more info?* Wiki: http://wiki.debian.org/DebianMultimedia Packaging: http://wiki.debian.org/DebianMultimedia/DevelopPackaging Existing packages which needs help: http://wnpp.debian.net/ Debian New Maintainers' guide: http://www.debian.org/doc/maint-guide/ (!) Bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-multim… It would be great if you choose one package which you uses a lot and maintain it for the Debian Multimedia Team! It would improve the quality of Linux audio and it will help the whole community! Kind regards, \r ps. If you like to join, please subscribe to the Debian Multimedia Team mailinglist and ask for more information: http://lists.debian.org/debian-multimedia/

16 years, 5 months

Programming for Lilypond (how to become an developer)

by Grammostola Rosea

Hi, I'm just an Lilypond user, not an programmer. I really think Lilypond is a core app for GNU/Linux musicians and many apps has Lilypond export functions. To keep improving Lilypond and because some people are starting to work on some Tablature improvements, which makes me really excited, I thought, let's make a call. Maybe you are a Lilypond user with a little programming background and want to contribute to Lilypond or you need a special feature/ improvement in it. Then you can start learning to do the programming yourself. You can start as a Frog, some kind of 'Lilypond student programmer'. You start learning the basics, maybe fix some bugs (like Frogs eat flies) and add some features you want with the help of the Lilypond developers. More info about developing for Lilypond: http://lilypond.org/web/devel/participating/ You can see the Contributors' Guide for some detailed information about participating: http://lilypond.org/doc/v2.13/Documentation/devel/contrib-guide/index#index At this moment there are some guys beginning to work on more and better Tablature functionality for Lilypond. Which is great imo also to get better Tablature functionality in GUI apps like Mscore and Tuxguitar. So maybe it's a good moment to jump in, and I think they can use some man power! See for example these threads: http://www.nabble.com/guitar-tab-feature-request-td21995370.html Thanks in advance, \r (Just an happy Lily user/ guitarist)

16 years, 5 months

qjackd goes funkity

by Gene Heskett

Greetings all; 1: I installed the jack suite about a week ago, recommended by a friend and I've had it grab core0 of my quad core phenom and loop at 100% several times, however, using qjackctl to stop and restart it always fixes it. Is there a buglet still around? 2: I have kmail set to play its usual pling as incoming mail arrives, and since I installed jack, its quite distorted and just a nearly mote whisper. Is this a possible config error? It may be that 1 above is related to 2 above as it seems to occur at some point when the machine is quiet for the night, but fetchmail/procmail/kmail is still running, so it would be getting tapped at that input several hundred times by the time I get up the next morning. Comments/hints welcomed. Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I have replaced NT with Linux. Linux -- heir of the byte that dogged me. -- Allan Willis

16 years, 5 months

Question: broadcasting OSC messages

by Pau Arumí

Hi all! I have a simple question about OSC, or more specifically, the liblo implementation: Is it possible to broadcast OSC messages to multiple receiving ends *in different processes*? That is, without needing to create N 1-1 communication channels, using N ports? The obvious thing would be to create two servers listening to the same port (using lo_server_thread_new ). But liblo doesn't allow creating two servers listening the same port. Ideas to work-around this? P

16 years, 5 months

qjackd Q

by Gene Heskett

Greetings all; I have used the kde audio prefs to place Jack at the top of the priority list, my audigy 2 stuffs next, with esd and pulse at the bottom. Everything seemed to work ok, but I noticed last night after I had watched some news on cnn with firefox-3.0.7, that qjackd was using an average of 50% of all 4 cores on my amd phenom, but no sound was being played at the time and the speakers were silent. Calling up qjackctl and doing a restart seems to have fixed it. Bug? Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Duty, n: What one expects from others. -- Oscar Wilde

16 years, 5 months

Re: [LAD] [Fwd: Re: realtime kernel for Debian]

by Grammostola Rosea

Hi, Sorry, but I've to call again... The developers seems very willing to include a realtime kernel there repo. They need some people who wants to build and maintain it. This is really a chance for linux audio, especially on Debian. *This is the moment!* So please consider to offer your help in building, maintaining and/or testing! Thanks in advance, \r Grammostola Rosea wrote: > Grammostola Rosea wrote: >> Hi, >> >> There is an promising discussion on the debian-dev mailinglist. Maybe >> some people who knows more about realtime kernels could join. Also >> users who might want to have an realtime kernel in Debian and/or want >> help testing could join the discussion. I think it would be nice if >> there is also an realtime kernel in Debian or that the default kernel >> would be improved for realtime (audio) usage. >> >> >> http://www.debian.org/MailingLists/subscribe > Here is the thread about a realtime kernel in Debian: > > > http://www.linux-archive.org/debian-development/268999-realtime-kernel-debi… > > > > Kind regards, > > \r > > > > >> >> \r >> >> ------------------------------------------------------------------------ >> >> Subject: >> Re: realtime kernel for Debian >> From: >> "Giacomo A. Catenazzi" <cate(a)debian.org> >> Date: >> Tue, 24 Mar 2009 13:26:35 +0100 >> To: >> debian-devel(a)lists.debian.org >> >> To: >> debian-devel(a)lists.debian.org >> >> >> Raphael Hertzog wrote: >>> On Tue, 24 Mar 2009, Giacomo A. Catenazzi wrote: >>>> Do you really need real time kernel? >>>> Debian is a technical driven project, but reading the previous two >>>> quotes, >>>> "real time" is used as marketing thing. >>> >>> It's good to question the use of any feature, but a real-time kernel is >>> certainly very useful in many industrial applications and Debian is >>> popular in that field. (Don't put a marketing label on anything where >>> you are not yourself sure of your expertise.) >> >> Yes, I didn't write very well my sentence: the previous quotes was more >> about "there exist rt kernels", "ubuntu has a rt kernel", but not solid >> requirements. I had to write some "seems", and I'm sorry for the two >> quoted people if it seems an attack. >> Anyway, later in the mail, I asked for precise needs, so we could see >> better what we should improve. >> >> IMHO most users want a low latency kernel, but not a slower kernel, so >> a CONFIG_HZ_1000 would be nice. But the original post was about >> multimedia production (and not reproduction), so the needs are probably >> other. >> >> My point was more: >> - Debian has not rt kernel. Why? Non DD interested or/and low demand? >> This is an important point. We must not produce a rt-kernel if >> we cannot provide testers and developers (in unstable). >> - kernel management is a weak point in distribution: no good method >> for kernel dependencies, using full capabilities, ... >> >> so IMHO we should try harder with the normal kernel, so that we >> can use the same infrastructure and testers. If we fail and we >> are able to support rt kernels, IMO it is good to provide it in Debian. >> >> The original mail was about "multimedia production" and few year ago >> kernel >> developers had a lot of interaction with music industries. >> I'm not an expert in the field, but how far are we in their need with >> standard kernels?) >> >> >>> I do use a real-time kernel on a Debian based system for one of my >>> customers (but I have to recompile the kernel anyway because I do other >>> customizations) and I have good reasons to do so because I can't suffer >>> serial overrun and I must ensure that the serial interrupt handler >>> is run in the required time and that no other (kernel) task has higher >>> priority. >> >> These *other customizations* are important to rt-kernel. So we need >> a person (or more) that know the needs and could support us. >> "realtime" alone is only a label ;-) >> >> ciao >> cate >> >> > >

16 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev