My company is looking for a Systems Programmer to (among other things)
maintain our Linux running on an embedded music product. If you/someone
you know are/is interested and live/s in the San Francisco Bay area,
please let me know.
Cheers... mo
PS: I couldn't tell from the list guidelines whether this kind of post
is appropriate. If not, sorry! and please ignore it.
I've stumbled across a problem that no doubt someone has come across before.
What is the recomended way to force alternate keybindings on a gtk
scrollbar?
Would I have to create a custom widget that is a replica is there
another way?
Using all the keys is a very simple way of making jackEQ truely useful
in live performance. It would add functionality to the mixer in ardour too.
The docs for range widgets say this:
------------
Scrollbars are not focusable, thus have no key bindings. The key
bindings for the other range widgets (which are, of course, only active
when the widget has focus) are do not differentiate between horizontal
and vertical range widgets.
All range widgets can be operated with the left, right, up and down
arrow keys, as well as with the Page Up and Page Down keys. The arrows
move the slider up and down by step_increment, while Page Up and Page
Down move it by page_increment.
The user can also move the slider all the way to one end or the other of
the trough using the keyboard. This is done with the Home and End keys.
------------
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
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
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
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
-------- 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
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
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
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
