Yahoo Tuning Groups Ultimate Backup makemicromusic The MMM Notation Editor/Sequencer: Recap/Update

Hey everyone,

Being as the other thread has slowly drifted away from the discussion
of software development and headed toward a discussion of different
compositional methods and preferences, I thought I'd make this one to
reignite that original discussion and sum up where we are so far. It
does seem that a lot of people would be interested in contributing to
such a project like this, which is exciting. Although there were a lot
of different ideas thrown around, I think that the main consensus was:

We need an interactive, microtonal staff GUI that can be played back
in real time.

This GUI should have a variety of features, including but not limited
to the following:
- Being cross-platform
- Having support for multiple notation systems (Sagittal, Decimal,
Sims-Maneri, etc.)
- Outputting via MIDI and MTS
- Should somehow integrate with Scala files

This naturally requires that the score editor has some kind of
sequencer component to it to allow for playback, as well as some kind
of GUI for the staff notation. From what I think we all decided, that
it plays back correctly and is graphically usable is a higher priority
than it looking good for printing: more of a linear scrolling
Sonar/Cakewalk "Staff View" than a Sibelius "Score Editor", at least
at first.

Secondary objectives that extend this core idea would be things like
the following:
1) A Piano Roll alpha blending overlay on top of the notation
2) Enabling integration with CSound and OSC
3) Enabling integration with VST synths and such
4) Integrating an audio sequencer into the fray
5) Throwing in pitch bend/channel swapping for backwards compatibility
with older synths
6) Expanding the idea or creating a full score-editing suite a la
Finale or Sibelius

But those should be tackled only after we get the first part going.

So far as I can remember, I think these are the main pathways forward
that we have found so far:

1) Canorus, as Graham pointed out, is a cross-platform score editor.
It builds off of an older KDE score-editor called NoteEdit, and the
developers of Lilypond and MusicABC are involved. We could either
lobby for microtonal features from them, and at some point fork off
from them. (http://canorus.berlios.de/)

2) Rosegarden is a very powerful DAW that has score editing, a piano
roll, and audio integration already done - but it's Linux only. Talk
of porting the GUI to Qt4, a cross-platform GUI, has been thrown
around on the Rosegarden-devel list for years, and they seem to be
very, very slowly moving forward with that objective. The main
hindrance with the porting, from what I gather, has nothing to do with
GUI, but rather that all of the audio stuff is hardcoded to work with
Linux's ALSA/JACK drivers, which we don't need to worry about to get a
score editor... for now. (http://www.rosegardenmusic.com/)

3) MusicKit, which looks very promising, is a non-GPL but free
library/API to use, which apparently does almost anything. I haven't
done as much research into this one as I have the other ones, but it
does seem very, very interesting, and might make it very easy to
proceed. (http://musickit.sourceforge.net/)

4) TSE3 is a GUI-less MIDI and audio sequencer library. We can build a
notation GUI straight on top of this. (http://tse3.sourceforge.net/)

5) Jazz++ is a cross platform MIDI and audio editor that Hans Straub
pointed out some time ago. It is currently being ported to wxwidgets.
From what I can tell from the Google images results for "Jazz++", it
has a piano roll, a "Harmony Generator" which might be useful to turn
into some kind of a lambdoma, but no staff editor. It does look a
little rough around the edges, and its website isn't all that helpful.
(http://jazzplusplus.sourceforge.net/)

6) ABC/MicroABC, Lilypond, etc. could possibly be modified to be
interactive, or have a front end created around them. Rosegarden, to
some extent, extends Lilypond in such a way. If people like the way
Lilypond looks, it might be nice to take its graphic library, modify
it, and integrate it with TSE3, or something like that. This one might
not even prove feasible in the end, but it was discussed in the
thread.

I think those were the ones talked about, although if I've forgotten
any please let me know. Some of these approaches are easier than
others - it may very well be easier to fork from Canorus than to make
a front end for Lilypond or port Rosegarden, for example.

And at least for now, the discussion on what language we should
program in and whether we should use .NET or some kind of managed code
should be put on hold for a bit until we get the main bits like this
sorted out. As the issue is already slightly raised by virtue of the
notion that we should fork off of existing projects, I will say that
this project, if people are willing to contribute to it, will go a lot
faster and much more smoothly if we are open to forking off from
existing projects that are in a huge range of languages. There are
people on the list that prefer Python, there are people that prefer
C++, and we even had a discussion about C# as a middle ground... So to
be blunt, people will have to be willing to work in C++, just as I
will have to be willing to work in Python, if we want to maximize our
range of options and get the best possible result.

Note also that some of these options would give us the secondary
objectives right away: Rosegarden, if we do manage to port it, will
give us audio and VST integration right off the bat. And Canorus aims
to be a score editor, so we'd have that secondary objective
accomplished. I do think that we will need to eventually fork off from
the Canorus route though, as even if they do implement some kind of
microtonal features in their software, new ideas seem to come out of
tuning and MMM at a fairly rapid rate. Unless Canorus latches onto the
microtonal community's wants and needs, which are considerably more
difficult to implement than what would be expected by a normal score
editor, I see us having a project designed mainly by and for us, a la
Scala.

-Mike

🔗Jon Szanto <jszanto@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

Mike wrote:

>We need an interactive, microtonal staff GUI that can be played back
>in real time.

Thank you.

>This naturally requires that the score editor has some kind of
>sequencer component to it to allow for playback,

I think we disagree on how much sequencer functionality is
desired, but anyway...

>2) Enabling integration with CSound and OSC

I'm strongly in favor of MIDI and OSC. I don't really get the
csound part. You want to output csound score files or something?

>3) Enabling integration with VST synths and such

MIDI'll do that.

>4) Integrating an audio sequencer into the fray

As already stated, I don't agree with this goal.

>5) Throwing in pitch bend/channel swapping for backwards compatibility
>with older synths

That'd be good.

>6) Expanding the idea or creating a full score-editing suite a la
>Finale or Sibelius

I'm definitely interested in the latter.

>But those should be tackled only after we get the first part going.

I'd like to do a generalized score editor from start to finish.

>1) Canorus, as Graham pointed out, is a cross-platform score editor.
>It builds off of an older KDE score-editor called NoteEdit, and the
>developers of Lilypond and MusicABC are involved. We could either
>lobby for microtonal features from them, and at some point fork off
>from them. (http://canorus.berlios.de/)

From the screenshot it's obvious it isn't a suitable basis for
what I'm interested in.

>3) MusicKit, which looks very promising, is a non-GPL but free
>library/API to use, which apparently does almost anything.

Ooh, I love that kind of library! ;)

>4) TSE3 is a GUI-less MIDI and audio sequencer library. We can build a
>notation GUI straight on top of this. (http://tse3.sourceforge.net/)

That's worth looking at.

>5) Jazz++ is a cross platform MIDI and audio editor that Hans Straub
>pointed out some time ago. It is currently being ported to wxwidgets.
>From what I can tell from the Google images results for "Jazz++", it
>has a piano roll, a "Harmony Generator" which might be useful to turn
>into some kind of a lambdoma, but no staff editor. It does look a
>little rough around the edges, and its website isn't all that helpful.
>(http://jazzplusplus.sourceforge.net/)

Good it's being ported to wxwidgets. However, this app is as old
as the hills and doesn't seem to overlap my needs much.

-Carl

🔗Mike Battaglia <battaglia01@...>

> I think we disagree on how much sequencer functionality is
> desired, but anyway...

Well, my desire for this project is to make it so that you can play back and
hear what you're doing, so as to enable some kind of feedback on what
different microtonal things sound like. Having just the score editor in
which you can move notes around but not hear what they sound like won't help
me really. So if the score can play back what it has, that is a sequencer.

>>2) Enabling integration with CSound and OSC
>
> I'm strongly in favor of MIDI and OSC. I don't really get the
> csound part. You want to output csound score files or something?

I mean that the root of the program should be the notation/sequencer and
work with MIDI. Being as people love Csound, it might be nice to make it so
they can use their Csound instruments as an output. There's a Csound VST
wrapper, I think, which means that this would be tackled with the
implementation of VST's. But I'm mainly saying that these things should be
secondary objectives to be tackled once we get the MIDI core down.

As for OSC, I think it would be good if we started with MIDI to get things
rolling, and once we get that part of the program down, we'll add OSC
support and stuff.

>>3) Enabling integration with VST synths and such
>
> MIDI'll do that.

I suppose it will. I don't know much about the VST spec, but I thought it
might be apt to get that part set up after we get just basic MIDI stuff
functioning.

>>4) Integrating an audio sequencer into the fray
>
> As already stated, I don't agree with this goal.

Well, it's a lofty goal. I would like to leave it open to be implemented in
the future if there is the time and interest for it. That's why I put it
down as a secondary objective - a possible extension.

In other words, I don't want to hardcode AGAINST having audio sequencing if
possible - else in the future, when that bridge is crossed, it'll be a
nightmare to implement.

>>6) Expanding the idea or creating a full score-editing suite a la
>>Finale or Sibelius
>
> I'm definitely interested in the latter.
>
>>But those should be tackled only after we get the first part going.
>
> I'd like to do a generalized score editor from start to finish.

I thought you were saying that your main goal was to have a linear scrolling
timeline kind of thing, not an actual score editor?

>>1) Canorus, as Graham pointed out, is a cross-platform score editor.
>>It builds off of an older KDE score-editor called NoteEdit, and the
>>developers of Lilypond and MusicABC are involved. We could either
>>lobby for microtonal features from them, and at some point fork off
>>from them. (http://canorus.berlios.de/)
>
> From the screenshot it's obvious it isn't a suitable basis for
> what I'm interested in.

Why?

>>3) MusicKit, which looks very promising, is a non-GPL but free
>>library/API to use, which apparently does almost anything.
>
> Ooh, I love that kind of library! ;)

Haha... Indeed. Which further opens the question on whether this should be
open-source...?

>>4) TSE3 is a GUI-less MIDI and audio sequencer library. We can build a
>>notation GUI straight on top of this. (http://tse3.sourceforge.net/)
>
> That's worth looking at.
>
>>5) Jazz++ is a cross platform MIDI and audio editor that Hans Straub
>>pointed out some time ago. It is currently being ported to wxwidgets.
> >From what I can tell from the Google images results for "Jazz++", it
>>has a piano roll, a "Harmony Generator" which might be useful to turn
>>into some kind of a lambdoma, but no staff editor. It does look a
>>little rough around the edges, and its website isn't all that helpful.
>>(http://jazzplusplus.sourceforge.net/)
>
> Good it's being ported to wxwidgets. However, this app is as old
> as the hills and doesn't seem to overlap my needs much.

I didn't like it too much either, but it might be a useful starting point.
Hans Straub was interested in it.

[Non-text portions of this message have been removed]

🔗Steve Morris <barbershopsteve@...>

Mike,

Nice breakdown. Before discussing branching off it might be worth more
thought about patitioning the problem better so that significant parts
of the work can be based existing projects without branching. For
example it might be good to standardize on an extensible text notation
(or API) system that multiple score editors could sit on top of. A
clear boundary layer for generating sound would make it easier to port
to different audio platforms. The key split is for score
representation levels to be ignorant of sound production details and
vice versa. This sounds simple and obvious but of the almost hundreds
of audio/music software tools out there each seems to partition in a
different way.

My own gut feel is that we want several API layers each with a one to
one text representation that can be used independently. Lower layers
should focus more on generality and portability. I'm sort of thinking
about something like the iso network stack. That model is tremendously
powerful because it makes clear just which layer you want to replace
to splice in a new platform(bottom) or application (top.)

It is all well and good to say we want to branch off and do our own
thing but the investment required is tremendous. What we really want
to do is mostly use someone elses well supported packages where we can
and branch off only where our needs are truly unique so our limited
resources can be spent on our unique needs.

I think your list is an excellent place to start. The next step is to
try and fit it into a layer strategy. I think if this is done cleverly
you will discover more existing stuff can be used and less new stuff
will be required than you imagine which is a good things because then
it might happen.

This is not a good group for most of the discussion because the
required skill set for much of it is software engineering. This list
represents the end users, composers, performers etc. Their large egos
will guarantee strong opinions about everything (it is not a shy or
particularly modest crowd) but should be trusted mostly for defining
"user" requirements. There is a subset here that can contribute a lot
to the software engineering discussion but an alternate list should be
considered to babysit development issues. Just look at the thread you
are replacing. It is a long winded thread full of interesting,
strongly stated but mostly irrelevant posts by posters who lost track
of the purpose of the thread. A yahoo group devoted to the creation of
a micro tuning tool chain would be easier to keep focused. I suggest
you start one, or if you like I will start one for you since I have
done it before.

On Mon, Jul 7, 2008 at 4:03 PM, Mike Battaglia <battaglia01@...> wrote:
> Hey everyone,
>
> Being as the other thread has slowly drifted away from the discussion
> of software development and headed toward a discussion of different
> compositional methods and preferences, I thought I'd make this one to
> reignite that original discussion and sum up where we are so far. It
> does seem that a lot of people would be interested in contributing to
> such a project like this, which is exciting. Although there were a lot
> of different ideas thrown around, I think that the main consensus was:
>
> We need an interactive, microtonal staff GUI that can be played back
> in real time.
>
> This GUI should have a variety of features, including but not limited
> to the following:
> - Being cross-platform
> - Having support for multiple notation systems (Sagittal, Decimal,
> Sims-Maneri, etc.)
> - Outputting via MIDI and MTS
> - Should somehow integrate with Scala files
>
> This naturally requires that the score editor has some kind of
> sequencer component to it to allow for playback, as well as some kind
> of GUI for the staff notation. From what I think we all decided, that
> it plays back correctly and is graphically usable is a higher priority
> than it looking good for printing: more of a linear scrolling
> Sonar/Cakewalk "Staff View" than a Sibelius "Score Editor", at least
> at first.
>
> Secondary objectives that extend this core idea would be things like
> the following:
> 1) A Piano Roll alpha blending overlay on top of the notation
> 2) Enabling integration with CSound and OSC
> 3) Enabling integration with VST synths and such
> 4) Integrating an audio sequencer into the fray
> 5) Throwing in pitch bend/channel swapping for backwards compatibility
> with older synths
> 6) Expanding the idea or creating a full score-editing suite a la
> Finale or Sibelius
>
> But those should be tackled only after we get the first part going.
>
> So far as I can remember, I think these are the main pathways forward
> that we have found so far:
>
> 1) Canorus, as Graham pointed out, is a cross-platform score editor.
> It builds off of an older KDE score-editor called NoteEdit, and the
> developers of Lilypond and MusicABC are involved. We could either
> lobby for microtonal features from them, and at some point fork off
> from them. (http://canorus.berlios.de/)
>
> 2) Rosegarden is a very powerful DAW that has score editing, a piano
> roll, and audio integration already done - but it's Linux only. Talk
> of porting the GUI to Qt4, a cross-platform GUI, has been thrown
> around on the Rosegarden-devel list for years, and they seem to be
> very, very slowly moving forward with that objective. The main
> hindrance with the porting, from what I gather, has nothing to do with
> GUI, but rather that all of the audio stuff is hardcoded to work with
> Linux's ALSA/JACK drivers, which we don't need to worry about to get a
> score editor... for now. (http://www.rosegardenmusic.com/)
>
> 3) MusicKit, which looks very promising, is a non-GPL but free
> library/API to use, which apparently does almost anything. I haven't
> done as much research into this one as I have the other ones, but it
> does seem very, very interesting, and might make it very easy to
> proceed. (http://musickit.sourceforge.net/)
>
> 4) TSE3 is a GUI-less MIDI and audio sequencer library. We can build a
> notation GUI straight on top of this. (http://tse3.sourceforge.net/)
>
> 5) Jazz++ is a cross platform MIDI and audio editor that Hans Straub
> pointed out some time ago. It is currently being ported to wxwidgets.
> From what I can tell from the Google images results for "Jazz++", it
> has a piano roll, a "Harmony Generator" which might be useful to turn
> into some kind of a lambdoma, but no staff editor. It does look a
> little rough around the edges, and its website isn't all that helpful.
> (http://jazzplusplus.sourceforge.net/)
>
> 6) ABC/MicroABC, Lilypond, etc. could possibly be modified to be
> interactive, or have a front end created around them. Rosegarden, to
> some extent, extends Lilypond in such a way. If people like the way
> Lilypond looks, it might be nice to take its graphic library, modify
> it, and integrate it with TSE3, or something like that. This one might
> not even prove feasible in the end, but it was discussed in the
> thread.
>
> I think those were the ones talked about, although if I've forgotten
> any please let me know. Some of these approaches are easier than
> others - it may very well be easier to fork from Canorus than to make
> a front end for Lilypond or port Rosegarden, for example.
>
> And at least for now, the discussion on what language we should
> program in and whether we should use .NET or some kind of managed code
> should be put on hold for a bit until we get the main bits like this
> sorted out. As the issue is already slightly raised by virtue of the
> notion that we should fork off of existing projects, I will say that
> this project, if people are willing to contribute to it, will go a lot
> faster and much more smoothly if we are open to forking off from
> existing projects that are in a huge range of languages. There are
> people on the list that prefer Python, there are people that prefer
> C++, and we even had a discussion about C# as a middle ground... So to
> be blunt, people will have to be willing to work in C++, just as I
> will have to be willing to work in Python, if we want to maximize our
> range of options and get the best possible result.
>
> Note also that some of these options would give us the secondary
> objectives right away: Rosegarden, if we do manage to port it, will
> give us audio and VST integration right off the bat. And Canorus aims
> to be a score editor, so we'd have that secondary objective
> accomplished. I do think that we will need to eventually fork off from
> the Canorus route though, as even if they do implement some kind of
> microtonal features in their software, new ideas seem to come out of
> tuning and MMM at a fairly rapid rate. Unless Canorus latches onto the
> microtonal community's wants and needs, which are considerably more
> difficult to implement than what would be expected by a normal score
> editor, I see us having a project designed mainly by and for us, a la
> Scala.
>
> -Mike
>
>

--
Steve Morris
barbershopsteve@...
Bass: Boston Wailers
Bass: Sounds Of Concord
Motto: Old age and treachery will always prevail over youth and skill

🔗Jon Szanto <jszanto@...>

🔗Carl Lumma <carl@...>

At 02:24 PM 7/7/2008, Mike wrote:

>> I think we disagree on how much sequencer functionality is
>> desired, but anyway...
>
>Well, my desire for this project is to make it so that you can play back
>and hear what you're doing, so as to enable some kind of feedback on what
>different microtonal things sound like. Having just the score editor in
>which you can move notes around but not hear what they sound like

But that's just the point. The notes are objects that can be
inspected on the score. That means they can be heard directly
from the score. Individually, as selected groups, or sequential
playback between two carets.

Usually these days "sequencer" means some sort of PCM audio
support, which I don't think a score editor needs and which
I think will bog down the project.
It also usually means some sort of track view where different
tracks can be arranged, and the same goes for that.

>>>2) Enabling integration with CSound and OSC
>>
>> I'm strongly in favor of MIDI and OSC. I don't really get the
>> csound part. You want to output csound score files or something?
>
>I mean that the root of the program should be the notation/sequencer and
>work with MIDI. Being as people love Csound,

How many people we talkin'?

>it might be nice to make it so
>they can use their Csound instruments as an output.

That can be done with MIDI.

>As for OSC, I think it would be good if we started with MIDI to get things
>rolling, and once we get that part of the program down, we'll add OSC
>support and stuff.

OSC should arguably come first, since it doesn't constrain the
design. Then the best-fit MIDI implementation will be more clear.

>>>3) Enabling integration with VST synths and such
>>
>> MIDI'll do that.
>
>I suppose it will. I don't know much about the VST spec, but I thought it
>might be apt to get that part set up after we get just basic MIDI stuff
>functioning.

First of all, I think you mean VSTi, as plain VST is effects only,
as the data sent to plain VST components is I think audio only.
With VSTi, I think the data simply includes MIDI, but I could be
completely wrong.

>>>4) Integrating an audio sequencer into the fray
>>
>> As already stated, I don't agree with this goal.
>
>Well, it's a lofty goal.

Lofty = deleterious in software.

>In other words, I don't want to hardcode AGAINST having audio sequencing
>if possible - else in the future, when that bridge is crossed, it'll be
>a nightmare to implement.

Why not make a separate app for audio? And audio sequencers
are already tuning-agnostic. So what functionality, exactly, are
you after?

>>>6) Expanding the idea or creating a full score-editing suite a la
>>>Finale or Sibelius
>>
>> I'm definitely interested in the latter.
>>
>>>But those should be tackled only after we get the first part going.
>>
>> I'd like to do a generalized score editor from start to finish.
>
>I thought you were saying that your main goal was to have a linear scrolling
>timeline kind of thing, not an actual score editor?

Fullblown score editor. Just without some sort of 15th-century
obsession with printing at the core of the architecture.

-Carl

🔗Steve Morris <barbershopsteve@...>

🔗Jon Szanto <jszanto@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

In regards to the discussion about setting up another list for this
project: That's generally what I had planned as well. I wanted to have
this first thread on MMM just to see what the group at large thought
about it and to see who might be interested, and then once we had an
actual starting point, I was going to move it to a sourceforge list or
another yahoo list... But Jon, if you want us to move it now, then we
can.

On Mon, Jul 7, 2008 at 5:32 PM, Steve Morris <barbershopsteve@...> wrote:
>
> Mike,
>
> Nice breakdown. Before discussing branching off it might be worth more
> thought about patitioning the problem better so that significant parts
> of the work can be based existing projects without branching. For
> example it might be good to standardize on an extensible text notation
> (or API) system that multiple score editors could sit on top of. A
> clear boundary layer for generating sound would make it easier to port
> to different audio platforms. The key split is for score
> representation levels to be ignorant of sound production details and
> vice versa. This sounds simple and obvious but of the almost hundreds
> of audio/music software tools out there each seems to partition in a
> different way.

I'm not sure what you mean here... We weren't going to have an actual
sound generator as part of the design. We were going to simply have it
output MIDI and perhaps OSC later.

If you're talking about having a DAW-ish event list, from which you
can then interpret with different views - i.e. a staff view, a piano
roll view, etc... I'm all for that. I think that is actually the route
we should take, as it would be more expandable later on.

> My own gut feel is that we want several API layers each with a one to
> one text representation that can be used independently. Lower layers
> should focus more on generality and portability. I'm sort of thinking
> about something like the iso network stack. That model is tremendously
> powerful because it makes clear just which layer you want to replace
> to splice in a new platform(bottom) or application (top.)

I'm not sure if we're talking about the same thing, but one model I
had floating around was something like this:

Layer 3: Different GUI's that take the event list and display the
information in different ways - Staff, Piano Roll, etc.
Layer 2: Event list. Stores note information as well as anything else we want.
Layer 1: MIDI/Sequencer API's

> It is all well and good to say we want to branch off and do our own
> thing but the investment required is tremendous. What we really want
> to do is mostly use someone elses well supported packages where we can
> and branch off only where our needs are truly unique so our limited
> resources can be spent on our unique needs.

Agreed. I think we should start with something like MusicKit, or
perhaps Canorus... I have to investigate deeply into both of those
though.

> I think your list is an excellent place to start. The next step is to
> try and fit it into a layer strategy. I think if this is done cleverly
> you will discover more existing stuff can be used and less new stuff
> will be required than you imagine which is a good things because then
> it might happen.

Hopefully! I like the paradigm you have of large-scale software
development. That was the original idea I was floating around... We do
have quite a bit of disparate programs that

> This is not a good group for most of the discussion because the
> required skill set for much of it is software engineering. This list
> represents the end users, composers, performers etc. Their large egos
> will guarantee strong opinions about everything (it is not a shy or
> particularly modest crowd) but should be trusted mostly for defining
> "user" requirements. There is a subset here that can contribute a lot
> to the software engineering discussion but an alternate list should be
> considered to babysit development issues. Just look at the thread you
> are replacing. It is a long winded thread full of interesting,
> strongly stated but mostly irrelevant posts by posters who lost track
> of the purpose of the thread. A yahoo group devoted to the creation of
> a micro tuning tool chain would be easier to keep focused. I suggest
> you start one, or if you like I will start one for you since I have
> done it before.

I think we should... See above. Let's just leave this thread on for a
little bit just to see who on the list is interested in programming
and perhaps get some feedback from the end users, and then let's set
up a yahoo list. Or perhaps sourceforge...? If we use the Musickit
API, the end product doesn't necessarily have to be licensed under the
GPL.

I'll set up a group in a few. What should the name of the group be?
MicroSoft, perhaps? :P

-Mike

🔗Mike Battaglia <battaglia01@...>

On Mon, Jul 7, 2008 at 5:35 PM, Carl Lumma <carl@...> wrote:
>>Well, my desire for this project is to make it so that you can play back
>>and hear what you're doing, so as to enable some kind of feedback on what
>>different microtonal things sound like. Having just the score editor in
>>which you can move notes around but not hear what they sound like
>
> But that's just the point. The notes are objects that can be
> inspected on the score. That means they can be heard directly
> from the score. Individually, as selected groups, or sequential
> playback between two carets.

Then we won't be able to hear rhythms, or for that matter, anything in
realtime, which for my purposes is vital to the whole thing.

> Usually these days "sequencer" means some sort of PCM audio
> support, which I don't think a score editor needs and which
> I think will bog down the project.
> It also usually means some sort of track view where different
> tracks can be arranged, and the same goes for that.

I don't think we need to worry about PCM audio support right now, but
it is something that I would like to see in the future.

>>>>2) Enabling integration with CSound and OSC
>>>
>>> I'm strongly in favor of MIDI and OSC. I don't really get the
>>> csound part. You want to output csound score files or something?
>>
>>I mean that the root of the program should be the notation/sequencer and
>>work with MIDI. Being as people love Csound,
>
> How many people we talkin'?

Quite a few - go over the Composition Software thread again. A LOT of
people, actually.

>>it might be nice to make it so
>>they can use their Csound instruments as an output.
>
> That can be done with MIDI.
>
>>As for OSC, I think it would be good if we started with MIDI to get things
>>rolling, and once we get that part of the program down, we'll add OSC
>>support and stuff.
>
> OSC should arguably come first, since it doesn't constrain the
> design. Then the best-fit MIDI implementation will be more clear.

Interesting idea... I'm open to that.

> First of all, I think you mean VSTi, as plain VST is effects only,
> as the data sent to plain VST components is I think audio only.
> With VSTi, I think the data simply includes MIDI, but I could be
> completely wrong.

Yeah, I'm talking about Kontakt, Pianoteq, FM8, etc.

>>>>4) Integrating an audio sequencer into the fray
>>>
>>> As already stated, I don't agree with this goal.
>>
>>Well, it's a lofty goal.
>
> Lofty = deleterious in software.

I disagree. We're not focusing on audio right now anyway, and if we
pick a good enough abstraction model then implementing it will be
relatively straightforward anyway. The notation GUI is step one, and
the sequencer is step two, and everything else is step one hundred.

I think having an all around composition environment for microtonal
music is really the end goal here. It is always a good idea to make
software expandable for future development. There is no reason to put
ourselves into this box where we CAN'T have audio later.

>>In other words, I don't want to hardcode AGAINST having audio sequencing
>>if possible - else in the future, when that bridge is crossed, it'll be
>>a nightmare to implement.
>
> Why not make a separate app for audio? And audio sequencers
> are already tuning-agnostic. So what functionality, exactly, are
> you after?

Why make a separate app for audio? Audio isn't even the focus now.
Here's what I'm saying:

We pick an abstraction model in which there are "events" that are
"played" somehow. If these events are MIDI notes, then corresponding
note ons and offs are played via MIDI. If they are OSC events, then
they are played via OSC. This kind of model means that if we want to
incorporate audio, we simply come up with an audio "event" which would
be a pointer to some PCM data in memory and such. The important thing
is that we have some kind of a model to build on. Hell, we could throw
any kind of event we wanted to in there. Hell, we could put video in
if we wanted. And we don't have to do any of these things if we don't
want to, but we CAN if for some reason they seem appropriate.

How do we sync the audio and video the MIDI/OSC together? We'll worry
about it later, and if we play our cards right now it won't require
deleting and recoding so many large portions of the project later on
that we give up on it.

> Fullblown score editor. Just without some sort of 15th-century
> obsession with printing at the core of the architecture.
>
> -Carl

What do you mean?

-Mike

🔗Mike Battaglia <battaglia01@...>

> Many of us cannot hear directly from the score. Please don't pretend I
> don't exist. I have lots of company even though we get under counted
> because we are generally too embarrassed to admit it. I agree that we
> may be a minority in an elitist crowd like this but please don't
> exclude us up front. I need immediate interactive playback of what I
> have selected on the screen or it is useless to me as a compositional
> tool; I don't care how pretty the gui is.

Indeed. I think this should be one of the guiding principles behind
the project. I don't think that's exactly what Carl was saying, but
the principle is a good idea regardless.

Our tastes and desires will not necessarily reflect everyone's.
However, we should be able to implement different features if people
should ask for it. There should be no reason to deliberately EXCLUDE
features from future development. Chances are, if one of US wants a
certain feature, other people will as well. Arguing over what is
"necessary" is useless. Arguing over which ideas should be an
immediate priority and which ones should be implemented at a later
date is much less useless.

We should build the project in such a way that we can add features
easily, a la the model that Steve suggested. We should be able to have
a staff GUI, a piano roll GUI, a track view GUI, an event list GUI, a
synesthetic visualization GUI that makes you feel like you're tripping
on acid, and a GUI that takes incoming event list data and gives you
your lucky number. We don't have to necessarily implement all or any
of those GUI's, but we should be able to overlay them off of the
existing event list easily. We need to have neatly modularized code.

Carl wrote:
> No no, that's the point! Nobody on *earth* can hear from the
> kind of scores I want to support. When I say notes are objects,
> I mean they have a pitch property that you can inspect. That
> includes getting a cents value on the screen, but most importantly
> it includes making them play by clicking on them, or by using
> a shuttle control (like an old tape deck) to play through the
> score sequentially. Don't worry, you'll be able to do barbershop
> (where the scores are comparatively normal) with it too.

Playing through the score sequentially is what I meant when I said we
need a sequencer.

-Mike

🔗Carl Lumma <carl@...>

Mike wrote:
>> But that's just the point. The notes are objects that can be
>> inspected on the score. That means they can be heard directly
>> from the score. Individually, as selected groups, or sequential
>> playback between two carets.
>
>Then we won't be able to hear rhythms, or for that matter, anything in
>realtime, which for my purposes is vital to the whole thing.

What does "sequential playback between two carets" mean to you? :)

>>>>>2) Enabling integration with CSound and OSC
>>>>
>>>> I'm strongly in favor of MIDI and OSC. I don't really get the
>>>> csound part. You want to output csound score files or something?
>>>
>>>I mean that the root of the program should be the notation/sequencer
>>>and work with MIDI. Being as people love Csound,
>>
>> How many people we talkin'?
>
>Quite a few - go over the Composition Software thread again. A LOT of
>people, actually.

Prent uses it, but I didn't get the sense he's interested in a
score editor. Graham has used it, but says a score editor is
a waste of time. Hans may be interested. Steve was interested
in using it via Blue. Who did I miss?

>> First of all, I think you mean VSTi, as plain VST is effects only,
>> as the data sent to plain VST components is I think audio only.
>> With VSTi, I think the data simply includes MIDI, but I could be
>> completely wrong.
>
>Yeah, I'm talking about Kontakt, Pianoteq, FM8, etc.

As a funny coincidence, all of those synths have standalone modes
that can accept MIDI from a virtual MIDI port. Synths without a
standalone mode can be hosted in any VSTi host you like (I like
REAPER and Brainspawn Forte) and recieve our MIDI there, where it
can render to PCM and sequenced to your heart's delight.

>> Why not make a separate app for audio? And audio sequencers
>> are already tuning-agnostic. So what functionality, exactly, are
>> you after?
>
>Why make a separate app for audio? Audio isn't even the focus now.
>Here's what I'm saying:
>
>We pick an abstraction model in which there are "events" that are
>"played" somehow. If these events are MIDI notes, then corresponding
>note ons and offs are played via MIDI. If they are OSC events, then
>they are played via OSC. This kind of model means that if we want to
>incorporate audio, we simply come up with an audio "event" which would
>be a pointer to some PCM data in memory and such.

What functionality, exactly, are you after?

>> Fullblown score editor. Just without some sort of 15th-century
>> obsession with printing at the core of the architecture.
>
>What do you mean?

I already explained it but we can flesh it out more if we can get
on the same page with the basics (see above).

-Carl

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

> Obviously we have to have an events timeline internally. But
> you just finished posting about 'track view' GUIs and so forth,
> and both Graham and I (and I think even one other person) have
> already said why they should NOT be features of this software.
>
> -Carl

I also posted about a "lucky number" GUI. The point wasn't about what
GUI's we should or should not have, but that we should design it with
the ability to be expandable to any GUI that we might want in the
future.

I personally do think a track view would be useful. If you don't then
you don't. But if we design the program correctly, we'll be able to
overlay any GUI we wish on top of the internal events timeline, and
I'll be able to put in my track view, and you'll be able to put in
your alpha blend piano roll view, and everyone wins. And if we never
get to put the acid trip visualizer GUI in, then so be it.

But the way I see it, if I want a track view GUI, then other people
will want a track view GUI, so let's set it up so that later on the
process to implement a track view GUI is trivial.

As for Csound, a lot of people have demonstrated that they like
Csound's synth capabilities; that was the early discussion in the
Composition Software thread. If we're designing software that will
work with VSTi, then this also seems like a pointless discussion.

Here is my point: a lot of people have a lot of different preferences.
You have just taken this position in your discussion with AKJ in the
adjacent thread. So rather than us having to replay this argument over
and over about what's "necessary," as if one set of features should
satisfy everyone, we should just set it up to be expandable for
different things in the future, the end. I do see this project having
the capability of turning into a DAW a few years down the line, and I
don't want to rule that option out, so I want the code to be
modularized enough to work with that objective if that's where the
project goes.

I don't feel like getting hit with the straw man that "these are too
many features and will take too much time to implement and it will
never get done", so let's move past this particular part.

-Mike

🔗Carl Lumma <carl@...>

At 08:54 PM 7/7/2008, you wrote:
>> Obviously we have to have an events timeline internally. But
>> you just finished posting about 'track view' GUIs and so forth,
>> and both Graham and I (and I think even one other person) have
>> already said why they should NOT be features of this software.
>
>I also posted about a "lucky number" GUI. The point wasn't about what
>GUI's we should or should not have, but that we should design it with
>the ability to be expandable to any GUI that we might want in the
>future.
>
>I personally do think a track view would be useful. If you don't then
>you don't. But if we design the program correctly, we'll be able to
>overlay any GUI we wish on top of the internal events timeline, and
>I'll be able to put in my track view, and you'll be able to put in
>your alpha blend piano roll view, and everyone wins. And if we never
>get to put the acid trip visualizer GUI in, then so be it.
>
>But the way I see it, if I want a track view GUI, then other people
>will want a track view GUI, so let's set it up so that later on the
>process to implement a track view GUI is trivial.
>
>As for Csound, a lot of people have demonstrated that they like
>Csound's synth capabilities; that was the early discussion in the
>Composition Software thread. If we're designing software that will
>work with VSTi, then this also seems like a pointless discussion.
>
>Here is my point: a lot of people have a lot of different preferences.
>You have just taken this position in your discussion with AKJ in the
>adjacent thread. So rather than us having to replay this argument over
>and over about what's "necessary," as if one set of features should
>satisfy everyone, we should just set it up to be expandable for
>different things in the future, the end. I do see this project having
>the capability of turning into a DAW a few years down the line, and I
>don't want to rule that option out, so I want the code to be
>modularized enough to work with that objective if that's where the
>project goes.
>
>I don't feel like getting hit with the straw man that "these are too
>many features and will take too much time to implement and it will
>never get done", so let's move past this particular part.

The way I see it, software projects should be based on clear
functional specs that are within scope and budget. You're welcome
to do whatever you want. I promise not to gloat when your project
crumbles, and to bake you a pie if it succeeds. If you do want my
involvement, I would appreciate more direct replies to points made
in previous posts rather than waxing on about the same stuff message
after message in reply to single paragraphs of mine as you've done
here. And if you and Aaron are going to be picking from
J.P. McFeely's Big Book of Logical Fallacies, please take the time
to pick appropriate fallacies.

-Carl

🔗Mike Battaglia <battaglia01@...>

On Tue, Jul 8, 2008 at 12:28 AM, Carl Lumma <carl@...> wrote:
> The way I see it, software projects should be based on clear
> functional specs that are within scope and budget. You're welcome
> to do whatever you want. I promise not to gloat when your project
> crumbles, and to bake you a pie if it succeeds. If you do want my
> involvement, I would appreciate more direct replies to points made
> in previous posts rather than waxing on about the same stuff message
> after message in reply to single paragraphs of mine as you've done
> here. And if you and Aaron are going to be picking from
> J.P. McFeely's Big Book of Logical Fallacies, please take the time
> to pick appropriate fallacies.

What about the specs is unclear? I made a list of primary objectives
and secondary objectives to focus on later. There is no budget, and
the scope of the project is going to change over time.

I said "let's focus on having a microtonal staff GUI that we can play
back, and let's make it so we can add audio later on if we want." Then
you said "let's not make it so we can add audio later on if we want."
I said "let's make it so we can add a track view later on if we want."
Then you said "let's not add a track view," which to me means "let's
not make it so we can add a track view later one" or "let's not add a
track view later." So every time I say "let's make it so we can add
possibilities later," you say "let's not."

As for "not gloating 'when' my project crumbles and baking me a pie
'if' it succeeds," you are being excessively negative, as usual. It
would certainly be nice to have your involvement as it would to have
everyone's, and if you don't want to work on the audio side of it,
then when it gets time to throw the audio side of it in, don't work on
it. Why you are set on stopping future implementations of audio in the
project, I don't know.

A straw man fallacy would be the exact fallacy in question as well.

🔗Carl Lumma <carl@...>

🔗Graham Breed <gbreed@...>

🔗Mike Battaglia <battaglia01@...>

>>What about the specs is unclear?
>
> You shouldn't write a line of code until you have a complete
> paper model or wireframes + state machine for the entire app.

That's... the point. Wireframes and state machine... might be a bit
unnecessary here, haha. And the paper model we're going to draw up is
going to be the same thing as the abstraction model that I keep
talking about. And the abstraction model I am suggesting will be
expandable to include audio and track view and things that you
yourself may not necessarily want, as will it be able to include
things that I myself may not necessarily want, and we may never put
any of them in, but we will not be hogtied in the future if we have a
good idea.

>>I made a list of primary objectives
>>and secondary objectives to focus on later. There is no budget,
>
> There's always a budget!

My budget right now is something like four dollars and whatever I can
pirate on Bittorrent. Let's see how that goes.

>>and the scope of the project is going to change over time.
>
> D'oh.

Yis.

>>A straw man fallacy would be the exact fallacy in question as well.
>
> You have to demonstrate my argument is unrelated to yours for that
> to be true.

Person 1: Let's make an expandable, modularized abstraction model for
this project so that in the future, if we want to add audio and video
and track views, we can do it without rewriting a considerable portion
of the code base.
Person 2: Those features will take too much time to implement and will
bog down the project.

I'm not saying to implement all of those features NOW, hence, this
whole thing is an unnecessary straw man. I've said about a thousand
times that if we throw in a track view and audio and channel
swapping/pitch bending and all of these little bells and whistles,
we're going to do it much, much later on. And so I don't understand
how it could affect the progress of the score editor, since we're
focusing on the score editor first. Designing the code to be
expandable won't "bog down" the project. If anything, NOT designing
the code to be expandable would be what bogs down the project.

My focus is that we have to be sensitive to people's needs. And so
this project will be infinitely more useful if we make it, again,
EXPANDABLE. There is no need to take some particular way we can expand
it and then say "this will be too difficult to implement now, so let's
not make it expandable." That is a straw man argument.

My goal for this, my long-term goal, is to someday have a microtonal
composition suite. I want to be able to write orchestral microtonal
music, electronic microtonal music, etc. I have gotten very good at
composing in DAW environments, in the scoring environments, etc. I
find text-based environments hard to work on, and so I want to have
this notation GUI, as do you.

Some day, I'd also like to have a lot of things that you probably
don't care about, and you'd like to have a lot of things I probably
don't care about. I could say "let's ignore the alpha blending piano
roll, as it would bog down the project." But, as a way to make the
project even better, I'd rather say "let's make sure we modularize our
code successfully, and then you can make your piano roll, and I'll
make my track view, and the product will appeal to a wider audience."

The starting point for this all is the notation GUI, and a lot of
people are interested in that. Eventually, once that's done, I might
go on and add audio, and then there will be people who don't care
about that and don't participate, and new people who do. But I hope
you realize that hardcoding this in such a way that we are not
sensitive to the adding of potential features in the future completely
invalidates the usefulness of this project for me.

In other words: rather than argue about what features we'll add in the
future, let's make it easy to add whatever features we WANT in the
future, and deal with avoiding bloat later. In the meantime, let's
tackle the problem of the notation GUI now. One thing we need to
figure out is exactly what model we're going to use for this, as Jon
brought up earlier.

-Mike

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

Mike wrote:
>>>What about the specs is unclear?
>>
>> You shouldn't write a line of code until you have a complete
>> paper model or wireframes + state machine for the entire app.
>
>That's... the point. Wireframes and state machine... might be a bit
>unnecessary here, haha. And the paper model we're going to draw up is
>going to be the same thing as the abstraction model that I keep
>talking about.

Paper modeling is also for UI elements.

>And the abstraction model I am suggesting will be
>expandable to include audio and track view and things that you
>yourself may not necessarily want, as will it be able to include
>things that I myself may not necessarily want, and we may never put
>any of them in, but we will not be hogtied in the future if we have a
>good idea.

You keep ignoring my point. I have no problem putting it in
if: 1. you can describe what you want to do with it and 2. you
can demonstrate that it belongs in this app and isn't already
available in other apps like I've already shown it to be but
you keep ignoring those parts of my messages.

>>>I made a list of primary objectives
>>>and secondary objectives to focus on later. There is no budget,
>>
>> There's always a budget!
>
>My budget right now is something like four dollars and whatever I can
>pirate on Bittorrent. Let's see how that goes.

Software budgets are almost never gated by money. They're
gated by time and communication bandwidth/overhead.

>>>A straw man fallacy would be the exact fallacy in question as well.
>>
>> You have to demonstrate my argument is unrelated to yours for that
>> to be true.
>
>Person 1: Let's make an expandable, modularized abstraction model for
>this project so that in the future,

Now that's a straw man. I never said we wouldn't do the appropriate
abstraction. That may or may not include hooks for video snips or
whatever the $*%@ you're going on about, but until you've done the
two things above I won't even consider it.

By the way, my argument about people paying for Finale was indeed
fallacious but it was an appeal to popularity (or authority), not
a straw man. (Despite the fact that 'consider the source' reasoning
often fails spectacularly, it's difficult to resist because it often
is a useful heuristic.)

>My goal for this, my long-term goal, is to someday have a microtonal
>composition suite.

And why should we provide the glue instead of letting the OS
provide the glue?

>I want to be able to write orchestral microtonal
>music, electronic microtonal music, etc. I have gotten very good at
>composing in DAW environments,

OK, I'll ask again: Exactly what about these environments isn't
microtonal?

>Some day, I'd also like to have a lot of things that you probably
>don't care about, and you'd like to have a lot of things I probably
>don't care about. I could say "let's ignore the alpha blending piano
>roll, as it would bog down the project."

You could and you very well may hear me agree.

-Carl

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

On Tue, Jul 8, 2008 at 1:49 AM, Carl Lumma <carl@...> wrote:
> You keep ignoring my point. I have no problem putting it in
> if: 1. you can describe what you want to do with it and 2. you
> can demonstrate that it belongs in this app and isn't already
> available in other apps like I've already shown it to be but
> you keep ignoring those parts of my messages.

Jesus Christ. Why do those things BELONG in this project? Because
those tools are useful for microtonal composition. And as NOBODY CAN
AGREE on what features are "ideal" for a microtonal composition suite,
we will have to make it easy to add new views, such as a track view,
later, to accommodate the preferences of a lot of different people.

I want a track view to be there for mixing, routing, and editing, and
I want audio to be in there so that I can easily audio samples to my
compositions. I don't want to have to use separate programs as it
interferes with the flow of composition and defeats the purpose of the
whole thing. Is this really necessary?

> >Person 1: Let's make an expandable, modularized abstraction model for
> >this project so that in the future,
>
> Now that's a straw man. I never said we wouldn't do the appropriate
> abstraction. That may or may not include hooks for video snips or
> whatever the $*%@ you're going on about, but until you've done the
> two things above I won't even consider it.

Carl.

I said, let's make it so we can expand on the core idea in the future.
You said, doing the possible expansions now will take too much time.

Straw man. The end.

> By the way, my argument about people paying for Finale was indeed
> fallacious but it was an appeal to popularity (or authority), not
> a straw man. (Despite the fact that 'consider the source' reasoning
> often fails spectacularly, it's difficult to resist because it often
> is a useful heuristic.)

And you run the same routine over and over, with all kinds of word
games and twisted logic, and I'm not amused.

> And why should we provide the glue instead of letting the OS
> provide the glue?

It's easier to use.

> >I want to be able to write orchestral microtonal
> >music, electronic microtonal music, etc. I have gotten very good at
> >composing in DAW environments,
>
> OK, I'll ask again: Exactly what about these environments isn't
> microtonal?

Gee, everything? In order for me to compose in 72-tet, I have to use 6
detuned MIDI channels, unless I'm using specifically Kontakt, and then
I can buy Kontakt's scale editor.

> >Some day, I'd also like to have a lot of things that you probably
> >don't care about, and you'd like to have a lot of things I probably
> >don't care about. I could say "let's ignore the alpha blending piano
> >roll, as it would bog down the project."
>
> You could and you very well may hear me agree.

Pointless. Pointless arguing. I'm tired of pointless arguing. This is stupid.

-Mike

🔗Graham Breed <gbreed@...>

Message to MMM, copied to Carl's list.

Mike Battaglia wrote:
> Hey everyone,
> > Being as the other thread has slowly drifted away from the discussion
> of software development and headed toward a discussion of different
> compositional methods and preferences, I thought I'd make this one to
> reignite that original discussion and sum up where we are so far. It
> does seem that a lot of people would be interested in contributing to
> such a project like this, which is exciting. Although there were a lot
> of different ideas thrown around, I think that the main consensus was:
> > We need an interactive, microtonal staff GUI that can be played back
> in real time.

That sounds right. I drew a distinction between a sequencer and a score editor before. What it seems we want is a simple score editor with basic audio support (probably via MIDI). And the immediate goal is to explore new notations, not to produce the best printed scores or MIDI performances. The distant goal is for perfect score output and some fuzzy idea of a composition system.

> This GUI should have a variety of features, including but not limited
> to the following:
> - Being cross-platform
> - Having support for multiple notation systems (Sagittal, Decimal,
> Sims-Maneri, etc.)
> - Outputting via MIDI and MTS
> - Should somehow integrate with Scala files

Looks good.

> This naturally requires that the score editor has some kind of
> sequencer component to it to allow for playback, as well as some kind
> of GUI for the staff notation. From what I think we all decided, that
> it plays back correctly and is graphically usable is a higher priority
> than it looking good for printing: more of a linear scrolling
> Sonar/Cakewalk "Staff View" than a Sibelius "Score Editor", at least
> at first.

I say a score editor is the target. The internal representation of notes should reflect staff notation, not MIDI. It should also be as easy as possible to enter notes in the score view. We have to accept that it won't be as powerful as Sibelius at first. Unfortunately that means very few people will be interested in it but it's worth a try anyway.

> Secondary objectives that extend this core idea would be things like
> the following:
> 1) A Piano Roll alpha blending overlay on top of the notation

Maybe.

> 2) Enabling integration with CSound and OSC

No need unless it's a *primary* goal (which it obviously isn't).

> 3) Enabling integration with VST synths and such

No need.

> 4) Integrating an audio sequencer into the fray

No. Audio sequencers are different beasts to score editors. Things you need for audio can't naturally be represented in staff notation. A good quality performance depends on low-level MIDI editing. The details of MIDI can't be well represented in staff notation and vice-versa. We need to decide what we want from the outset -- a score editor that does MIDI or a sequencer with a score view.

> 5) Throwing in pitch bend/channel swapping for backwards compatibility
> with older synths

Yes.

> 6) Expanding the idea or creating a full score-editing suite a la
> Finale or Sibelius

There should always be room for expansion in that direction.

> But those should be tackled only after we get the first part going.
> > So far as I can remember, I think these are the main pathways forward
> that we have found so far:
> > 1) Canorus, as Graham pointed out, is a cross-platform score editor.
> It builds off of an older KDE score-editor called NoteEdit, and the
> developers of Lilypond and MusicABC are involved. We could either
> lobby for microtonal features from them, and at some point fork off
> from them. (http://canorus.berlios.de/)

It looks good. I suggest we contact the development team ASAP.

What I suggest is not a fork. Maybe a branch. They're going to be working on improving its general score editing features and we need to roll in those changes. The more cooperation they give us the better. If possible we join the project. If not we maintain a patch against it or plug-ins.

> 2) Rosegarden is a very powerful DAW that has score editing, a piano
> roll, and audio integration already done - but it's Linux only. Talk
> of porting the GUI to Qt4, a cross-platform GUI, has been thrown
> around on the Rosegarden-devel list for years, and they seem to be
> very, very slowly moving forward with that objective. The main
> hindrance with the porting, from what I gather, has nothing to do with
> GUI, but rather that all of the audio stuff is hardcoded to work with
> Linux's ALSA/JACK drivers, which we don't need to worry about to get a
> score editor... for now. (http://www.rosegardenmusic.com/)

It's a sequencer with good notation support. My (second hand) information is that the development team is not at all interested in microtonal support. Jack should move to Windows with the rest of KDE. If the Rosegarden team don't have a plan for this it worries me. It suggests their code-base is getting bloated.

> 3) MusicKit, which looks very promising, is a non-GPL but free
> library/API to use, which apparently does almost anything. I haven't
> done as much research into this one as I have the other ones, but it
> does seem very, very interesting, and might make it very easy to
> proceed. (http://musickit.sourceforge.net/)

It shares a common ancestor with Csound, doesn't it? How is it relevant?

> 4) TSE3 is a GUI-less MIDI and audio sequencer library. We can build a
> notation GUI straight on top of this. (http://tse3.sourceforge.net/)

I don't like the idea of GUI-less. Too much work for us.

> 5) Jazz++ is a cross platform MIDI and audio editor that Hans Straub
> pointed out some time ago. It is currently being ported to wxwidgets.
>>From what I can tell from the Google images results for "Jazz++", it
> has a piano roll, a "Harmony Generator" which might be useful to turn
> into some kind of a lambdoma, but no staff editor. It does look a
> little rough around the edges, and its website isn't all that helpful.
> (http://jazzplusplus.sourceforge.net/)

I used an old version if Jazz and it was a very basic MIDI sequencer. I followed the Jazz++ development once. If it's still rough around the edges I guess it always will be. Rosegarden is the project that succeeded.

> 6) ABC/MicroABC, Lilypond, etc. could possibly be modified to be
> interactive, or have a front end created around them. Rosegarden, to
> some extent, extends Lilypond in such a way. If people like the way
> Lilypond looks, it might be nice to take its graphic library, modify
> it, and integrate it with TSE3, or something like that. This one might
> not even prove feasible in the end, but it was discussed in the
> thread.

Rosegarden and Canorus are both front-ends for Lilypond in that sense. The back-end is largely irrelevant when it comes to writing a score editing GUI.

Lilypond output is good because you can then tweak it for a printed score. I think we can customize it for what we need. I'm still waiting for a reply from Torsten on that.

> Note also that some of these options would give us the secondary
> objectives right away: Rosegarden, if we do manage to port it, will
> give us audio and VST integration right off the bat. And Canorus aims
> to be a score editor, so we'd have that secondary objective
> accomplished. I do think that we will need to eventually fork off from
> the Canorus route though, as even if they do implement some kind of
> microtonal features in their software, new ideas seem to come out of
> tuning and MMM at a fairly rapid rate. Unless Canorus latches onto the
> microtonal community's wants and needs, which are considerably more
> difficult to implement than what would be expected by a normal score
> editor, I see us having a project designed mainly by and for us, a la
> Scala.

I think Canorus is the way to go. Either Canorus or Rosegarden will mean C++ which is fine with me.

Graham

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗J.A.Martin Salinas <tony@...>

🔗Graham Breed <gbreed@...>

🔗J.A.Martin Salinas <tony@...>

🔗Daniel Wolf <djwolf@...>

It's great that there seems to be so much interest in this, and if it's an open source/free software project, all the better. Alas, my own experience in programming a notation program was done back in the upper Pleistocene, so I can only offer encouragement. But may I point out two features for microtonal notation in existing programs that ought to be emulated, or even better, improved upon?

First, in Finale, the non-standard key signature feature allows the user to define (a) the number of lines in a staff, (b) the number of tones in an octave, (b) the number and position of nominals ("naturals") in an octave, (3) the values in +/- steps of accidentals the font and symbols associated with each accidental. I can get a reasonably good real time composing desktop with this, provided that I output to an external synth or to InTun and then to my computer's synth. The limitations are (1) 128 midi notes, (2) no microtonal playback with Finale's built in synth or Kontakt Player (although once a score is completed, I can export the midi file and use Scala to add pitch bends, then re-import to Finale, so long as I keep each channel monophonic), (3) alternative staff designs are limited to changing the number of lines, not the spacing between lines, a la Klavarskribo or Wilson.

Second, in Lime, there is a tuning table in which a pitch bend is assigned to each note and accidental combination. This is a great feature, but limited to 35 pitches (= 7 naturals, plus two modifications upwards and two downwards). I suspect that this limitation is arbitrary, but not certain. Further, it's not clear to me how Lime handles fonts, and that's a deal breaker. In any case, the tuning table is a very useful feature, and I am still surprised that no one has made a plug-in for Finale or Sibelius that can do the same thing.

I also think that the rules in Harmony Assistant are worth looking at.

All the best to you!

Daniel Wolf

🔗Carl Lumma <carl@...>

Daniel wrote:

>First, in Finale, the non-standard key signature feature allows the user
>to define (a) the number of lines in a staff, (b) the number of tones in
>an octave, (b) the number and position of nominals ("naturals") in an
>octave, (3) the values in +/- steps of accidentals the font and symbols
>associated with each accidental.

That's pretty comprehensive. Have you ever considered doing the
world a massive favor and writing a tutorial on it (or is there a
good reference already)?

>I can get a reasonably good real time
>composing desktop with this, provided that I output to an external synth
>or to InTun and then to my computer's synth. The limitations are (1) 128
>midi notes,

So I take it I can span multiple MIDI channels with the +/- steps
assignment. Too bad.

>(2) no microtonal playback with Finale's built in synth or
>Kontakt Player (although once a score is completed, I can export the midi
>file and use Scala to add pitch bends, then re-import to Finale, so long
>as I keep each channel monophonic),

Or get a Scala-compatible softsynth and wire Finale up to it
via a virtual MIDI port!

>(3) alternative staff designs are
>limited to changing the number of lines, not the spacing between lines, a
>la Klavarskribo or Wilson.

Too bad.

>Second, in Lime, there is a tuning table in which a pitch bend is assigned
>to each note and accidental combination. This is a great feature, but
>limited to 35 pitches (= 7 naturals, plus two modifications upwards and
>two downwards). I suspect that this limitation is arbitrary, but not
>certain. Further, it's not clear to me how Lime handles fonts, and that's
>a deal breaker. In any case, the tuning table is a very useful feature,
>and I am still surprised that no one has made a plug-in for Finale or
>Sibelius that can do the same thing.

There was a microtonal plugin for Sibelius 2, but last I heard
from the developer it was broken by Sibelius 3.

>I also think that the rules in Harmony Assistant are worth looking at.

Yes. I'll make it a task to check out Harmony Assistant.
I have it installed here, albeit in evaluation mode. As I
recall, Jon Lyle Smith got good results with it.

-Carl

The MMM Notation Editor/Sequencer: Recap/Update

🔗Mike Battaglia <battaglia01@...>

🔗Jon Szanto <jszanto@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

🔗Steve Morris <barbershopsteve@...>

🔗Jon Szanto <jszanto@...>

🔗Carl Lumma <carl@...>

🔗Steve Morris <barbershopsteve@...>

🔗Jon Szanto <jszanto@...>

🔗Carl Lumma <carl@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

🔗Mike Battaglia <battaglia01@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗Graham Breed <gbreed@...>

🔗Mike Battaglia <battaglia01@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

🔗Graham Breed <gbreed@...>

🔗Carl Lumma <carl@...>

🔗Mike Battaglia <battaglia01@...>

🔗Mike Battaglia <battaglia01@...>

🔗Carl Lumma <carl@...>

🔗Carl Lumma <carl@...>

🔗J.A.Martin Salinas <tony@...>

🔗Graham Breed <gbreed@...>

🔗J.A.Martin Salinas <tony@...>

🔗Daniel Wolf <djwolf@...>

🔗Carl Lumma <carl@...>

🔗Carl Lumma <carl@...>

🔗Rick McGowan <rick@...>