Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Marco Ballini

I'm following the LADSPA and XAP discussions from the beginning. I've some ideas about audio plugins I've been thinking about since 2001. What I really wanted was an audio plugin API for: - a music composition environment - real-time music performances All my ideas led to a sketch of an event-oriented API. So many things are common to (what I read of) XAP that I wanted to join the discussion, but unfortunately I had no time to do that. I now have some free time and I would like to share my ideas with others (a new API is a big effort). So, what happened to XAP? Is this list the right place for discussion on it? Would it be better to add my ideas to "XAP spec - early scribbles" (e-mail from Tim Hockin on 4 February 2003) or to put them in an indipendent form? Thanks for any answer, - Marco

22 years, 3 months

[linux-audio-dev] EU software patents?

by Juhana Sadeharju

Hello. Can anyone report what is going on with the EU software patents? How they would affect immediately the audio and graphics development we are doing? Xine? Sodipodi? Others? Yesterday news broadcasting made not a big case how EU software patents affects us. They were more conserned about how companies' money escapes from research and development to the patent lawyers when companies *have to* start patenting. (It looks like professional politicians do not realize that nobody forces to patent anything.) Other worry was that then big companies collects patent portfolios and thus puts small companies to trouble. Again, no worry about us. It was only at evening news that one channel mentioned Linux, but no politicians seemed to worry about Linux or us. -*- I would like to propose the following: if EU gets the software patents, then should non-profit open source community and non-profit academic researchers get patents for free. Then we would be in equally competitive situation. IMHO, the current patent system discriminate us. Patenteer for sure use anything we develop, but for sure they are protecting even triviallest "invention". Please, don't say we have *choosed* not to patent anything. I have choosed not to patent only because there is no income in writing free software. I have invented tens of non-trivial and trivial techniques. It would have been great if the free/open source community would have a 20 years monopoly for these techniques. (As a non-profit institution we cannot get royalties from the patent, right? We would use them to block commercial products for using the techniques.) Best regards, Juhana

22 years, 3 months

[linux-audio-dev] LilyPond 2.0 - make beautiful music prints

by Han-Wen Nienhuys

Dear music enthousiasts, LilyPond version 2.0 was released today. LilyPond is an automated music notation system: it is used to make gorgeous sheet music. It is libre software ("open source"), and available for most Unix flavors, including Linux and MacOS X, and MS Windows. Use it for your music too! For this version, we have dramatically simplified many parts of the syntax, making it easier to use than ever before. Other improvements include quarter-tone accidentals, and conditional inclusion of music fragments. With version 2.0, we have a solid platform for working on notation and typography features for coming versions. Downloads, examples and documentation are available from the website, http://lilypond.org A big thank-you goes out to our hackers and bughunters: Mats Bengtsson, Heikki Junes, Juergen Reuter, Antonio Palama, Benjamin Milde, Daniel Berjon Diez, David Bobroff, David Rayleigh Arnold, Erik Ronstroem, Fabio dos Santos, Fodor Bertalan, Frederic Bron, Graham Parcival, Ian Bailey-Mortimer, John Williams, Josza Marton, Marco Caliari, Matthieu Amiguet, Michael Welsh Duggan, Patrick Atamaniuk, Paul Scott, Pedro Kroeger, Peter Lutek, Richard Schoeller, Thorkil Wolvendans, and Werner Trobin Happy music printing, Han-Wen Nienhuys & Jan Nieuwenhuizen (core development team) New features in 2.0 since 1.8 ***************************** * Crescendos can now be drawn dotted or dashed. * Quarter tones are now supported. They are entered by suffixing `ih' for a half-sharp and `eh' for a half-flat. Hence, the following is an ascending list of pitches: ceses ceseh ces ceh c cih cis cisih cisis * The following constructs have been removed from the syntax: \duration #SCHEME-DURATION \pitch #SCHEME-PITCH \outputproperty FUNC SYMBOL = VALUE For `\outputproperty', the following may be substituted: \applyoutput #(outputproperty-compatibility FUNC SYMBOL VALUE) * Clefs may now be transposed arbitrarily, for example \clef "G_8" \clef "G_15" \clef "G_9" * The syntax for chords and simultaneous music have changed. Chords are entered as <PITCHES> while simultaneous music is entered as <<..MUSIC LIST..>> In effect, the meanings of both have been swapped relative to their 1.8 definition. The syntax for lists in `\markup' has changed alongside, but figured bass mode was not changed, i.e.: \markup { \center <..LIST OF MARKUPS..> } \figure { <FIGURES> } As chords the more often used than simultaneous music, this change will save keystrokes. * Each music expression can now be tagged, to make different printed versions from the same music expression. In the following example, we see two versions of a piece of music, one for the full score, and one with cue notes for the instrumental part: << \tag #'part << { c4 f2 g4 } % in the part, we have cue-notes \\ R1 >> \tag #'score R1 % in the score: only a rest >> The same can be applied to articulations, texts, etc.: they are made by prepending -\tag #YOUR-TAGS to an articulation, for example, c4-\tag #'with-fingerings -4 -\tag #'with-strings \6 This defines a note, which has a conditional fingering and a string-number indication. * The settings for chord-fingering are more flexible. You can specify a list where fingerings may be placed, eg. \property Voice.fingeringOrientations = #'(left down) This will put the fingering for the lowest note below the chord, and the rest to the left. * The script previously known as `ly2dvi' has been renamed to `lilypond'. The binary itself is now installed as `lilypond-bin'. * Markup text (ie. general text formatting) may now be used for lyrics too. * Two new commands for grace notes have been added, `\acciaccatura' and `\appoggiatura', \appoggiatura f8 e4 \acciaccatura g8 f4 Both reflect the traditional meanings of acciaccatura and appogiatura, and both insert insert a slur from the first grace note to the main note. * Layout options for grace notes are now stored in a context property, and may now be set separately from musical content. * The `\new' command will create a context with a unique name automatically. Hence, for multi-staff scores, it is no longer necessary to invent arbitrary context names. For example, a two-staff score may be created by \simultaneous { \new Staff { NOTES FOR 1ST STAFF } \new Staff { NOTES FOR 2ND STAFF } } * Octave checks make octave errors easier to correct. The syntax is \octave PITCH This checks that PITCH (without octave) yields PITCH (with octave) in \relative mode. If not, a warning is printed, and the octave is corrected. * All articulations must now be entered postfix. For example, c8[( d8]) is a pair of beamed slurred eighth notes. * The definition of `\relative' has been simplified. Octaves are now always propagated in the order that music is entered. In the following example, PRE \repeat "unfold" 3 BODY \alternative { ALT1 ALT2 } POST the octave of BODY is based on PRE, the starting octave of ALT1 on BODY, the starting octave of ALT2 on ALT1, and the starting octave of POST on ALT2. The same mechanism is used for all other music expressions, except the chord. Backwards compatibility is retained through a special program option, which is set through #(ly:set-option 'old-relative) * Windows users can double click a `.ly' file to process and view it automagically through the new `lily-wins' frontend. New features in 1.8 since 1.6 ***************************** * The chord entry code has been completely rewritten. It is now cleaner and more flexible. * A new syntax has been added for text entry. This syntax is more friendly than the old mechanism, and it is implemented in a more robust and modular way. For more information, refer to the section on "Text markup" in the notation manual. * The integration of the input language and Scheme has been made deeper: you can now use LilyPond identifiers in Scheme, and use Scheme expressions instead of LilyPond identifiers. * The internal representation of music has been cleaned up completely and converted to Scheme data structures. The representation may be exported as XML. * A new uniform postfix syntax for articulation has been introduced. A beamed slurred pair of eighth notes can be entered as c8-[-( d8-]-) In version 2.0, postfix syntax will be the only syntax available, and the dashes will become optional. This will simplify the language: all articulations can be entered as postfix, in any order. * A new syntax has been added for chords: << PITCHES >> It is not necessary to update files to this syntax, but it will be for using LilyPond version 2.0. In version 2.0, this syntax will be changed to < PITCHES > for chords, and \simultaneous { .. } for simultaneous music. To convert your files from <PITCHES> to <<PITCHES>>, use the script included in buildscripts/convert-new-chords.py This change was introduced for the following reasons * It solves the "start score with chord" problem, where you have to state \context Voice explicitly when a chord was the start of a Staff or Score. * With the new syntax, it is possible to distinguish between articulations (or fingerings) which are for a single chord note, and which are for the entire chord. This allows for per-note fingerings, and is more logical on the whole. * User code may now be executed during interpreting. The syntax for this code is \applycontext #SCHEME-FUNCTION * User code may now be executed on arbitrary grobs during interpreting. The syntax for this feature is \applyoutput #SCHEME-FUNCTION SCHEME-FUNCTION takes a single argument, and is called for every grob that is created in the current context. * New algorithms for chord-name formatting have been installed. They can be tuned and have ergonomic syntax for entering exceptions. * Texts may now be put on multimeasure rests, e.g. R1*20^\markup { "GP" } * Ancient notation now prints ligatures in Gregorian square neumes notation, roughly following the typographical style of the Liber hymnarius of Solesmes, published in 1983. Ligatures are still printed without the proper line breaking and horizontal spacing. * Glissandi can now be printed using the zigzag style. * LilyPond can now print clusters. The syntax is \apply #notes-to-clusters { NOTE NOTE .. } * For irregular meters, beat grouping marks can be printed. The syntax for this is #(set-time-signature 7 8 '(3 2 2)) * Nested horizontal brackets for music analysis can now be printed: NOTE-\startGroup .. NOTE-\stopGroup * Ottava brackets are now fully supported as a feature. The syntax is #(set-octavation 1) * Metronome markings are printed when a \tempo command is processed. * Fingerings can be put on chords horizontally. * The appearance of various glyphs has been fine-tuned. * Different types of percent style repeats may now be nested. * The emacs support has been extended. * The manual has been completely revised and extended. New features in 1.6 since 1.4 ***************************** * Support for figured bass and tablature. * Completely rewritten beam formatting: provides much better output now. * Completely revised and improved music font. * Completely rewritten MIDI import support. * Completely rewritten grace note support. Practically speaking this means that grace notes can be slurred to normal normal notes. * Improved accidental handling and formatting: styles for producing cautionaries may vary, and complex collisions between accidentals of a chord are handled much better. * Better spacing: both globally and locally. This includes subtle details like optical stem spacing. * More support for ancient notation: mensural ligatures, ambitus (pitch range) of voices, more shapes, etc. * More support for piano notation: bracket pedals, directed arpeggios, arpeggio brackets. * Easier music polyphonic music entry. * More extensibility, many speedups and bugfixes * The manual has been thoroughly revised. * Development is now hosted at http://savannah.gnu.org, and sources can be downloaded through anonymous CVS. * Support for windows: LilyPond is part of the cygwin distribution, which comes with a user-friendly installer. -- Han-Wen Nienhuys | hanwen(a)cs.uu.nl | http://www.xs4all.nl/~hanwen

22 years, 3 months

Re: [linux-audio-dev] EU software patents?

by hexe_2003＠directbox.com

-------- directBOX Reply --------------- From: kouhia(a)nic.funet.fi To : linux-audio-dev@music.columbia.edu;linux-graphics-dev@music.columbia.edu Date: 24.09.2003 12:07:26 Hello. Can anyone report what is going on with the EU software patents? How they would affect immediately the audio and graphics development we are doing? Xine? Sodipodi? Others? --------- Well, they'd affect everything; Software patents (or "logical algorythmic patents") are a disaster. You know the status bar in an Installing application like "Install Shield Wizzard" ? Well, with these patents ONE firm could own these structure; EVERY other application would use this kind of algorythmic would be forbidden .... . greetz, sascha retzki __________________________________________________ Verpassen Sie keine eBay-Auktion und bieten Sie bequem und schnell über das Telefon mit http://www.telefonbieten.de Ihre eMails auf dem Handy lesen - ohne Zeitverlust - 24h/Tag eMail, FAX, SMS, VoiceMail mit http://www.directbox.com

22 years, 3 months

[linux-audio-dev] shared memory question

by Dave Phillips

Greetings LADders: I'm working with Kjetil's vstserver, testing various plugins, and occasionally I get this error from the server : VSTSERVER/SMS_new: Unable to allocate 12288 bytes of shared memory. VSTSERVER/CH_new: Could not set up shared memory. The plugin then politely refuses to load. 'cat /proc/meminfo' reports : total: used: free: shared: buffers: cached: Mem: 526311424 511303680 15007744 0 70569984 234008576 Swap: 337195008 223801344 113393664 MemTotal: 513976 kB MemFree: 14656 kB MemShared: 0 kB Buffers: 68916 kB Cached: 208332 kB SwapCached: 20192 kB Active: 253612 kB Inactive: 177876 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 513976 kB LowFree: 14656 kB SwapTotal: 329292 kB SwapFree: 110736 kB I tried expanding the shared amount with 'echo some-big-number > /proc/sys/kernel/shmmax' but still got the error. I'm obviously not understanding something, so I turn to the wizards for help. Is there a fix for this problem ? Best regards, == dp

22 years, 3 months

Re: [linux-audio-dev] Best road to audio programming happiness?

by Juhana Sadeharju

Me too! For me Jack has been confusing as I'm not sure in what process/thread my audio routine runs. Somebody here wrote Jack's interesting thing is that it can route audio through applications. I don't want that. I want that Jack takes my C function (or its compiled object) and executes that within the real-time audio engine. Even if Jack is used, should one prepare process non-realtime audio within your own application. You cannot send background audio processings to Jack. Threads in the application are important because it is not good that the whole application freezes when one opens a big audiofile to editor, for example. I have not yet seen even moderate explanations or guides on those topics. We have discussed about Model-View-Controller (MVC) scheme, but nobody seemed to have any practical tool-level explanations so that I could easily use MVC in my applications. I suggest to start with Jack, not with Alsa or OSS. It took me an hour to write a Theremin synth, sort of. Very easy. (GUI was built with GTK+.) Best regards, Juhana

22 years, 3 months

[linux-audio-dev] Best road to audio programming happiness?

by Earle

I was hoping someone could help me with my first newbie steps in linux audio programming. I finally made it over to Linux, and discovered that I arrived here before cubase and fruityloops did. They never did what I wanted them to anyway. *sob*. Anyhoo, now that I'm over them, I would love to get cracking on some chunky audio projects but I'm a bit unsure of a kind of "best practises" approach for audio programming. What should I study? Whats the best way to go?! I have done some messing around with SDL and that seems pretty cool - cross platform, good graphic capabilites, and the audio is really simple. The faq says "low level support for audio" - is it low enough?! Is it useless? Ive really gotten into audio programming, but the stuff I'm making is currently all over the place (like this message) using different snippets of code and tutorials I've found here and there. Half of the sources are old, so I don't know which path I should be following. Any hints would be appreciated! Earle

22 years, 3 months

Re: [linux-audio-dev] Best road to audio programming happiness?

by Earle Castledine

Wow, thanks a lot everyone. I'm certainly going to check out JACK, but is GTK+ flexible enough (can you make your own buttons and stuff) Actually, don't answer that, that's just laziness on my part - Its just that I've noticed that the graphics sometimes take a back seat in the linux world :) ... Well that uses up my one free "really newbie" question. I promise the next question I post will be thoroughly researched! Thanks again, Earle

22 years, 3 months

[linux-audio-dev] Compiling DJplay

by Frank Barknecht

Hallo, I'm having a strange problem with linmpeg3 while compiling DJplay (http://linux1.t-data.com/djplay/) All goes well until the final linker step which gives this error: g++ -o djplay djplay.o display.o [...] mp3.o [...] recorder.o \ -L$QTDIR/lib -lqt-mt `pkg-config --libs glib jack` -laudiofile -lmad \ -lmpeg3 mp3.o(.text+0x4ac): In function `mpeg3demux_read_char': /usr/include/mpeg3demux.h:104: undefined reference to `mpeg3demux_read_char_packet(mpeg3_demuxer_t*)' mp3.o(.text+0x4e9): In function `mpeg3demux_read_prev_char': /usr/include/mpeg3demux.h:118: undefined reference to `mpeg3demux_read_prev_char_packet(mpeg3_demuxer_t*)' collect2: ld returned 1 exit status make: *** [djplay] Error 1 This is using the Debian testing packages of libmpeg3. I als tried recompiling the library, but it still gives this error. Anone any tips on where to look for the error? ciao -- Frank Barknecht _ ______footils.org__

22 years, 3 months

Re: [linux-audio-dev] LL-patch for SuSE kernel?

by Stefan Nitschke

>yes, suse kernel (since 8.1) already includes most of the >necessary changes. some parts are missing but they are on >the rare code path, which has been not audited quite well, >anyway. Well i do have a LL patch for the original SusE 8.1 kernel that comes with the distribution, including the capability patch. The original SuSE 8.1 kernel does not work well without that patch on my machines. I also have a patch that adds cpufreq and a patch for BIOSes with broken ACPI. That patches are only tested on my Dell i8500, but for me they work perfect. I dont have patches for SuSE 8.2 ... i wait for an update until the first stable 2.6.x kernel based SuSE distro is out. - Stefan _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

22 years, 3 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