Free common music software for linux

Common Music (CM) is an object-oriented music composition environment.

Common Music produces sound by transforming a high-level representation of musical structure into a variety of control protocols for sound synthesis and display.

CMU Common Lisp is a free implementation of the Common Lisp programming language which runs on most major Unix platforms. CMU Common Lisp project mainly conforms to the ANSI Common Lisp standard.
Main features:
- a sophisticated native-code compiler which is capable of powerful type inferences, and generates code competitive in speed with C compilers.
- generational garbage collection and multiprocessing capability on the x86 ports.
- a foreign function interface which allows interfacing with C code and system libraries, including shared libraries on most platforms, and direct access to Unix system calls.
- support for interprocess communication and remote procedure calls.
- an implementation of CLOS, the Common Lisp Object System, which includes multimethods and a metaobject protocol.
- a graphical source-level debugger using a Motif interface, and a code profiler.
- an interface to the X11 Window System (CLX), and a sophisticated graphical widget library (Garnet).
- programmer-extensible input and output streams.
- an Emacs-like editor implemented in Common Lisp.
- freely redistributable: free, with full source code (most of which is in the public domain) and no strings attached (and no warranty). Like the GNU/Linux and *BSD operating systems, CMUCL is maintained and improved by a team of volunteers collaborating over the Internet.
Common Lisp is well suited to large programming projects and explorative programming. The language has a dynamic semantics which distinguishes it from languages such as C and Ada.
It features automatic memory management, an interactive incremental development environment, a module system, a large number of powerful data structures, a large standard library of useful functions, a sophisticated object system supporting multiple inheritance and generic functions, an exception system, user-defined types and a macro system which allows programmers to extend the language.
Enhancements:
- A new float type EXT:DOUBLE-DOUBLE-FLOAT is supported.
- A DOUBLE-DOUBLE-FLOAT uses two DOUBLE-FLOATs to represent a number with >= 106 bits of precision (about 33 digits).
- Hash tables now support weak value, weak key- and-value, and weak key-or-value tables.
- LONG-LONG and UNSIGNED-LONG-LONG are recognized types in the C-CALL package for signed and unsigned 64-bit integers.
- The generational garbage collector has been ported to Darwin/ PPC.
- Numerous bugs and ANSI-compliance problems have been fixed.

GNU ccRTP is an implementation of RTP, the real-time transport protocol from the IETF (see RFC 3550, RFC 3551 and RFC 3555). ccRTP is a C++ library based on GNU Common C++ which provides a high performance, flexible and extensible standards-compliant RTP stack with full RTCP support. The design and implementation of ccRTP make it suitable for high capacity servers and gateways as well as personal client applications.
In designing ccRTP, we have taken into account that RTP has been defined as an application level protocol framework rather than a typical Internet transport protocol such as TCP and UDP. Thus, RTP is hardly ever implemented as a layer separated from the application.
Consequently, RTP applications often must customize the adaptable RTP packet layout and processing rules, timing constraints, session membership rules as well as other RTP and RTCP mechanisms. ccRTP aims to provide a framework for the RTP framework, rather than being just an RTP packet manipulation library.
Support for both audio and video data is also considered in the design of ccRTP, that can do partial frame splits/re-assembly. Unicast, multi-unicast and multicast transport models are supported, as well as multiple active synchronization sources, multiple RTP sessions (SSRC spaces), and multiple RTP applications (CNAME spaces). This allows its use for building all forms of Internet standards based audio and visual conferencing systems.
GNU ccRTP is threadsafe and high performance. It uses packet queue lists for the reception and transmission of data packets. Both inter-media and intra-media synchronization is automatically handled within the incoming and outgoing packet queues. GNU ccRTP offers support for RTCP and many other standard and extended features that are needed for both compatible and advanced streaming applications.
It can mix multiple payload types in stream, and hence can be used to impliment RFC 2833 compliant signaling applications as well as other specialized things. GNU ccRTP also offers direct RTP and RTCP packet filtering.
GNU ccRTP uses templates to isolate threading and sockets related dependencies, so that it can be used to impliment realtime streaming with different threading models and underlying transport protocols, not just with IPV4 UDP sockets. For a more detailed list of ccRTP features you can have a look at the programmers manual.
At its highest level, ccRTP provides classes for the real-time transport of data through RTP sessions, as well as the control functions of RTCP.
The main concept in the ccRTP implementation of RTP sessions is the use of packet queues to handle transmission and reception of RTP data packets/application data units. In ccRTP, a data block is transmitted by putting it into the transmission (outgoing packets) queue, and received by getting it from the reception (incoming packets) queue.
Main features:
- Highly extensible to specialized stacks.
- Supports unicast, multi-unicast and multicast. Handles multiple sources (including synchronization sources and contributing sources) and destinations. Also supports symmetric RTP.
- Automatic RTCP functions handling, such as association of synchronization sources from the same participant or NTP-RTP timestamp mapping.
- Genericity as for underlying network and transport protocols through templates.
- It is threadsafe and supports almost any threading model.
- Generic and extensible RTP and RTCP header validity checks.
- Handles source states and information as well as statistics recording.
- Automatically handles SSRC collisions and performs loop detection.
- Implements timer reconsideration and reverse reconsideration.
- Provides good random numbers, based on /dev/urandom or, alternatively, on MD5.
There are several levels of interface (public interface, public or protected inheritance, etc) in ccRTP. For instance, the rtphello demo program distributed with ccRTP just uses the public interface of the RTPSession class and does not redefine the virtual method onGotSR, thus what this program knows about SR reports is the information conveyed in the last sender report from any source, which can be retrieved via the getMRSenderInfo method of the SyncSource class.
On the contrary, the rtplisten demo program redefines onGotSR by means of inheritance and could do specialized processing of these RTCP packets. Generally, both data and control packets are not directly accessible through the most external interface.
All this functions are performed through a few essential classes and types. The most basic ones are the enumerated type StaticPayloadType, and the classes StaticPayloadFormat and DynamicPayloadFormat.
The most important ones are the classes RTPSession, SyncSource, Participant and AppDataUnit, that represent RTP sessions, synchronization sources, participants in an RTP application, and application data units conveyed in RTP data packets, respectively.
When using ccRTP, both sending and receiving of data transported over RTP sessions is done through reception and transmission queues handled by the RTP stack. In the most common case, a separate execution thread for each RTP session handles the queues. This case is the threading model that we will generally assume throughout this document. Note however that ccRTP supports other threading models, particularly ccRTP supports the use of a single execution thread to serve a set of RTP sessions. It is also possible to not associate any separate thread with any RTP session, manually calling the main data and control service methods from whatever other thread.
The basic idea for packet reception with ccRTP is that the application does not directly read packets from sockets but gets them from a reception queue. The stack is responsible for inserting received packets in the reception queue and handling this queue. In general, a packet reception and insertion in the reception queue does not occur at the same time the application gets it from the queue.
Conversely, the basic idea for packet transmission with ccRTP is that packets are not directly written to sockets but inserted in a transmission queue handled by the stack. In general, packet insertion and transmission occur at different times, though it is not necessary.
In order to use ccRTP, you must include the main header (#include < ccrtp/rtp.h >. Two additional headers are provided by ccRTP:
#include < ccrtp/rtppool.h
Classes for pools of RTP service threads.
#include < ccrtp/rtpext.h >
Classes for RTP extensions which are not mature yet.
You must also link in the library, currently ccrtp1.
Enhancements:
- Brand new support has been introduced for Secure RTP Profile (srtp) as per RFC 3711.
- This release also supports a new add-on package, libzrtpcpp, that directly offers native zfone (zrtp) compatible encryption capabilities to Common C++ RTP based applications.
- This is the first softphone client to use both Common C++ RTP srtp and zrtp support.

XNap Commons project provides a set of utility Java classes for easy handling of common tasks like sortable tables, auto completion, and internationalization, a settings framework, and Swing components like common dialogs, a wizard, a closeable tabbed pane, a directory chooser, and whats-this-style context help.
Enhancements:
# New Features:
- IconHelper has been enhanced with a methods getApplicationIcons() to retrieve a list of application icons and getSystemTrayIcon() to retrieve an icon for the Java 6 system tray.
# Fixed bugs:
- The CloseableTabbedPane has been fixed to work on Java 6.

PyMusicD is yet another jukebox daemon written in python. It was born out of my frustration with the current mp3 jukeboxes, mostly the lack of features that I want. Ive also been playing with python quite a lot lately, and this is my first attempt at a large project in python.
The player is being written to satisfy my own requirements for a car mp3 player, although theres no reason you couldnt use this for a home mp3 player, or work mp3 player.
It assumes that your network users are (mostly) benign, and doesnt take a lot of precautions against malicious users who want to screw with your mp3s. Take appropriate measures to only allow trusted users to play with it, at least until I secure it a bit better.
Its primary purpose is to run in the background, and play mp3s whenever they are in the playlist.
Usage
Unpack this to its own directory. Edit the pymusicd.conf file to your liking. Run python PyMusicD, then run python pymusic to play around with it. The client operates very similarly to most shells, and includes tab completion for commands (but not arguments... yet.)
If you wish to install this to the system, you may do so by running python setup.py install. This will install the server binary in the default place for your platform (according to distutils.) You may then edit the config file (/etc/pymusicd.conf by default) and run the server by running PyMusicD. The cli client will be named pymusic.
This software is currently in development. It is not ready for end users yet. You should have familiarity with scripting in python before you set about to use this software. That being said, if you find bugs that arent listed in TODO, and/or have problems with the software that arent listed in TODO, email me (zwhite@darkstar.frop.org) and Ill see what I can do to help you. Code patches/suggestions are always welcome.
This is known to work on my Slackware 9.0 machine using the Python 2.2.2 package that came with it. I have also tested it on my Mac OSX 10.2.8 machine with Python 2.2. I have no reason to believe that it wont work on any machine with a Python 2.x interpreter and
either mpg123 or mpg321. Your mileage may vary. If it doesnt work on your platform, please let me know. My goal is to have this work on any platform that python runs on.
Enhancements:
- Fixed a bug when adding an entire directory with %2A instead of *
- Added a debug command to get server state, currently only playstatus is reported, will add more as needed.
- Changed the way the stop command works to eliminate a bug.
- Check to make sure a file exists before we add it to the playlist.
- We no longer start playing music as soon as the playlist has entries.
- Instead, we wait for a play command to be issued.
- Added config file support. Defaults to /etc/pymusicd.conf or ./pymusicd.conf
- Added a setup.py and setup.cfg file. Now users can install PyMusicD using the standard "python setup.py install" method that other scripts and modules use.

Emacs Common Lisp is an implementation of Common Lisp, written in Emacs Lisp. It does not yet purport to conform to the ANSI standard since, among other things, CLOS, and pretty printing are missing.

However, most other Common Lisp features like lexical closures,
packages, readtables, multiple values, bignums, adjustable arrays, etc, are present. At this stage many bugs remain and error checking is sparse.

This implementation provides a Common Lisp environment, separate from Emacs Lisp, running in Emacs. It does not intend to extend Emacs Lisp with Common Lisp functionality; however, Common Lisp functions compile to byte code, so Emacs Lisp functions can call Common Lisp functions and vice versa.

All Emacs Lisp data can be passed unchanged to Common Lisp functions, except vectors, which are used to implement various Common Lisp types not present in Emacs Lisp.

An Emacs Lisp vector should be converted to a Common Lisp vector (SIMPLE-VECTOR or VECTOR) when passed to a Common Lisp function.

Top Music allows you to publish music (albums, songs, sound tracks, rankings, artists, etc.) to create an online music portal.

It features: A-Z list of bands; band information (name, photo, genre, biography, etc.); discography; album information (title, year, covers, band, etc.); albums songs lists; song information (title, album, number, lyrics, etc.); the ability to listen to tracks; searching; ranking lists (most visited, most voted, etc.); a voting system; an uploads system; themes; an easy configuration screen; many blocks; multi-language support; easy installation; and a support forum, mailing lists, and Sourceforge.net support (CVS, files, etc.)

Steel Bank Common Lisp is a development environment for Common Lisp, with excellent support for the ANSI standard: garbage collection, lexical closures, powerful macros, strong dynamic typing, incremental compilation, and the famous Common Lisp Object System (multimethods and all).

Steel Bank Common Lisp also includes many extensions, such as native threads, socket support, a statistical profiler, programmable streams, and more. These are all available through an integrated, interactive native compiler which feels like an interpreter.

SBCL is unique in being a multiplatform native compiler which bootstraps itself completely from source, using a C compiler and any other ANSI Common Lisp implementation.

Whats New in This Release:

* enhancement: experimental macro SB-EXT:COMPARE-AND-SWAP provides
atomic compare-and-swap operations on threaded platforms.
* enhancement: experimental function SB-EXT:RESTRICT-COMPILER-POLICY
allows assining a global minimum value to optimization qualities
(overriding proclamations and declarations).
* enhancement: closed over variables can be stack-allocated on x86
and x86-64.
* performance bug fix: GETHASH and (SETF GETHASH) are once again
non-consing.
* optimization: slot definition lookup is now O(1). This speeds up
eg. SLOT-VALUE and (SETF SLOT-VALUE) with variable slot names.
* optimization: STRING-TO-OCTETS is now up to 60% faster for UTF-8.
* optimization: ASSOC and MEMBER can now be open-coded for all
combinations of keyword arguments when second argument is constant
and SPEED >= SPACE. In other cases a specialized version is
selected.
* bug fix: using obsoleted structure instances with TYPEP and
generic functions now signals a sensible error.
* bug fix: threads waiting on GET-FOREGROUND can be interrupted.
(reported by Kristoffer Kvello)
* bug fix: backtrace construction is now more careful when making
lisp-objects from pointers on the stack, to avoid creating bogus
objects that can be seen by the GC.
* bug fix: defaulting of values in contexts expecting more than 7
variables now works on x86-64. (reported by Christopher Laux)
* bug fix: modifications to packages (INTERN, EXPORT, etc) are now
thread safe.
* bug fix: (SETF SYMBOL-PLIST) no longer allows assigning a non-list
as the property-list of a symbol.
* bug fix: DEFMETHOD forms with CALL-NEXT-METHOD in the method body,
in EVAL-WHEN forms with both :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL
situations requested, are once again file-compileable. (reported
by Sascha Wilde)