2 May
2005
2 May
'05
7:01 p.m.
Dear list,
I am currently designing a new kind of music sequencer and I
need your help in making some crucial decisions.
Introduction
My project is a sequencer for composing Just Intonation music.
Just Intonation is not a new idea in the music landscape, not by a long
shot: it has roots in the first studies of music by the ancient Greeks.
The GUI I'm designing though will (hopefully) be the first of its kind.
My sequencer is going to be just that: a sequencer. It will be hard
enough to design an efficient, user-friendly and solid GUI for composing
music without a scale (yes, you read it right) so I'm not going to put
synthesis modules in the same software package. Not at first, anyway.
MIDI
Here comes the biggest problem. I cannot use MIDI as a protocol between
my sequencer and the syntesizers, because most (if not all) of the notes
produced by my software will not lie in the equal tempered scale (the 12
notes per octave everyone knows) nor in any other scale for that matter.
Please correct me if I'm wrong: MIDI doesn't allow for microtonal notes.
The best next things MIDI has to offer are Custom Scales and Pitch Bend.
Custom Scales is not a feature of MIDI, it's more like a reinterpreta-
tion of the protocol. It happens when both the sequencer and the
synthesizer are still talking of C, C#, D, D#... but the synthesizer
renders those notes with custom pitches, coming from a custom scale set
by the user. This approach is unsuitable to my project, mainly because
there could be more than 12 notes (pitches) in an octave.
Pitch Bend is not any better, because (to my knowledge) there is only
one pitch bend setting per channel. I could certainly use it to play
microtonal notes, but the pitch bend applies simultaneously to ALL notes
being played. This limits the applicability of pitch bend to monophonic
instruments, or at least to playing one voice per MIDI channel.
Alternatives
Is there a common protocol with the same scope as MIDI (transferring
notes from a sequencer to a synthesizer) but which allows for microtonal
notes? I fear not.
So I am left with the only option of manually interfacing my sequencer
to a select few software syntesizers. I'm designing my project in an
extensible way (support for plugins) so that's not so bad as it seems.
The problem is that I don't know of any software synthesizer that is:
1. good enough for decent music production;
2. easy to use by non-experts (this is a direct stab at CSound, or
better at its lack of a decent GUI, of a standard instrument exchange
file format and of a decent, centalized library of presets)
3. free software.
A final note: outputting SCO files for use in CSound seems like an
obvious solution, but this would greatly limit the usability of my
project. This is because (to my knowledge) there is no decent GUI one
can use to merge the SCO file coming from a sequencer with a few ORC/SCO
file-couples coming from an instrument library, without having to know
the CSound language. I don't want to target CSound programmers only.
I hope I've managed to explain my problem. Please feel free to dicuss
on these matters. Any constructive criticism, any note of mistakes on
my part and any practical advice for my project will be appreciated.
Toby
--
«A computer is a state machine. Threads are for people
who can't program state machines.» —Alan Cox
2 May
2 May
7:37 p.m.
enough to design an efficient, user-friendly and solid
GUI for composing
music without a scale (yes, you read it right) so I'm not going to put
the option of a "Scale" might be convenient for those who arent wishing to
compose drum hits or the like
Here comes the biggest problem. I cannot use MIDI as
a protocol between
my sequencer and the syntesizers, because most (if not all) of the notes
produced by my software will not lie in the equal tempered scale (the 12
notes per octave everyone knows) nor in any other scale for that matter.
Please correct me if I'm wrong: MIDI doesn't allow for microtonal notes.
The best next things MIDI has to offer are Custom Scales and Pitch Bend.
AFAIK this has been overcome by using 14 bits to describe the note, a similar hack has
been done for controller data. in fact, it is possible to use any multiple of 7 bits in
MIDI as well (correct me if im wrong). many VST hosts and instruments on windows for
example accept floating point note like 67.1234 and its rendered accordingly. there are
even MIDI plugins to microtune notes in this manner to different scales.
Is there a common protocol with the same scope as MIDI
(transferring
notes from a sequencer to a synthesizer) but which allows for microtonal
notes? I fear not.
OSC
8:44 p.m.
ix(a)replic.net wrote:
the option of a "Scale" might be convenient
for those who arent
wishing to compose drum hits or the like
I'm not sure I get all of your irony... :-) but rest assured that I
have good plans about this. I'm designing the interface on paper and
thinking it over even before venturing into UML class diagrams. It is
possible to compose music without a scale and I'm going to make it easy.
Hopefully.
AFAIK this has been overcome by using 14 bits to
describe the note
[...] many VST hosts and instruments on windows for example accept
floating point note like 67.1234 and its rendered accordingly.
This is *very* interesting to me!
Do you have any references/web sites/semi-official specifications/
list of supported software and hardware?
Every search I do for 'MIDI microtonality' and such yields information
about setting the tuning of hardware synths. That is of no use to me, I
need to be able to specify single notes with 1 cent accuracy (at least)
from my sequencer. If MIDI supported that, as you claim, it'd be great!
Toby
9:28 p.m.
AFAIK this has
been overcome by using 14 bits to describe the note
[...] many VST hosts and instruments on windows for example accept
floating point note like 67.1234 and its rendered accordingly.
This is *very* interesting to me!
Do you have any references/web sites/semi-official specifications/
list of supported software and hardware? 
3 May
3 May
2:37 a.m.
On Mon, 2005-05-02 at 23:01 +0200, Toby wrote:
--
(
)
c[] // Jens M Andreasen
Please correct me if I'm wrong: MIDI doesn't
allow for microtonal notes.
The best next things MIDI has to offer are Custom Scales and Pitch Bend.
Custom Scales is not a feature of MIDI, it's more like a reinterpreta-
tion of the protocol. It happens when both the sequencer and the
synthesizer are still talking of C, C#, D, D#... but the synthesizer
renders those notes with custom pitches, coming from a custom scale set
by the user. This approach is unsuitable to my project, mainly because
there could be more than 12 notes (pitches) in an octave.
Midi generally can't hear the pitches nor see your 12 note keyboard
layout. The triggers are all numbers and can corespond to any layout
(like a drumkit.) Having more than 12 notes/octave is mostly an
inconvenience for the player, learning to navigate on a keyboard build
for other purposes.
To my awareness, the hardware synths that do microtuning can be set up
any twisted imaginable way. You might have to look one page further down
though, to get past the 12 note/octave convenience setup.
Pitch Bend is not any better, because (to my knowledge) there is only
one pitch bend setting per channel. I could certainly use it to play
microtonal notes, but the pitch bend applies simultaneously to ALL notes
being played. This limits the applicability of pitch bend to monophonic
instruments, or at least to playing one voice per MIDI channel.
Alternatives
Is there a common protocol with the same scope as MIDI (transferring
notes from a sequencer to a synthesizer) but which allows for microtonal
notes? I fear not.
This one perhaps?
http://www.midi.org/about-midi/tuning.shtml
:)
9:57 a.m.
On Mon, 2005-05-02 at 23:01 +0200, Toby wrote:
THere was a piece written for the DX-7 (symphonia?) that had ~60
steps/octave. It wasn't diffucult to set up, just time consuming. All you
would have to do is program the multitune on each device - The MIDI note
number is layer of abstraction; it doesn't *need* to map to it's
traditional key.
Please correct me if I'm wrong: MIDI
doesn't allow for microtonal notes.
The best next things MIDI has to offer are Custom Scales and Pitch Bend.
Custom Scales is not a feature of MIDI, it'smore like a reinterpreta-
tion of the protocol.It happens when both the sequencer and the
synthesizer are still talking of C, C#, D, D#... but the synthesizer
renders those notes with custom pitches, coming from a custom scale set
by the user.This approach is unsuitable to my project, mainly because
there could be more than 12 notes (pitches) in an octave.
Midi generally can't hear the pitches nor see your 12 note keyboard
layout. The triggers are all numbers and can corespond to any layout
(like a drumkit.) Having more than 12 notes/octave is mostly an
inconvenience for the player, learning to navigate on a keyboard build
for other purposes.
To my awareness, the hardware synths that do microtuning can be set up
any twisted imaginable way. You might have to look one page further down
though, to get past the 12 note/octave convenience setup.
10:14 a.m.
On Tue, 2005-05-03 at 14:55 +0300, michael tewner wrote:
If "it" (symphonia?) was tuned even tempered 60 note/octave, the DX7*
will do the tuning in almost no time from the "convenience page". Select
"even tempered", select "60", done! (Well, approximately like that
...)
[*] The DX7 MkII that is. Or a MkI retrofitted with the kit from Grey
Matter Response.
--
(
)
c[] // Jens M Andreasen
To my awareness, the hardware synths that do microtuning can be set up
any twisted imaginable way. You might have to look one page further down
though, to get past the 12 note/octave convenience setup.
THere was a piece written for the DX-7 (symphonia?) that had ~60
steps/octave. It wasn't diffucult to set up, just time consuming. All you
would have to do is program the multitune on each device - The MIDI note
number is layer of abstraction; it doesn't *need* to map to it's
traditional key. 
11:37 a.m.
On Tue, May 03, 2005 at 02:14:46PM +0200, Jens M Andreasen wrote:
On Tue, 2005-05-03 at 14:55 +0300, michael tewner
wrote:
If "it" (symphonia?) was tuned even tempered 60 note/octave, the DX7*
will do the tuning in almost no time from the "convenience page". Select
"even tempered", select "60", done! (Well, approximately like that
...)
So you assign 60 pitches per octave - doesn't that leave you with
only just over a 2 octave range?
confused...
--
Paul Winkler
http://www.slinkp.com
To my awareness, the hardware synths that do microtuning can be set up
any twisted imaginable way. You might have to look one page further down
though, to get past the 12 note/octave convenience setup.
THere was a piece written for the DX-7 (symphonia?) that had ~60
steps/octave. It wasn't diffucult to set up, just time consuming. All you
would have to do is program the multitune on each device - The MIDI note
number is layer of abstraction; it doesn't *need* to map to it's
traditional key.
1:42 p.m.
On Tue, 2005-05-03 at 09:37 -0400, Paul Winkler wrote:
--
(
)
c[] // Jens M Andreasen
On Tue, May 03, 2005 at 02:14:46PM +0200, Jens M
Andreasen wrote:
Right, and you'd need an incredible 10 meter wide keyboard for an 8
octave range, split over a handful of devices ...
:-o
On Tue, 2005-05-03 at 14:55 +0300, michael tewner
wrote:
If "it" (symphonia?) was tuned even tempered 60 note/octave, the DX7*
will do the tuning in almost no time from the "convenience page". Select
"even tempered", select "60", done! (Well, approximately like that
...)
So you assign 60 pitches per octave - doesn't that leave you with
only just over a 2 octave range?
confused...
To my awareness, the hardware synths that do microtuning can be set up
any twisted imaginable way. You might have to look one page further down
though, to get past the 12 note/octave convenience setup.
THere was a piece written for the DX-7 (symphonia?) that had ~60
steps/octave. It wasn't diffucult to set up, just time consuming. All you
would have to do is program the multitune on each device - The MIDI note
number is layer of abstraction; it doesn't *need* to map to it's
traditional key. 
10:26 a.m.
Greetings:
Considering its suitability for microtonality, why not design
something around Csound ?
Best,
dp
10:45 a.m.
On Tue, May 03, 2005 at 08:36:29AM -0400, Dave Phillips wrote:
Considering its suitability for microtonality, why
not design
something around Csound ?
From the origianl post:
The problem is that I don't know of any software
synthesizer that is:
1. good enough for decent music production;
2. easy to use by non-experts (this is a direct stab at CSound, or
better at its lack of a decent GUI, of a standard instrument exchange
file format and of a decent, centalized library of presets)
3. free software.
:-) :-| :-(
To add my 0.02 Euro : I'm sure that OSC is the way to go for this project.
And I'd love to have an 'OSC sequencer' -- something that allows you to
schedule / edit / manipulate arbitrary OSC events, and with a non-destructive
region editor similar to Ardour's.
--
FA
11:28 a.m.
On Tue, May 03, 2005 at 08:57:56AM -0400, Paul Davis wrote:
:-)
The first step towards this could well be taken one of these days. As
you know I've beem experimenting with a second DLL, based on system
time in JACK. I'm currently trying to decide what should be the exact
time scale and format of this timer, and it could very well end up being
exactly the same as OSC time (modulo a fixed offset maybe).
--
FA
To add my 0.02
Euro : I'm sure that OSC is the way to go for this project.
And I'd love to have an 'OSC sequencer' -- something that allows you to
schedule / edit / manipulate arbitrary OSC events, and with a non-destructive
region editor similar to Ardour's.
Ardour v2.3 ... 
11:42 a.m.
On Tue, May 03, 2005 at 08:57:56AM -0400, Paul Davis
wrote:
:-)
I am not joking. This is on the roadmap for Ardour. When we add MIDI,
the goal is to generalize to handle arbitrary non-streaming
byte-oriented protocols.
--p
>To add my 0.02 Euro : I'm sure that OSC
is the way to go for this project.
>And I'd love to have an 'OSC sequencer' -- something that allows you to
>schedule / edit / manipulate arbitrary OSC events, and with a non-destructi
ve
region
editor similar to Ardour's.
Ardour v2.3 ... 
11 a.m.
To add my 0.02 Euro : I'm sure that OSC is the way
to go for this project.
And I'd love to have an 'OSC sequencer' -- something that allows you to
schedule / edit / manipulate arbitrary OSC events, and with a
non-destructive
region editor similar to Ardour's.
An OSC sequencer would have to be written such that it would have no
preconceptions of what the data was actually representing, you could set
up all sorts of filtering, conditional events, remapping of messages etc.
I think it could be really powerful if done correctly. The worst thing
would be a sequencer that forced OSC to look like midi - with note
ons/offs etc.
cheers,
dave
11:06 a.m.
New subject: [linux-audio-dev] Common synthesizer interface -or- microtonal
On Tue, May 03, 2005 at 06:00:03AM -0700, dave(a)pawfal.org wrote:
Thats true, but it might also be nice to be able to plug in schema
modules, that could handle certain methods more conviently*. Much like the
sysex librarian plugins that know how to handle sysex for a particular
synth.
* eg. showing a paino keyboard widget for quantised pitch information.
- Steve
To add my 0.02
Euro : I'm sure that OSC is the way to go for this project.
And I'd love to have an 'OSC sequencer' -- something that allows you to
schedule / edit / manipulate arbitrary OSC events, and with a
non-destructive
region editor similar to Ardour's.
An OSC sequencer would have to be written such that it would have no
preconceptions of what the data was actually representing, you could set
up all sorts of filtering, conditional events, remapping of messages etc.
I think it could be really powerful if done correctly. The worst thing
would be a sequencer that forced OSC to look like midi - with note
ons/offs etc.
11:33 a.m.
Alfons Adriaensen wrote:
On Tue, May 03, 2005 at 08:36:29AM -0400, Dave Phillips
wrote:
Well, Csound is being used for just that purpose. Perhaps the original
poster should check out recent traffic on the Csound mail lists.
Considering its suitability for microtonality,
why not design
something around Csound ?
From the origianl post:
>The problem is that I don't know of any software synthesizer that is:
>
>1. good enough for decent music production;
> >2. easy to use by non-experts (this is a direct
stab at CSound, or
> better at its lack of a decent GUI, of a standard instrument exchange
> file format and of a decent, centalized library of presets)
>
Csound has no integral GUI, sorry. It does have a set of FLTK-based GUI
widgets which lets you create your own GUI.
The Csound orc file has been and still is the way Csounders exchange
instruments. There are in fact a number of instrument libraries out
there. I think the original poster might not be quite up to date on Csound.
>3. free software.
>
>
Csound is LGPL and has been for some time now.
To add my 0.02 Euro : I'm sure that OSC is the way
to go for this project.
And I'd love to have an 'OSC sequencer' -- something that allows you to
schedule / edit / manipulate arbitrary OSC events, and with a non-destructive
region editor similar to Ardour's.
Sounds cool, I'd like to see that too.
Btw, Rocky was a project with somewhat similar goals, a sequencer for
22-tone ET, using Csound for its rendering engine and Java for its GUI.
Alas, Rocky appears to have disappeared. [Insert obligatory Sylvester
Stallone joke here].
Best,
dp
4:31 p.m.
New subject: [linux-audio-dev] CSound usability (was: Common synthesizer interface...)
Hi all
I'm still studying the solutions you people kindly gave me in my other
thread, but I thought I'd post this slightly OT spinoff in the meantime!
:-)
Dave Phillips wrote:
I might very well fail be up to date on CSound, in fact I'm still
trying to find my way through it and all the various interfaces/
utilities/extensions/what-not people have come up with.
But from my (limited) experience I see that not only does writing a
CSound instrument require knowledge of the CSound language and of its
architecture (that's obvious), but that *incorporating* an existing
CSound instrument into a new composition requires almost the same
skills. And those are computer programmer-level skills, not average
music writer-level ones.
I'm not running down CSound, I'm just backing my claim that it's not
easy to use by non-experts. At all.
Let's make a comparison, although a simple, maybe unworthy one: Reason™.
Novice users don't *need* to know how the Malström* works to be able to
1. load a patch 2. give it MIDI input and 3. start playing. They only
need that kind of skill if they want to make their own patches or modify
existing ones. (*: a small piece of soft-synth found in Reason™)
Granted, the power of any synth lies in customization, but IMHO part of
its *usability* lies in being able to play it *without* knowing how to
program it. That's what presets are for anyways!
I'm under the impression that CSound fails right there.
An ORC file you say? Most of the instruments I've seen need both and
ORC and a SCO file to be of any use (problem #1.) Moreover, since you
need to come up with a single ORC and a single SCO to make CSound render
your composition, you have to merge the various ORC/SCO file-pairs of
the instruments you want to use, along with the additional SCO file
containing the actual notes (problem #2) and AFAIK you need vast
knowledge of the ORC and SCO syntax to be able to do it (problem #3.)
I could go on, but I think you see my point. (Unless I'm seriously
misunderstanding how CSound works nowadays, in which case I'll apologize
to everybody and go read some CSound mailing list archives!)
Toby
> From the original post:
>
> The problem is that I don't know of any software synthesizer that is:
[snip]
2. easy to use
by non-experts
(this is a direct stab at CSound, or better at its lack of a
decent GUI, of a standard instrument exchange file format and of
a decent, centalized library of presets)
Csound has no integral GUI, sorry. It does have a set of FLTK-based
GUI widgets which lets you create your own GUI.
The Csound orc file has been and still is the way Csounders exchange
instruments. There are in fact a number of instrument libraries out
there. I think the original poster might not be quite up to date on
Csound.
5:59 p.m.
New subject: [linux-audio-dev] CSound usability
Toby wrote:
I'm still studying the solutions you people kindly
gave me in my other
thread, but I thought I'd post this slightly OT spinoff in the meantime!
Dave Phillips wrote:
I might very well fail be up to date on CSound, in fact I'm still
trying to find my way through it and all the various interfaces/
utilities/extensions/what-not people have come up with.
But from my (limited) experience I see that not only does writing a
CSound instrument require knowledge of the CSound language and of its
architecture (that's obvious), but that *incorporating* an existing
CSound instrument into a new composition requires almost the same
skills. And those are computer programmer-level skills, not average
music writer-level ones.
I taught myself how to use Csound, I have no special background in
mathematics or computer programming.
>From the original post:
>
>The problem is that I don't know of any software synthesizer that is:
>
>
[snip]
2. easy to
use by non-experts
(this is a direct stab at CSound, or better at its lack of a
decent GUI, of a standard instrument exchange file format and of
a decent, centalized library of presets)
Csound has no integral GUI, sorry. It does have a set of FLTK-based
GUI widgets which lets you create your own GUI.
The Csound orc file has been and still is the way Csounders exchange
instruments. There are in fact a number of instrument libraries out
there. I think the original poster might not be quite up to date on
Csound.
I'm not running down CSound, I'm just backing
my claim that it's not easy to use by non-experts. At all.
Some non-experts work harder at this kind of thing. I'm one.
I think by the time you're done learning how to write your
sequencer/synthesizer you'll have spent considerably more time learning
how to do that than you would have spent learning how to use Csound. ;-)
Let's make a comparison, although a simple, maybe
unworthy one: Reason™.
Novice users don't *need* to know how the Malström* works to be able to
1. load a patch 2. give it MIDI input and 3. start playing. They only
need that kind of skill if they want to make their own patches or modify
existing ones. (*: a small piece of soft-synth found in Reason™)
Granted, the power of any synth lies in customization, but IMHO part of
its *usability* lies in being able to play it *without* knowing how to
program it. That's what presets are for anyways!
I might have misunderstood your original intent. I thought you *wanted*
a programmable synth with exceptional microtuning capabilities.
An ORC file you say? Most of the instruments I've
seen need both and
ORC and a SCO file to be of any use (problem #1.) Moreover, since you
need to come up with a single ORC and a single SCO to make CSound render
your composition, you have to merge the various ORC/SCO file-pairs of
the instruments you want to use, along with the additional SCO file
containing the actual notes (problem #2) and AFAIK you need vast
knowledge of the ORC and SCO syntax to be able to do it (problem #3.)
I think you don't completely understand Csound, especially modern
Csound. The orc file defines the instrument, always. The sco file
supplies the instrument (s) with parameter values and event times
(start/duration). Contemporary Csounders usually use the CSD unified
file format to define both instrument and score within a single file.
There are many catalogs and collections of predefined Csound
instruments, or you can simply borrow and build from the examples found
in the many available Csound compositions.
I occasionally teach Csound to high-school students, again with no
special background beyond their basic music skills.
I could go on, but I think you see my point. (Unless
I'm seriously
misunderstanding how CSound works nowadays, in which case I'll apologize
to everybody and go read some CSound mailing list archives!)
If you're coming from a point & click environment then indeed Csound may
not be sufficiently amenable, but it does do what you're looking for in
a synthesizer.
Best,
dp
4 May
4 May
9:59 a.m.
New subject: [linux-audio-dev] CSound usability
I taught myself how to use Csound, I have no special
background in
mathematics or computer programming.
But you're on the LAD list! Just subscribing to a list is a harder
technical task than some musicians I know are capable of ;)
I think by the time you're done learning how to
write your
sequencer/synthesizer you'll have spent considerably more time learning
how to do that than you would have spent learning how to use Csound. ;-)
Yeah but not the point - the programmer does the work so the users
don't have to.
The sco file
supplies the instrument (s) with parameter values and event times
(start/duration). Contemporary Csounders usually use the CSD unified
file format to define both instrument and score within a single file.
In my experience (correct me if I'm wrong), many instruments don't
work unless you set up (eg) the right wavetables in the .sco file. I
don't know how much the .csd format helps this.
But it's certainly true that if you put all the right bits of CSound
add-ons together, you can get a nice and usable system. Modularity is
nice, but the lists of add-ons at www.csounds.com is pretty
frightening.
My 2 cents
10:34 a.m.
New subject: [linux-audio-dev] CSound usability
James McDermott wrote:
Well, actually I was one of the founders. I don't recall ever explicitly
subscribing, maybe someone did it for me. Given my music background, I'm
not sure I could do it on my own. ;-)
Makes me wonder if I could apply for a disability pension...
I taught myself
how to use Csound, I have no special background in
mathematics or computer programming.
But you're on the LAD list! Just subscribing to a list is a harder
technical task than some musicians I know are capable of ;)
In my experience (correct me if I'm wrong), many
instruments don't
work unless you set up (eg) the right wavetables in the .sco file. I
don't know how much the .csd format helps this.
You aren't up to date. Function tables can be defined in the orc file too.
Many instruments work even with the "wrong" function table. You can have
much fun mixing and matching ftable definitions, and the interested
student can learn a lot by changing elements of even the most simple
wavetable.
Btw, the CSD format simply combines orc, sco, and command-line options
neatly into one file format. I believe it is also possible to embed MIDI
and binary files into a CSD file, but don't quote me on that yet.
But it's certainly true that if you put all the
right bits of CSound
add-ons together, you can get a nice and usable system. Modularity is
nice, but the lists of add-ons at www.csounds.com is pretty frightening.
Well, you certainly aren't required to learn and/or use them all. I've
learned Csound as I've learned any musical instrument: I acquire needed
skill as I need it. I practice to extend and maintain chops, but if I
want to use a new method or technique I dig in and learn something new.
Frankly, if you've made the effort to learn how to play an instrument to
some degree of familiarity then you've already displayed intelligence
enough to learn how to use something like Csound. Or perhaps I have an
unwarranted high estimation of the intelligence of my fellow citizens ? ;-)
Best,
dp
3 May
3 May
10:53 a.m.
Greetings:
Considering its suitability for microtonality, why not design
something around Csound ?
The best solution is to remove the mapping from note number to frequency,
and directly send the frequency to the synth. I use OSC messages to do
this (my sequencer uses the scala tuning format).
OSC should replace midi for internal communication - the first OSC
hardware has started to appear already, so maybe for external
communication too, one day :)
It would be interesting to compare the ways that OSC based synths are
accepting note information and try to arrive at some sort of standard.
cheers,
dave
3:51 a.m.
On Mon, 2005-02-05 at 23:01 +0200, Toby wrote:
Is there a common protocol with the same scope as MIDI
(transferring
notes from a sequencer to a synthesizer) but which allows for microtonal
notes? I fear not.
Yep. Open Sound Control (OSC)
http://www.cnmat.berkeley.edu/OpenSoundControl/
You can send pretty much whatever you want, the receiver will have to
understand whatever commands you're sending to it though.
In other words, you may need to do a little bit of work on your
receiving synths, but doing it via OSC is a million times better (and
easier) than custom hacked interfacing to one synth.
-DR-
5:33 p.m.
New subject: [linux-audio-dev] timesetevent alternative
Hello, About 5 years ago I hacked together a nice midi looper app. The
only problem is that it was for Windows. Anyway... I'm working towards
reimplamenting the app in linux. Basically, I have a circular linked
list of midi events. Each node has the event and the time to the next
event. In Windows there was a timeSetEvent function. I pass this
function the time_to_next_event,
function_to_call_after_time_to_next_event, and
data_to_pass_to_function. The function_to_call_after_time_to_next_event
just outputs the event and then calls timeSetEvent with the next nodes
data. I'm curious as to how others would implament something similar in
linux. Perhaps as a thread with sleep call? Is there a high resolution
sleep function? Any ideas? Thanks. -Garett
6:01 p.m.
New subject: [linux-audio-dev] timesetevent alternative
I would probably lock on to the audio clock, in jack or otherwise, since
this is were it all ends up ultimately.
When the jack_process() gets called, count down the time to wait untill
time is zero or less, in which case you do your midi thing and pick the
next event.
On Tue, 2005-05-03 at 13:33 -0600, Garett Shulman wrote:
Hello, About 5 years ago I hacked together a nice midi
looper app. The
only problem is that it was for Windows. Anyway... I'm working towards
reimplamenting the app in linux. Basically, I have a circular linked
list of midi events. Each node has the event and the time to the next
event. In Windows there was a timeSetEvent function. I pass this
function the time_to_next_event,
function_to_call_after_time_to_next_event, and
data_to_pass_to_function. The function_to_call_after_time_to_next_event
just outputs the event and then calls timeSetEvent with the next nodes
data. I'm curious as to how others would implament something similar in
linux. Perhaps as a thread with sleep call? Is there a high resolution
sleep function? Any ideas? Thanks. -Garett
--
(
)
c[] // Jens M Andreasen
6:44 p.m.
New subject: [linux-audio-dev] timesetevent alternative
I would probably lock on to the audio clock, in jack or
otherwise, since
this is were it all ends up ultimately.
When the jack_process() gets called, count down the time to wait untill
time is zero or less, in which case you do your midi thing and pick the
next event.
that depends. is this a MIDI-only looper, or a MIDI-driven audio
looper?
usleep (2) is the canonical high resolution sleep function on POSIX
(although nanosleep(2) is a close cousin). the resolution is limited
by the system timer interrupt frequency, which is typically either
100Hz (2.4 and older kernels) or 1kHz (2.6 kernels)
--p
6 May
6 May
10:23 a.m.
New subject: [linux-audio-dev] timesetevent alternative
Paul Davis wrote:
usleep (2) is the canonical high resolution sleep
function on POSIX
(although nanosleep(2) is a close cousin). the resolution is limited
by the system timer interrupt frequency, which is typically either
100Hz (2.4 and older kernels) or 1kHz (2.6 kernels)
Right,
nanosleep() might be a bit more precise than usleep() but for low sleep
values ( AFAIK < 2msec ) it
busywaits when you run your app SCHED_FIFO which in the case of
sustained streams of low sleep values
could chew up all the CPU, not idea for real time audio apps.
Last time I tried usleep() on a 2.4 kernel with HZ=1000 ( Red Hat
kernels come with HZ=1000 by default),
the resolution was
usleep(x)
the minimum real sleep value was 2msec , no matter how small x was
if x > 2000 (=2msec) then usleep always sleeps floor(x/1000)+1 msecs.
For MIDI playback usleep() on a 1000Hz kernel (fortuntately on 2.6
kernels HZ=1kHz is the standard) is completely fine.
Of course if you want sample accuracy then the MIDI sequencer requires a
mechanism ala VSTi to pass time stamped events
to software MIDI instruments.
cheers,
Benno
http://www.linuxsampler.org
4:17 p.m.
New subject: [linux-audio-dev] timesetevent alternative
On Fri, 2005-05-06 at 14:30 +0200, Benno Senoner wrote:
Paul Davis wrote:
Not anymore. From man 2 nanosleep:
Old behaviour
In order to support applications requiring much more precise
pauses (e.g., in order to control some time-critical hardware),
nanosleep would handle pauses of up
to 2 ms by busy waiting with microsecond precision when called
from a process scheduled under a real-time policy like SCHED_FIFO or
SCHED_RR. This special
extension was removed in kernel 2.5.39, hence is still present in
current 2.4 kernels, but not in 2.6 kernels.
Lee
usleep (2) is the canonical high resolution sleep
function on POSIX
(although nanosleep(2) is a close cousin). the resolution is limited
by the system timer interrupt frequency, which is typically either
100Hz (2.4 and older kernels) or 1kHz (2.6 kernels)
Right,
nanosleep() might be a bit more precise than usleep() but for low sleep
values ( AFAIK < 2msec ) it
busywaits when you run your app SCHED_FIFO which in the case of
sustained streams of low sleep values
could chew up all the CPU, not idea for real time audio apps.
8 May
8 May
2:15 p.m.
New subject: [linux-audio-dev] timesetevent alternative
Hi Lee,
Interesting.
But what's the exact behaviour in 2.6 kernels then ?
Does nanosleep() provide non-busywait usec precision using hires timers,
or does it simply do the same as usleep() ?
Eg providing only 1/HZ precison.
cheers,
Benno
http://www.linuxsampler.org
Lee Revell wrote:
Right,
nanosleep() might be a bit more precise than usleep() but for low sleep
values ( AFAIK < 2msec ) it
busywaits when you run your app SCHED_FIFO which in the case of
sustained streams of low sleep values
could chew up all the CPU, not idea for real time audio apps.
Not anymore. From man 2 nanosleep:
Old behaviour
In order to support applications requiring much more precise
pauses (e.g., in order to control some time-critical hardware),
nanosleep would handle pauses of up
to 2 ms by busy waiting with microsecond precision when called
from a process scheduled under a real-time policy like SCHED_FIFO or
SCHED_RR. This special
extension was removed in kernel 2.5.39, hence is still present in
current 2.4 kernels, but not in 2.6 kernels.
Lee
6 May
6 May
7:38 p.m.
New subject: [linux-audio-dev] timesetevent alternative
On 5/3/05, Garett Shulman <shulmang(a)colorado.edu> wrote:
Hello, About 5 years ago I hacked together a nice midi
looper app. The
only problem is that it was for Windows. Anyway... I'm working towards
reimplamenting the app in linux. Basically, I have a circular linked
list of midi events. Each node has the event and the time to the next
event. In Windows there was a timeSetEvent function. I pass this
function the time_to_next_event,
function_to_call_after_time_to_next_event, and
data_to_pass_to_function. The function_to_call_after_time_to_next_event
just outputs the event and then calls timeSetEvent with the next nodes
data. I'm curious as to how others would implament something similar in
linux. Perhaps as a thread with sleep call? Is there a high resolution
sleep function? Any ideas? Thanks. -Garett
Are you using the ALSA sequencer API? If so, I believe it handles
timing for you. Each event contains a timestamp, so I assume that
when you send an event, the sequencer core dispatches it at the proper
time. I never tried it though; my apps only receive events. If
you're not using ALSA, may I ask why?
Can anybody confirm my understanding of the sequencer API?
3 May
3 May
11:03 a.m.
The problem is that I don't know of any software
synthesizer that is:
1. good enough for decent music production;
2. easy to use by non-experts (this is a direct stab at CSound, or
better at its lack of a decent GUI, of a standard instrument exchange
file format and of a decent, centalized library of presets)
3. free software.
have you checked out supercollider? its somewhat dubious on point 2 I guess.
dave
2:57 p.m.
Hallo,
Sorry, I can't resist:
Toby hat gesagt: // Toby wrote:
My sequencer is going to be just that: a sequencer.
That's actually quite a curious sentence! People have very different
conceptions about what a sequencer is or what it should be.
Dave Griffiths' performance at LAC2005 is just one of the more extreme
examples how a sequencer can look like, if it's not Cubase. Pd's data
structures are another experimental approach as is Orm Finnendahl's
usage of XFig as a sequencer environment presented at last year's LAC.
Ciao
--
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
3:48 p.m.
On Tue, May 03, 2005 at 06:57:43PM +0200, Frank Barknecht wrote:
As I work on the design of a hardware sequencer, I developed
the following definition:
A sequencer is a device for recording and playback of signals
with the possibility to arrange several recordings.
Recording can happen in realtime, step-wise or alternatively
happen through programming.
The Signal can be audio or control data.
To arrange refers to repeating, putting into sequence
and layering of recordings.
(A propably a bit rough translation from german)
---
Thorsten Wilms
My sequencer
is going to be just that: a sequencer.
That's actually quite a curious sentence! People have very different
conceptions about what a sequencer is or what it should be.
8:59 p.m.
Hallo,
Thorsten Wilms hat gesagt: // Thorsten Wilms wrote:
On Tue, May 03, 2005 at 06:57:43PM +0200, Frank
Barknecht wrote:
One important feature still missing might be the "edit operation".
People use "sequencers" a lot to edit "stuff" (for a lack of a better
term) as well, where "editing" is a bit more complicated than just
"recording". Editing also includes changing already recorded events in
various ways. This could just mean "copy and paste", but more
interesting is the "modify" operation, that is, use various ways to
change the event sections at hand to create new "stuff" (like the
genetic "breeding" Dave is applying to the sequences.)
Ah, all this can get very complicated. The approach taken by Pd or
similar software is to give users tools to easily create their own
"sequencers", whatever these look like. But even traditional
sequencers offer modify operations like for example time or scale
quantization, which actually - if you think about it - is not a
trivial modification at all.
Ciao
--
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
That's actually quite a curious sentence!
People have very different
conceptions about what a sequencer is or what it should be.
As I work on the design of a hardware sequencer, I developed
the following definition:
A sequencer is a device for recording and playback of signals
with the possibility to arrange several recordings.
4 May
4 May
4:54 a.m.
On Wed, May 04, 2005 at 12:59:40AM +0200, Frank Barknecht wrote:
Dang! Thanks. I do it all the time and still managed to let
it slip out of my definition (now added) :)
---
Thorsten Wilms
A sequencer is
a device for recording and playback of signals
with the possibility to arrange several recordings.
One important feature still missing might be the "edit operation".
... 
6 May
6 May
9:15 p.m.
Frank Barknecht <fbar(a)footils.org> writes:
One important feature still missing might be the
"edit operation".
Editing is not part of the sequencer; it's the job of the relevant
editor (data context). I won't say this is just my opinion, cause a
sequencer is not an editor.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
7 May
7 May
9:02 a.m.
Editing is not part of the sequencer; it's the job
of the relevant
editor (data context). I won't say this is just my opinion, cause a
sequencer is not an editor.
If the sequencer and the editor(s) are separate (and, say, communicate
via OSC) it makes it easy for people to use the editor of their choice
(piano-roll, tracker, etc). I also imagine writing things like
search-and-replace functionality, and algorithmic composition tools,
as separate editors in their own right.
10 May
10 May
8:27 p.m.
James McDermott <jamesmichaelmcdermott(a)gmail.com> writes:
If the sequencer and the editor(s) are separate (and,
say,
communicate via OSC) it makes it easy for people to use the editor
of their choice (piano-roll, tracker, etc).
Exactly;). Don't forget drum editor and portamento editor. But it's
more than this. We have to be able to export the model data so that we
can have a daemon running and have clients connect to it and work on
the same session.
I also imagine writing things like search-and-replace
functionality,
and algorithmic composition tools, as separate editors in their own
right.
Elaborate.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
11 May
11 May
9:59 a.m.
Esben Stien wrote:
Um, was that an adjective or an imperative?!
You can read some of my thoughts on this at
http://www.skynet.ie/~jmmcd/zz.html. Ignore the parts about plugins,
though, because they're redundant. The original plan was for a plugin
host/sequencer, with separate ui/editor modules, communicating via
OSC. But my programming skills and free time are limited, so
a) it makes sense to hand the plugin host job off to a separate
program, eg to Om (http://savannah.nongnu.org/projects/om-synth),
which can be driven by OSC, and
b) maybe it makes sense to simply alter an existing sequencer to run
as daemon + editor modules (which communicate via OSC). Did I read
somewhere that Rosegarden is already like this? If so, how easy would
it be to write (eg) a stripped-down, hotkey-driven tracker editor
which communicated with the Rosegarden core?
While we're on the subject, what are the prospects for turning an
existing MIDI sequencer into an OSC sequencer (which could then take
full advantage of a plugin host like Om)?
We have to be able to export the model data so that
we
can have a daemon running and have clients connect to it and work on
the same session.
Yes, that's the way I've been thinking of it too.
I also imagine
writing things like search-and-replace functionality,
and algorithmic composition tools, as separate editors in their own
right.
Elaborate.
12 May
12 May
4:22 p.m.
James McDermott <jamesmichaelmcdermott(a)gmail.com> writes:
Yes, reading it now. I'll reply when it's read.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
7 May
7 May
10:06 a.m.
On Sat, 2005-05-07 at 01:12 +0200, Esben Stien wrote:
Frank Barknecht <fbar(a)footils.org> writes:
What about recording? That's not really any different from "realtime
editing".
--
Lars Luthman
PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
One important feature still missing might be the
"edit operation".
Editing is not part of the sequencer; it's the job of the relevant
editor (data context). I won't say this is just my opinion, cause a
sequencer is not an editor.
8 May
8 May
1:53 p.m.
Hallo,
Esben Stien hat gesagt: // Esben Stien wrote:
Frank Barknecht <fbar(a)footils.org> writes:
As I wrote in my very first mail in this thread: People think of very
different things when they hear the word "sequencer". If MusE is a
typical sequencer, then sequencers contain an editor. If a sequencer
is a device as in ALSA or OSS, then they don't contain an editor. Is a
midi file player a sequencer? Is changing the tempo and transposing
editing or sequencing?
Ciao
--
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
One important feature still missing might be the
"edit operation".
Editing is not part of the sequencer; it's the job of the relevant
editor (data context). I won't say this is just my opinion, cause a
sequencer is not an editor.
10 May
10 May
8:33 p.m.
Frank Barknecht <fbar(a)footils.org> writes:
People think of very different things when they hear
the word
"sequencer".
Yes, they do, but it doesn't change the fact of what a sequencer is.
If MusE is a typical sequencer, then sequencers
contain an editor.
It's more than a sequencer.
If a sequencer is a device as in ALSA or OSS, then
they don't
contain an editor.
That's more like what a sequencer does.
Is a midi file player a sequencer?
If it sequence midi, then it's a midi sequencer.
Is changing the tempo and transposing editing or
sequencing?
Well, you control the sequencer with your interface.
I'm not trying to be difficult, but I'd rather have a powerful
sequencer daemon and then look for a nice model view editor.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
9:24 p.m.
Esben Stien <b0ef(a)esben-stien.name> writes:
If it sequence midi, then it's a midi sequencer.
If it does more than that, it's a midi sequencer and then some.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
6947
days inactive
6957
days old
linux-audio-dev@lists.linuxaudio.org
43 comments
20 participants
participants (20)
-
Alfons Adriaensen -
Benno Senoner -
Dave Phillips -
Dave Robillard -
dave＠pawfal.org -
Esben Stien -
Frank Barknecht -
Garett Shulman -
ix＠replic.net -
James McDermott -
Jens M Andreasen -
Lars Luthman -
Lee Revell -
michael tewner -
Paul Coccoli -
Paul Davis -
Paul Winkler -
Steve Harris -
Thorsten Wilms -
Toby