Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by warjamy＠yahoo.com

discussion started at LAD about changing the jack server latency from the app called guitarix (like ardour does from its menu JACK -> Latency). Proposed guitarix patch (by me) works nice against jack2 but not against jack1. See below. Hermann, I quickly ran guitarix in debug mode through gdb. You get a crash at dsp_audio.cpp, line 469. Looks like memory at output[2] and output[3] cannot be accessed. I tried to understand what you attempt to do but this function (mydsp::compute) is way to much for me to understand. It looks like some sort of auto-code ... Anyway, output[2] and output[3] are passed in from process() (process callback function). I believe these arrays should correspond to buffers that you receive from jack audio ports 2 and 3. However, at the time we try to change the latency, they are already unregistered because of DSP.setNumOutputs(). So it looks to me that resetting the jack buffer size on the fly from guitarix badly interacts with how jack1 handled your port deregistration requests. I don't know why it works with jack2. Running guitarix through gdb against jack2, I could see that output[2] and output[3] were still valid memory locations after changing the jack buffer size on the fly. This is a bit unfortunate that we get different behaviors when using jack1 or jack2. I hope you'll sort it out, I don't have more time to spend on it. J. PS: by the way, be careful with hardcoded values. On one hand you have gNumOutChans (= 4), on the other you have arrays declared with [4]. --- On Sat, 5/23/09, hermann meyer <brummer-(a)web.de> wrote: > From: hermann meyer <brummer-(a)web.de> > Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release > To: "James Warden" <warjamy(a)yahoo.com> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Saturday, May 23, 2009, 2:24 AM > Am Freitag, den 22.05.2009, 09:07 > -0700 schrieb James Warden: > > Hermann, > > > > I added a Latency menu to guitarix. You can now change > the jack server latency on the fly from guitarix (a la > ardour). See patches below: > > > > --------- > > Hi James > > Many thanks, it's real welcome, but unfortunatly I > experience a lot of > chrash's with your patch added. > I work (at time) with jackd, not jackdmp, and guitarix > recive often a > wrong(NULL) pointer after change the buffer size and > chrash'd, also, > when jackd cant set the selected buffersize, jackd > chrash'd. > So here is a proper errorhandling needed. > > Anyway, I have include the jack_set_buffer_size_callback, > to recreate > the intern buffer's from guitarix, when the buffersize > change, so that > guitarix can handle a buffersize change (currently not > commit). > > I did'nt have check it with jackdmp, did it work for you > without > experience some chrash's ? > > regards > hermann > >

16 years, 5 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

Hi Hermann, wow, I forgot to test against jack1 ... mmmm, strange, they use the same API. I have no problem at all when using it against jack2. I will investigate a bit more later today and let you know. FYI, I use jack2 svn@3540. J. --- On Sat, 5/23/09, hermann meyer <brummer-(a)web.de> wrote: > From: hermann meyer <brummer-(a)web.de> > Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release > To: "James Warden" <warjamy(a)yahoo.com> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Saturday, May 23, 2009, 2:24 AM > Am Freitag, den 22.05.2009, 09:07 > -0700 schrieb James Warden: > > Hermann, > > > > I added a Latency menu to guitarix. You can now change > the jack server latency on the fly from guitarix (a la > ardour). See patches below: > > > > --------- > > Hi James > > Many thanks, it's real welcome, but unfortunatly I > experience a lot of > chrash's with your patch added. > I work (at time) with jackd, not jackdmp, and guitarix > recive often a > wrong(NULL) pointer after change the buffer size and > chrash'd, also, > when jackd cant set the selected buffersize, jackd > chrash'd. > So here is a proper errorhandling needed. > > Anyway, I have include the jack_set_buffer_size_callback, > to recreate > the intern buffer's from guitarix, when the buffersize > change, so that > guitarix can handle a buffersize change (currently not > commit). > > I did'nt have check it with jackdmp, did it work for you > without > experience some chrash's ? > > regards > hermann > >

16 years, 5 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

Hermann, I added a Latency menu to guitarix. You can now change the jack server latency on the fly from guitarix (a la ardour). See patches below: --------- PATCH Start guitarix.cpp ----------- Index: guitarix.cpp =================================================================== --- guitarix.cpp (revision 125) +++ guitarix.cpp (working copy) @@ -9,7 +9,7 @@ // global static fields -GtkWidget* fWindow, *menul, *menus, *pb, *midibox, *fbutton, *label1, *menuh; +GtkWidget* fWindow, *menul, *menus, *menulat, *pb, *midibox, *fbutton, *label1, *menuh; GdkPixbuf* ib, *ibm, *ibr; GtkStatusIcon* status_icon; GtkWidget* livewa; @@ -203,6 +203,32 @@ bool GTKUI::fInitialized = false; list<UI*> UI::fGuiList; +//----menu function latency +void set_jack_buffer_size(GtkCheckMenuItem *menuitem, gpointer arg) +{ + // let's avoid triggering the jack server on "inactive" + if (gtk_check_menu_item_get_active(menuitem) == false) + return; + + // are we a proper jack client ? + if (!client) { + cerr << "<*** guitarix.cpp: set_jack_buffer_size()" + << " we are not a jack client, server may be down ***>" + << endl; + return; + } + + + // if the buffer size is the same, no need to trigger it + jack_nframes_t buf_size = (jack_nframes_t)GPOINTER_TO_INT(arg); + + if (buf_size == jack_get_buffer_size(client)) + return; + + // let's resize the buffer + jack_set_buffer_size(client, buf_size); +} + //----menu funktion play stop void play_function (GtkCheckMenuItem *menuitem, gpointer checkplay) { ---------- PATCH END guitarix.cpp -------------- ---------- PATCH START GTKUI.cpp --------------- Index: GTKUI.cpp =================================================================== --- GTKUI.cpp (revision 125) +++ GTKUI.cpp (working copy) @@ -897,6 +897,7 @@ GtkWidget *menuHelp; GtkWidget *menuLoad; GtkWidget *menuSave; + GtkWidget *menuLatency; GtkWidget *menubar; GtkWidget *menu; GtkWidget *menu1; @@ -948,6 +949,40 @@ gtk_widget_show (menuitem); /*---------------- End Engine menu declarations ----------------*/ + /*---------------- Create Latency menu items --------------------*/ + /*-- Create Latency submenu under Engine submenu --*/ + menuLatency = gtk_menu_item_new_with_label ("Latency"); + gtk_menu_bar_append (GTK_MENU_BAR(menubar), menuLatency); + menulat = gtk_menu_new(); + gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuLatency), menulat); + + /*-- Create menu item under Latency submenu --*/ + gchar buf_size[8]; + const int min_pow = 5; // 2**5 = 32 + const int max_pow = 13; // 2**13 = 8192 + group = NULL; + + for (int i = min_pow; i <= max_pow; i++) { + int jack_buffer_size = (int)pow(2.,i); + (void)snprintf(buf_size, 5, "%d", jack_buffer_size); + menuitem = gtk_radio_menu_item_new_with_label (group, buf_size); + group = gtk_radio_menu_item_get_group (GTK_RADIO_MENU_ITEM (menuitem)); + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (menuitem), FALSE); + + g_signal_connect (GTK_OBJECT (menuitem), "activate", + GTK_SIGNAL_FUNC (set_jack_buffer_size), + GINT_TO_POINTER(jack_buffer_size)); + + // display actual buffer size as default + if (client) + if (jack_buffer_size == (int)jack_get_buffer_size(client)) + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (menuitem), TRUE); + + gtk_menu_append(GTK_MENU(menulat), menuitem); + gtk_widget_show (menuitem); + } + /*---------------- End Latency menu declarations ----------------*/ + /*---------------- Create Settings menu items --------------------*/ menuEdit = gtk_menu_item_new_with_label ("Presets"); gtk_menu_bar_append (GTK_MENU_BAR(menubar), menuEdit); @@ -1074,6 +1109,7 @@ gtk_widget_show(handlebox); // remove handelbox here gtk_widget_show(menuitem); gtk_widget_show(menuFile); + gtk_widget_show(menuLatency); gtk_widget_show(menuEdit); gtk_widget_show(menuLoad); gtk_widget_show(menuSave); ------------ PATCH END GTKUI.cpp Feel free to add this functionality or not. Cheers! J. --- On Thu, 5/21/09, hermann meyer <brummer-(a)web.de> wrote: > From: hermann meyer <brummer-(a)web.de> > Subject: [LAD] [ANN] guitarix-0.04.4-1 release > To: linux-audio-dev(a)lists.linuxaudio.org > Date: Thursday, May 21, 2009, 8:56 AM > guitarix is a simple Linux Rock > Guitar amplifier for jack(Jack Audio Connektion Kit) > with one input and two outputs. Designed to get nice > thrash/metal/rock/blues > guitar sounds. . . . > > > Some new effect's in the amp section with new controllers, > overworked tuner, overworked midi output > (still it is experimental but can be usefull for rhythm > blues or jazz or. . . fun) > > Many thanks to Orcan Ogetbil (Fedora) for give the right > hint to impruve the tuner, > and the patch's to create a proper Makefile and more, > thanks Orcan. > > have fun > ________________________________________________________________________ > > guitarix based on Gtk, a great part is also realesed as > ladspa plugin. > guitarix is licensed under GPL > > Projektpage with screenshots: > http://guitarix.sourceforge.net/ > > download: > http://sourceforge.net/projects/guitarix/ > > > For capture guitarix make use of jack_capture ver >= > 0.9.30 from Kjetil > S. Matheussen. If you dont have it installed, look here: > > http://old.notam02.no/arkiv/src/?M=D > > For extra Impulse Response guitarix make use of jconv from > Fons Adriaensen. If > you dont have it installed, look here: > > http://www.kokkinizita.net/linuxaudio/index.html > > I use faust to build the prototype and will say thanks to > > : Julius Smith > http://ccrma.stanford.edu/realsimple/faust/ > > : Albert Graef > http://www.musikwissenschaft.uni-mainz.de/~ag/ag.html > > : Yann Orlary > http://faust.grame.fr/ > > > regards hermann > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >

16 years, 5 months

Re: [LAD] phasex building/bug/suggestion

by hollunder＠gmx.at

On Thu, 21 May 2009 21:52:43 -0700 (PDT) William Weston <weston(a)sysex.net> wrote: > On Fri, 22 May 2009, hollunder(a)gmx.at wrote: > > > On Thu, 21 May 2009 16:45:08 -0700 (PDT) > > William Weston <weston(a)sysex.net> wrote: > > > >> On Thu, 21 May 2009, hollunder(a)gmx.at wrote: > >> > >>> Hi William, > >>> I just tested it a bit and it works really well, a huge > >>> improvement over 0.11.1 and really fun to play around. > >>> However, I found some minor weirdness and what looks like a bug to > >>> me. > >>> > >>> 1) autogen behaves strangely: > >>> > >>> $ ./autogen.sh > >>> **Error**: Directory `.' does not look like the top-level package > >>> directory > >>> > >>> This was in the top level dir, the one where autogen.sh is > >>> located. > >> > >> I should really remove autogen.sh from the source tree. I used it > >> to create an initial configure.ac, and haven't touched it since. > >> The following should work for new builds: > >> > >> aclocal > >> autoconf > >> automake > >> autoheader > >> ./configure --enable-arch=foo (where foo is a gcc supported arch) > >> make > >> make install > > > > So far I used the following in a script that builds a package from > > source: > > > > ./configure --prefix="/usr" --enable-arch="native" > > make > > make DESTDIR="$pkgdir/" install > > > > "$pkgdir/" is just a variable in this script. > > "native" is something like i686, this machine is an old-ish amd > > athlon XP3000+. > > > > What difference do these steps make? > > > > aclocal > > autoconf > > automake > > autoheader > > These four steps are almost a guarantee that an autoconf enabled > project will build on your system. When compiling anything and > having issues with ./configure && make, I always go for this series > to rebuild all the autogenerated files. Works like a charm most of > the time, especially for packages that weren't released on the same > distro that I'm trying to build for. > > Aclocal sets up some system dependent variables that configure > expects to have defined. This usually isn't needed unless you're > building with another version of autoconf, but it doesn't hurt > either. > > Autoconf rebuilds configure from configure.ac. Ususally, the > existing configure script will work just fine, but again, it doesn't > hurt. > > Automake builds a Makefile for each Makefile.am. > > Autoheader builds a config.h from a config-h.in. > > You bring up a very good point here. The normal ./configure && make > should just work for most builds. I'm going to look into this some > more and make sure the stable release gets it right. Thanks for the detailed explanation. It's almost certainly a different distro and version of several applications, so I'll try these steps, even if ./configure && make seems to work. Thanks for looking into it. > >>> 2) It looks like make is running configure again, although > >>> configure needs to be run before make can be run, so this seems > >>> to be redundant. > >> > >> I've noticed this before, normally after running autoconf. Once > >> the configure script is rebuilt, make shouldn't decide to rebuild > >> it. Does this happen every time for you, or just after cleaning up > >> and re-running aclocal and/or autoconf? > > > > The above-mentioned script always builds from a clean tarball or > > clean copy of the tarball so I always got it so far, but I just > > tried it. From a clean directory I ran > > configure [options], make, configure [no options], make > > and the second make didn't configure. > > > >>> 3) When playing a little piano piece I noticed that it cuts off > >>> some notes prematurely for some reason, likely timing related, > >>> even in poly-mode. The attached midi file should work as > >>> demonstration, note how the notes played by the right hand get > >>> cut long before the note-off. Both hands play continuously except > >>> for the end, so it should be easy to spot. Simple sounds like > >>> preset #3 work best. > >> > >> Sounds like you might be hitting the polyphony limit. What CPU are > >> you building for? CPU dependent things are configured in > >> src/phasex.h. Sane defaults where chosen for all the common x86 > >> CPU types (broken up into three classes) so as not to bog down the > >> realtime system, but depending on CPU power, you might be able to > >> squeeze a little more out of your machine. > > > > Judging from what 'top' tells me phasex isn't using that much cpu. > > Are you looking at top with voices in play? The CPU consumption > goes up with the number of voices currently being generated. When idle it chews around 6-15%, with 6 voices playing 25-30%. > > src/phasex.h: > > # define PHASEX_CPU_POWER 2 > > > > #if (PHASEX_CPU_POWER == 2) > > # define NUM_VOICES 6 > > #endif > > > > So this could indeed be the polyphony limit. > > Yes it is. I've been keeping it low enough to get full polyphony > out of two instances without choking up the realtime (I generally > run 4-6 instances and run sequencing out of MusE). I've been > thiknking of setting up the default builds with more polyphony and > treating the running of multiple instances as the special cases. It seems like with the default settings I could have at least 3 instances playing at the same time. Does it hurt if it is compiled for many voices and multiple instances are run with a low voice count each? In other words, does the compile with many voices impact performance even if these voices aren't used? Personally I think that the voice limit defined at compiletime is a problem, especially if it is that low. Most distributions out there are pure binary based, so they'll have to make a choice for their users with a wide variety of machines. Some switch at application start + sane default or auto-detection would be preferable. I usually only write scripts that build from source for my distro's community repository, like this one: http://aur.archlinux.org/packages/phasex-git/phasex-git/PKGBUILD where this isn't really an issue, but we are in the process of making a binary audio repository so we face that problem as well. > > Can I pass this at configure-time somehow or do I need to sed? > > You can override the definitions at configure time by passing new > ones as debug flags to the compiler: > > ./configure --enable-arch=athlon-xp --enable-debug="-DNUM_VOICES=12" Ah, thanks a lot, I will experiment. Does enable-debug have other implications/sideeffects? > >>> 4) A suggestion: > >>> Especially when playing back files and stopping in between you can > >>> get hung notes that can swell quite immensely and are hard to get > >>> rid of (well, you have to somehow hit the right note to get a > >>> note-off). Similar stuff could happen in other situations. > >>> Something like a panic-button that kills all sounds could help. > >> > >> The hung notes are most likely due to not receiving note off > >> messages (a problem with a lot of players when stopping > >> mid-stream). Phasex responds to the all-notes-off controller > >> message, but that's not available on a lot of controllers, so the > >> panic button sounds like a great idea. I'll see about > >> implementing it for 0.12.0-stable. > >> > >>> That's it for now, thanks a lot for phasex, it's really fun to > >>> play. > >> > >> Thanks for your support. Happy music-making! > >> > >> --ww > > > > Thanks, > > I haven't made a lot of music yet but the sounds that phasex > > produces are very inspiring to me (and I just bought nice monitors > > and a mic, so I kind of have to make some music now). > > The new monitors will make a *huge* difference for any style of > music. You won't regret your purchase. Of course, you'll be hooked > and start shopping for outboard preamps, compressors, eqs, etc... > Or at least that's what happened right after I bought new monitors. Definitely, this was the best purchase I did, ever. The difference is huge, now it's really a joy to listen to music, understanding lyrics, hear and feel bass, stereo image.. it's really great. For now it has to be enough gear, monitors, e-piano, a nice mic and a linux box full of audio apps, far more than is needed for making music. Reminds me to try the phasex audio in :) > Enjoy! I will :) Best regards, Philipp

16 years, 5 months

[ANN] guitarix-0.04.4-1 release

by hermann meyer

guitarix is a simple Linux Rock Guitar amplifier for jack(Jack Audio Connektion Kit) with one input and two outputs. Designed to get nice thrash/metal/rock/blues guitar sounds. . . . Some new effect's in the amp section with new controllers, overworked tuner, overworked midi output (still it is experimental but can be usefull for rhythm blues or jazz or. . . fun) Many thanks to Orcan Ogetbil (Fedora) for give the right hint to impruve the tuner, and the patch's to create a proper Makefile and more, thanks Orcan. have fun ________________________________________________________________________ guitarix based on Gtk, a great part is also realesed as ladspa plugin. guitarix is licensed under GPL Projektpage with screenshots: http://guitarix.sourceforge.net/ download: http://sourceforge.net/projects/guitarix/ For capture guitarix make use of jack_capture ver >= 0.9.30 from Kjetil S. Matheussen. If you dont have it installed, look here: http://old.notam02.no/arkiv/src/?M=D For extra Impulse Response guitarix make use of jconv from Fons Adriaensen. If you dont have it installed, look here: http://www.kokkinizita.net/linuxaudio/index.html I use faust to build the prototype and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://www.musikwissenschaft.uni-mainz.de/~ag/ag.html : Yann Orlary http://faust.grame.fr/ regards hermann

16 years, 5 months

phasex-0.12.0-beta2

by William Weston

Announcing phasex-0.12.0-beta2 I've been away from the dev circles for a while, but I haven't forgotten about keeping phasex up to date. The new phasex beta targets all of the current build/usability issues, and includes a ton of small changes and fixes: - Clearer licensing (code and samples GPLv2, patches public domain). - Reworked JACK connection code (can now survive JACK restarts when running multiple instances). - Initial support for sampled oscillator waveforms (Juno-106 and vocal waveforms currently included). - Sound quality improvements (super-clean chorus using hermite interpolation, cleaner envelope curves, smoothing added for pitchbender adjustments, and fixes for portamento and mono keymode triggering). - New parameters (pan, lfo support for resonance, fine-tuning for osc pitch and fm). - Fixed 64 bit builds. - Added new architectures in the x86 family. - Fixed file dialog problems with newer GTK builds. - New GTK theme and color scheme. - See the ChangeLog for more... This beta aims at being a stable release. All of the currently known showstoppers have been fixed. Builds under Fedora 8 and Fedora 10 behave well with jackd and jackdmp. Builds under Debian/Ubuntu and with jackdbus have not yet been tested. Any build and crash reports would be greatly appreciated, especially from distribution maintainers. I aim to release a stable 0.12.0 in a couple of weeks, including updated patches. Check out http://sysex.net/phasex/beta to download the latest phasex tarballs and Fedora 10 RPMs. Alternatively, you can try out the new git repositoty: git clone http://sysex.net/git/phasex.git It's nice to be back working on Linux audio! Cheers, --ww

16 years, 5 months

Re: [LAD] New proposal for the jackd/jackdbus mess : adding "config" API

by James Warden

the existence of ~/.jackdrc is fine and using it in the future for legacy reasons is also a good thing. Its format, on the other hand, is questionable. I don't find it a good practice to call a server configuration file something that is more some sort of shell script, because the current ~/.jackdrc is nothing but a shell script. However, I am no jack dev, so you can dismiss my opinion if you like. J. --- On Wed, 5/20/09, Stéphane Letz <letz(a)grame.fr> wrote: > From: Stéphane Letz <letz(a)grame.fr> > Subject: [LAD] New proposal for the jackd/jackdbus mess : adding "config" API > To: "Jack devel" <jack-devel(a)lists.jackaudio.org>, "Linux Audio Developers" <linux-audio-dev(a)lists.linuxaudio.org> > Date: Wednesday, May 20, 2009, 8:30 AM > Hi all, > > Here is an updated version that add a new (to be defined) > "config" API in libjack.so. The idea is to provide a way to > *share* multiple server configurations in a unique place for > all control application. The important point are: > > - we are not allowed to break legacy use of ~/.jackdrc > > - we absolutely want to maintain server auto-start from > clients > > So the overall suggestion is to *maintain* this > ~/.jackdrc with it's current format and to define a > new config API that will probably use another file (or set > of files...). > > - legacy control application (Qjackcl for instance) can > still use their multiple server configurations, they will > not see and use this new share and centralized state, but I > don't think we can do better. > > - new control front-end (jackdbus, jackOSC) would have to > use this new config API. > > Comments? > > Stephane > > > > -----Inline Attachment Follows----- > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >

16 years, 5 months

New proposal for the jackd/jackdbus mess : adding "config" API

by Stéphane Letz

Hi all, Here is an updated version that add a new (to be defined) "config" API in libjack.so. The idea is to provide a way to *share* multiple server configurations in a unique place for all control application. The important point are: - we are not allowed to break legacy use of ~/.jackdrc - we absolutely want to maintain server auto-start from clients So the overall suggestion is to *maintain* this ~/.jackdrc with it's current format and to define a new config API that will probably use another file (or set of files...). - legacy control application (Qjackcl for instance) can still use their multiple server configurations, they will not see and use this new share and centralized state, but I don't think we can do better. - new control front-end (jackdbus, jackOSC) would have to use this new config API. Comments? Stephane

16 years, 5 months

my take on the jack/dbus issue

by Aaron Johnson

Hi all, Where I'm coming from--I use Arch Linux, so I'm a big believer in simplicity and modularity. And CHOICE. Enforcing a Dbus dependency into an architecture that already just works fine is, I dunno, procrustean "must have Dbus" insanity. So, I agree with Fons that something like Dbus seemingly take over the whole infrastructure of my Linux system, including a key audio component like jack, is a bad idea. I also agree that this Dbus stuff seems to be creeping in as a dependency into more and more software causing all sorts of instability and havoc with whatever it touches. I can also say from 12 years of using Linux, I've never had so many error messages or instability from any other piece of my system than from Dbus-related processes. One of the reasons I now avoid the major Desktop environments as much as I can, and use fluxbox, is the feeling that they are getting too big and unstable and not 'system critical performance' enough, and I think a lot of that has to do with this incredible 'dependency creep'. So, really, from my point of view, not only should Dbus NOT have anything to do with jack, it should be taken out into the backyard and shot so we can all sleep at night.... This reminds me of Debian/Ubuntu trying to determine what Linux is. For instance, instead of adhering to vanilla practices, Debian and Ubuntu folks change file system hierarchy standards, and no wonder things break so often on those distros. I remember using both and feeling "wow this is great, lots of packages" but also..."damn, this is the 3rd reboot today--Dbus error" I'm sure I've offended someone in the Dbus-loving community. I'm sorry. You ideally should be willing to listen to reports from the field... -AKJ -- Aaron Krister Johnson http://www.akjmusic.com http://www.untwelve.org

16 years, 5 months

Denemo 0.8.4 release - Music Notation Editor

by Nils Gey

Sorry for the crossposting, but the statistics show that only some people have subscribed to all three lists. ------------ The Denemo project has released a new version of its music notation program. Denemo 0.8.4, which is available for Windows, Linux and MacOS (via third-party builds) as source and binaries. The software is distributed under the GPL. Some of the new features are improvements for scripting support and user-created commands and improved MIDI-output. Official support, beneath our website, is avaible via our IRC channel #denemo on irc.freenode.net. Denemos notation-functionality is ready for daily and professional use. For future improvements our team searches for additional developers. If you are interested in notation and midi-sequencing please join the team! Website: http://www.denemo.org Additional information: GNU Denemo is a free, GPL, open source music notation editor for Linux, MacOS and Windows that lets you rapidly enter notation for typesetting via the LilyPond music engraver. You can compose, transcribe, arrange, listen to the music and much more. Music can be typed in at the PC-Keyboard, or played in via MIDI controller, or input acoustically into a microphone plugged into your computer's soundcard.

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