Re: [linux-audio-dev] Re: [alsa-devel] Re: well why,... ->>> Music Composition Environment(s)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: [alsa-devel] Re: well why,... ->>> Music Composition Environment(s)
From: David Slomin (david.slomin_AT_av.com)
Date: Wed Sep 13 2000 - 18:15:18 EEST


Hi there --

One thing you may wish to consider: you're discussing a number of
different tasks, and the optimal interface for each may well be
different. As such, you may find it more appropriate to make
separate applications which are designed to cooperate well, rather
than a monolithic, all-encompassing environment.

Tasks of computer music software to consider:

1. Composition

Designing the piece of music. This is the task which a music
copyright protects: the melody, the chordal structure, the layout
of the song. Here, for instance, repeated sections of a song would
be presented as such (identical), whereas during a performance,
they would most likely be played with some variation to make it more
interesting.

For the task of composition, popular interfaces include the
following: (a) a simple piano roll for setting up melodies and
harmonies; (b) a chord editor for setting up chordal structure;
(c) a drum pattern editor for setting up drum patterns only in
those compositions where percussion features as a melodic element;
and either (d) a graphic block layout editor or (e) a programmatic
language for setting up the sections of a song.

There are additional specialized compositional interfaces required
for certain types of music, such as a programmatic language for
algorithmic composition, or an audio sample editor for those
compositions where a particular sample (sound effect, voice, etc)
makes up the core nature of the song (ie: it would be a completely
different song if that sample was changed or missing).

2. Publishing for computer performance

This task is where you describe exactly how the piece should sound
when performed electronically either using some internal software
method (as in the case of MOD trackers), or by communications to
some hardware device (as in the case of MIDI). In this task,
timing and nuance become core issues, as do instrumentation,
timbre, etc.

Popular interfaces for this task include the following:
(a) a detailed piano roll for setting up timing information
or fine-tuning a recorded performance; (b) a tempo graph;
(c) gesture graphs, such as those used to set up continuous
controllers for MIDI; (d) tracker-style parameter editing
tables; (e) control panels for synthesizer and effects processor
parameters; and (f) audio sample editors, (g) loop editors, and
(h) audio spectrum editors for sampler parameters.

3. Publishing for human performance

In other words, printing out the results of the composition task
in a form which human musicians can read. This form is usually
CMN (Common Music Notation, what you generally think of as
printed music), but there are many others used for particular
instruments or genres of music, including tablature, chord
charts, plainchant notation, shape singing notation, and ABC.

The core issue of this task is the problem that most of these
human readable forms (CMN especially) are inconsistent with
themselves, and not particularly expressive nor precise.
The most popular interface for this, of course, is a graphical
CMN score editor, although programmatic layout languages have
been tried before as well.

4. Interactive performance

This is a much less explored task where computers and human
performers combine in realtime to produce the piece of music.
By its very nature, a piece produced in this manner will be
different every time it is played, not fully composed nor
notated beforehand.

For this task, it is hard to point to popular interfaces,
since each existing program seems to come up with an entirely
unique one. Most of them incorporate hardware interface
devices such as MIDI controllers, joysticks, switches, knobs,
sliders, proximity sensors, etc, in addition to any
software-based interfaces they have. The extent of overlap
which should exist between this and the task of publishing for
pure computer performance depends on how much of the song is
to be specified ahead of time.

Most commercial music software houses have realized that you
can make more money selling big, monolithic packages than
selling small, independent but cooperative pieces. (The
monetary gain comes from selling consumers things which they
don't need, and wouldn't buy piecemeal.) However, in the
world of free software, we don't have any incentive to
sacrifice the quality of the interface for financial gain.

Just a thought to keep in mind,
Div.

(who has largely clammed up and decided to lurk in recent
months since he's been too busy with the real world to produce
any new software of the LAD variety)

Allan Klinbail wrote:
>
> Eric Bresie wrote:
>
> > > From: On Behalf Of Allan Klinbail
> > > Sent: Wednesday, September 06, 2000 8:00 AM
> >
>
> I'll have a quick go at this. This topic was spawned on ALSA-DEV ML. It
> has been pointed that it is more appropriate here.
>
> > What exactly makes a good UI for music creation?
> >
> > You can have a way of entering it like sheet music.
>
> For classically trained "sight readers" this is a fantastic way to
> compose. However, many of us do not think naturally in score format
> (including myself). Apart from having to be score literate traditional
> notation does not allow for viewing of many features MIDI offers, such
> as controller information.
>
> >
> > You can enter it like a tracker (which often times seems cryptic to
> > me).
>
> I agree, and before you all send a thousand mails at me, many don't.
> However, I believe that pure tracker type software is very much
> established and those using it do not use it to control externel
> devices, mainly samples. OTOH, step style sequencing is a feature that
> is highly useful, while not all the time different types of melodical
> lines are achieved with step style sequencing of MIDI. Logical editors
> within sequencers (which function almost exactly like trackers)
> areparticularly useful for refining the MIDI data to achieve the exact
> timing wanted and for cleaning out excess data which can make
> synthesisers pop and click or simply give a MIDI BUFFER FULL type
> message (this is particulalry true for older keyboards e.t.c.)
>
> > You can use a keyboard (real or virtual)
>
> For myself, this feature within a sequencer is a must, but again not the
> be all and end all.
>
> >
> > You can use sequencer (real or virtual) like tools.
>
> Interfaces such as Cubase, Cakewalk and Logic have the most useable
> interface so - far. Muse has taken this style of approach,
> incoroporation of the features as mentioned above would make it very
> powerful indeed. The interface for JAZZ++ is satisfactory but not quite
> as good, as cutting and pasting is defined by the bar not a loops or
> riffs graphcially represented as blocks which can be picked up and moved
> around.
>
> > Is it better to include one or more of the following?
>
> THe more, the better, flexibility is the key to a good commposition
> environment.
>
> >
> > What do professions tend to use? Would like to use? Would like to be
> > made
> > to use?
>
> Personally, I use one of the above mentioned WIndows softwares. I would
> like to use something that bases itself around that style of
> environment, which gives you an arrangement screen (to drag and drop
> blocks), where individual tracks can be edited in a number of ways, most
> importantly with logical editors and step editing/recording functions.
> Piano-roll editors I have not found being used by many other
> professionals, however this system led to the development of the drum
> editor (like in Cubase) which is a fantastic tool if you don't have a
> drum machine (and even if you do). Score editing is required by few,
> however score publishing is essential to many composing for groups of
> real musicians (or handing in assignments).
>
> Further to this, a trend began with he big commercial MIDI sequencer
> developers just prior to getting hooked on audio, this was to develop
> more and more interesting MIDI interpolation tools/algorithms. Such as
> style quantising, MIDI delay units and highly configurable arpeggiators
> (to name a short list) more of these tools within a linux based
> sequencer could be very interesting. One idea that just popped to mind
> would be an assignable and clock syncable (but not fixed to MIDI clock
> necessarily) LFO (low frequency oscillator) that can be applied to any
> MIDI controller or note sequence.
>
> THe incorporation of LADSPA is already happening, however it would be
> really nice to see C-sound, Jmax (or other similar platforms) to be
> hosted and hence controlled by the sequencer most importantly to easily
> integrate them into a composition. I may be dreaming here of course.
> MIDI controllable LADSPA (i.e. VST2) would be fantastic. Controlling
> something like reverb depth with a controller can make for more detailed
> recordings and more precise experimentation with these tools.
>
> I don't want to be made to use anything, as mentioned before the more
> flexibility within a composition environment the better.
>
> > Which features in exsisting systems (like Jazz++, Quasimodo,etc) are
> > appealing?
>
> See all of the above.
>
> >
> >
> > Just identifying requirements for such an "ideal music creation"
> > tool. Who
> > knows, if there is enough interest, maybe I can start something on
> > sourceforge (which I think was where this whole thread started from
> > :-)
>
> Thanks for asking some question I feel I can answer.
>
> Just to remind everybody , my studio is happy to test new programs (well
> maybe after the album launch on October 13)
>
> cheers and best wishes to all here
>
> Allan Klinbail
>
> >
> >
> > Eric Bresie
> > ebresie_AT_usa.net
> >
> > ------
> > To unsubscribe from <alsa-devel_AT_alsa-project.org> mailing list send
> > message
> > 'unsubscribe' in the body of message to
> > <alsa-devel-request_AT_alsa-project.org>.
> > BUG/SMALL PATCH REPORTING SYSTEM:
> > http://www.alsa-project.org/cgi-bin/bugs


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Sep 13 2000 - 19:23:34 EEST