Yahoo Tuning Groups Ultimate Backup makemicromusic A poll, if you will: Microtonal Production Environment

(Cross-posted to MMM and MicroTools)

Besides the score editor we're currently working on, there was once
talk of creating a full-fledged cross-platform production environment,
something like a DAW. Something that might have a track view, a piano
roll, VST support, possibly a mixer or console view, etc., all with
microtonal features build in under the hood. Something in which you
can route to different MIDI devices and use different VST synths and
such. A microtonal Rosegarden, or Logic, or SONAR, or anything like
that, if you will. The focus wouldn't be so much on making the score
pretty for printing (although that might be nice), but on making it
easy to produce microtonal works in terms of the actual sound of the
end result wise. A production environment, if you will. There is going
to be a very, very strong emphasis on making this software easy to
use, so that those of us who are less computer-literate can still jump
into writing microtonal music.

I do envision it having a very robust notation and staff view, a lot
of which I want to "borrow" from the score editor we're working on
(and possibly even design the score editor with that kind of
portability in mind from the getgo). I want to have the notes in the
staff view look like 72-tet or JI or whatever tuning or notation
system it is you're using, and then translate all of that behind the
scenes into MIDI/MTS/Scala, or pitch bent/channel swapped MIDI, or
OSC, or whatever else. Things that are extremely difficult to
implement or extraneous to this specific goal, such as audio support
or a CSound GUI or anything even resembling a synth engine are not an
immediate priority for this program, but would be future
considerations later if we can get this off the ground first. In other
words, let's just make it a MIDI sequencer with some fancy views at
first.

So to the people on this forum: does this sound like something that
you would be interested in having? Does it sound like having
everything rounded together in a package like this would make
production easier for you? Many of the microtonal works that I've
heard are extremely interesting, but simply run through some sort of
GM-sounding synth, and so I thought that having a production
environment like this might make it easier for people to focus on the
production side of creating music. I also thought it might make it
easier for people who are musicians and composers first and foremost
to jump right into this kind of stuff without having to learn how to
use multiple pieces of software and connect them all.

I've spoken to a few of you off-list, so I know there is at least some
demand for it. If there is enough demand, I'll kick this off as a
project in its own right alongside the score editor. It's a pretty big
goal and could take some time to complete, but there is a huge wealth
of talent on these lists, so I am pretty optimistic.

Most importantly, this could determine the design route for a few
different projects. I've also been throwing around the idea of first
creating some general purpose toolkits before jumping into either one
of these programs. I like this approach even just on the merit that it
will make microtonal software development in the future much easier
for whoever has the next big idea. A few people on the score editor
team think that it'll be too much work to go that route.

However, if there is going to be a score editor and a production
environment, both projects might move along more quickly if we code
together on architectures that will be common to both projects. So we
might end up with some toolkits just out of necessity. For example, it
makes sense to code the notation GUI in this way, or else we're going
to have the people from the score editor working on their GUI, and the
people from the production environment working on another GUI, which
is just wasted time for everyone. It also determines whether it's
necessary to come up with some kind of universal Microtonal Event
List, as AKJ suggested, and to what extent the programs will be able
to communicate with one another.

Carl has requested that I actually go write some wireframe diagrams
and go into how I think the production environment should work and
how, if at all, it overlaps with the score editor. Before I actually
take the time to do that, though, I want to see if there is any sort
of interest for it. So speak up! We need to hear some feedback right
now. And if you'd be interested in helping to code such a project, any
little bit of effort would certainly help move things along real, real
nice-like.

-Mike

🔗Jon Szanto <jszanto@...>

Mike,

For starters, it might be helpful, communication-wise, if you could
have a small reduction in your "walls of text" posts! To tap the
feeling of the MMM community for your project, you needn't have placed
paragraphs and paragraphs of ... stuff. Try boiling things down to the
nitty-gritty, and I guarantee you'll get more eyeballs reading, which
means more people responding.

Next: as you know, I've joined over at the Google group as well, and
will give my support as I am able. But I plead with you:

Start simple. Make something work.

Any of us who have been here for more than a few months can tell you
of the many projects, all well-intentioned, that simply foundered on
the rocks of over-optimism, wanting to please everyone in the room,
and lack of concrete, step-by-step goals. I'd like this to succeed, so
please be realistic. The people on board are talented, but they aren't
gods.

--- In MakeMicroMusic@yahoogroups.com, "Mike Battaglia"
<battaglia01@...> wrote:
> So to the people on this forum: does this sound like something that
> you would be interested in having?

Of course.

> Does it sound like having
> everything rounded together in a package like this would make
> production easier for you?

Only if it is done exceedingly well, which to me means that it has to
match, or at least come very close, to the best of the commercial apps
in any particular area you choose to look at (i.e. notation has to be
as good as Finale/Sibelius/etc, anything going towards audio
production has to be as good as what's out their (Logic/Sonar/etc).

If the goal is smaller (great score editor with some sound capability)
you'll have a chance to make it. Making it the last microtonal music
production app anyone will ever need might be a bit much to bite off.

> Many of the microtonal works that I've
> heard are extremely interesting, but simply run through some sort of
> GM-sounding synth, and so I thought that having a production
> environment like this might make it easier for people to focus on the
> production side of creating music. I also thought it might make it
> easier for people who are musicians and composers first and foremost
> to jump right into this kind of stuff without having to learn how to
> use multiple pieces of software and connect them all.

Wellll, that would sure be great, but... :) One of the things I
enjoyed most when I was more active on the list was to help people put
together systems to create their music. Always fun when it finally
comes together! And not all of us cram the stuff into GM:

http://www.microtonal.org/music/DoSomething.mp3

Written for Prent's "Making Microtonal Music Day" back in... uh...
2006 I think.

Crap. I've just created another wall of text.

Cheers,
Jon

🔗Mike Battaglia <battaglia01@...>

Haha, fair enough. It's hard to condense everything into one little
bit sometimes. I'll try with this post, let's see how it goes. Here's
a more condensed version:

I am used to working in a DAW environment. I like to mess around with
tones, put on effects and such, and all of that. The notation part of
it, for me, is crucial as an easy way to enter in notes to be screwed
around with in the DAW. I -hate- most of the DAW's that are available
in terms of what they can do with staff notation. I absolutely hate
them. They weren't designed for anything that even rhymes with
"microtonal".

I want to be able to do the following:

1) write a piece of music using a notation editor that makes intuitive
sense to me and will likely need to support a wide range of microtonal
music.
2) accomplish this objective without having to deal from my viewpoint
as a user with anything that even sounds like channel swapping or
pitch bending or retuning MIDI with Scala or Fractal Tune Smithy or
any of that. All of that should be done under the hood.
3) then be able to mix, engineer, and produce the production -ONLY IN
MIDI, AT FIRST- so that I can get a professional sounding final result
4) be able to go back and forth from the writing to the mixing, from
the staff notation to the synth I'm using, fluidly and easily, without
having to switch between programs and wait for them to load, without
having to have multiple large-scale programs open at the same time,
and without having to buy any extra software to accomplish this basic
functionality
5) And, finally, be able to give this product to musicians of average
computer-literacy and have them be able to use it reasonably well out
of the box. As well as they can use Logic or Sibelius. I'm talking
about musicians that will give up on writing microtonal music if they
have to get scala set up (which involves first getting the GTK set up,
which scares off quite a few people), and then setting it up to retune
MIDI, or generating a scala file to send to Kontakt by way of a
commercial program.

-Mike

🔗Mike Battaglia <battaglia01@...>

Jon wrote:
> Next: as you know, I've joined over at the Google group as well, and
> will give my support as I am able. But I plead with you:
>
> Start simple. Make something work.

Well, let's put it this way: I find that Sibelius is great for scoring
and awful for production. The people involved with the score editor
would rather write Sibelius and don't really want to accommodate any
sort of serious production needs, even potential ones in the future.
They don't want a track view, for example. All they want is basic
sequencer playback. So this is going to likely have to be a separate
project.

Or, in other words: I don't want this to be a huge, complex, bloated
behemoth that is Finale and ProTools put together any more than you
do.

>> So to the people on this forum: does this sound like something that
>> you would be interested in having?
>
> Of course.

Good. Believe it or not, I just had a very lively conversation in
which it was posed that I was "the only one" who wanted to have this
and that existing tools were "fine."

> Only if it is done exceedingly well, which to me means that it has to
> match, or at least come very close, to the best of the commercial apps
> in any particular area you choose to look at (i.e. notation has to be
> as good as Finale/Sibelius/etc, anything going towards audio
> production has to be as good as what's out their (Logic/Sonar/etc).

Well, my idea is that the two programs would sort of complement each
other. What would be bloated is stuffing Sibelius into Sonar as the
staff view. I think we're going to have a score editor, which is going
to be Sibelius... eventually. I would also like to have Sonar...
eventually as well. So what will be necessary is some degree of
interoperability between the two programs.

If you like writing things out in a score, there's a program for that,
and it's called Sibelius. We're working on a microtonal version of
that. But, if you like composing on the fly or in a DAW, there's a
program for that too, and it's called Logic. We need a microtonal
version of that too. Having an easy transition from score editor to
DAW is, as far as I know, something that NOBODY has together right
now, but it might evolve out of necessity here.

Either way, the audio stuff is going to be dealt with much, much
later. Tackling MIDI would be better at first.

> If the goal is smaller (great score editor with some sound capability)
> you'll have a chance to make it. Making it the last microtonal music
> production app anyone will ever need might be a bit much to bite off.

Or a great sequencer with some score editing. I really have less of an
interest in the score editor than I do in a DAW. Perhaps I'm being
unclear: I don't want this to be the be-all, end-all, app. I just want
a sequencer, and the score editor group doesn't. So, I'm going to be
working on this instead. Most likely I'll contribute to both projects
to some extent.

> http://www.microtonal.org/music/DoSomething.mp3
>
> Written for Prent's "Making Microtonal Music Day" back in... uh...
> 2006 I think.

Sounds great, man. Damn.

> Crap. I've just created another wall of text.

Ah, it's alright, so did I.

-Mike

🔗Carl Lumma <carl@...>

Hi Mike,

>I am used to working in a DAW environment. I like to mess around with
>tones, put on effects and such, and all of that. The notation part of
>it, for me, is crucial as an easy way to enter in notes to be screwed
>around with in the DAW. I -hate- most of the DAW's that are available
>in terms of what they can do with staff notation. I absolutely hate
>them.

Have you tried using your favorite notation editor (which I
gather is Sibelius) and sending MIDI from that into synths
in your DAW?

>They weren't designed for anything that even rhymes with
>"microtonal".

I think MIDI is what wasn't designed for this. DAWs typically
host VSTs, record their output to PCM audio, and let you arrange
that audio on a timeline and then mix it down. All of those
are tuning-agnostic functions. If you want it to manipulate
multiple instances of synths for you in a convenient way, that's
one thing, but it isn't the limitations of DAWs you'd be getting
around, but rather the limitations of MIDI -- right?

Furthermore, what is your DAW of choice? Sonar has a nice feature
where you can group tracks and collapse them and stuff, and I
think other DAWs do as well. So you could put multiple instances
of your synths into groups and that might help. Have you tried
that?

>I want to be able to do the following:
>
>1) write a piece of music using a notation editor that makes intuitive
>sense to me and will likely need to support a wide range of microtonal
>music.

See above re. using Sibelius with your DAW.

>2) accomplish this objective without having to deal from my viewpoint
>as a user with anything that even sounds like channel swapping or
>pitch bending or retuning MIDI with Scala or Fractal Tune Smithy or
>any of that. All of that should be done under the hood.

So far, making electronic music means being a nerd on some level.
It was like that when Wendy Carlos started with Moog synths in
the '60s, and to paraphrase her, new technology has given us more
power but hasn't made anything easier. If you're afraid of bus
routing and MIDI channels, I think you'd be having a problem with
electronic music in general, not just microtonality.

>3) then be able to mix, engineer, and produce the producti on -ONLY IN
>MIDI, AT FIRST- so that I can get a professional sounding final result

What does it mean to mix and engineer MIDI?

>4) be able to go back and forth from the writing to the mixing, from
>the staff notation to the synth I'm using, fluidly and easily, without
>having to switch between programs and wait for them to load,

Well, get a faster computer! With an 8-core Mac Pro running a
stripped down version of Windows XP, you can have plenty of
synths in a DAW plus Sibelius all running at once, and if you
turn off taskbar animation switching apps should essentially
instantaneous a lot of the time.

Building a Sibelius into a Sonar wouldn't solve any task-switching
issue, either, since it's the same compute load either way.

>and without having to buy any extra software to accomplish this basic
>functionality

Not even synths? That sounds like you're calling for rebuilding
all of music software from scratch.

-Carl

🔗Mike Battaglia <battaglia01@...>

I'm going to partially quote these not because I'm not reading what
you're saying, but just to keep the message length down.

> Have you tried using your favorite notation editor (which I
> gather is Sibelius) and sending MIDI from that into synths
> in your DAW?

Yes. And I've tried using Sibelius' built in support for Kontakt. It
is bulky and awkward, and the software really wasn't designed for that
sort of thing. It is not at all fluid and, to take it a step further,
actively interferes with the quick pace and workflow of my
compositions.

> I think MIDI is what wasn't designed for this. DAWs typically
> host VSTs, record their output to PCM audio, and let you arrange
> that audio on a timeline and then mix it down. //

MIDI limitations play into it, but what I'm getting at furthermore is
that a microtonal feature set was just not a design consideration when
the people at Cakewalk and Digidesign came up with their software. If
it was, they wouldn't have stuck with just MIDI. They didn't go out of
their way to support OSC or MTS or anything. They didn't implement
pitch bending and channel swapping. They didn't come up with an
ingenious solution to solve the problem.

As for VST synths and PCM audio, perhaps we have a different view of
what a DAW really entails. That is part of a DAW, to be sure, but the
main thing I'm getting at is a sequencer with a bunch of different
views and ways to manipulate the data. And I don't want to code it in
such a way that it will be impossible to add audio support in the
future.

Perhaps calling it a DAW is a bad idea, since the A stands for
"audio", but let the record show that what I've outlined in the
statement above is what I'm getting at.

> Furthermore, what is your DAW of choice? Sonar has a nice feature
> where you can group tracks and collapse them and stuff, and I
> think other DAWs do as well. //

Track folders are useful, and I do actually use them a lot. But it
still doesn't solve the problem of not having an intuitive environment
to work in in terms of how I actually enter notes in. I suppose this
is where you would say to route Sibelius into SONAR via virtual MIDI
ports or even MIDIYoke or MIDIOx or something, and I find it to be an
awkward solution. Sibelius makes mixing extremely difficult and
doesn't have much in the way of MIDI accuracy or control. And I've run
into a few latency and sync issues when audio is involved as well.

> So far, making electronic music means being a nerd on some level.
//

That's what I'm trying to address with this program. I'm not afraid of
it, but I find that solution cumbersome and detracting from the
concentration I need to write. And even though I've gotten used to it
now to some extent, it certainly isn't catching on amongst most other
musicians.

> What does it mean to mix and engineer MIDI?

It means to be able to change the patch and bank, the output port, and
the volume, pan, chorus, and reverb settings on a track as well as
whatever other clever MIDI controllers I'm forgetting. It means making
a simple interface to control those things. On a more advanced level,
it might include something like automation as well, although believe
me when I say I'm not thinking about that just yet.

> Well, get a faster computer! //

I'm broke. And I'm sure you know why that solution doesn't really
satisfy me here :P

If we're talking about memory footprints and overheads and such with
the score editor, why is that all supposed to go by the wayside here?

> Building a Sibelius into a Sonar wouldn't solve any task-switching
> issue, either, since it's the same compute load either way.

Right. So I don't really want a full Sibelius into Sonar. I want only
what parts of our ideas from the score editor will be necessary.
Pretty printing stuff will probably not be necessary. Monitor
readability will be necessary, and implementing different types of
microtonal notation will be necessary.

> Not even synths? That sounds like you're calling for rebuilding
> all of music software from scratch.

Synths I'll allow.

-Mike

🔗Carl Lumma <carl@...>

Mike wrote:

>> I think MIDI is what wasn't designed for this. DAWs typically
>> host VSTs, record their output to PCM audio, and let you arrange
>> that audio on a timeline and then mix it down. //
>
>MIDI limitations play into it, but what I'm getting at furthermore is
>that a microtonal feature set was just not a design consideration when
>the people at Cakewalk and Digidesign came up with their software. If
>it was, they wouldn't have stuck with just MIDI. They didn't go out of
>their way to support OSC or MTS or anything.

MTS is for synths, not DAWs. OSC didn't exist until recently,
and actually is still being developed.

>If we're talking about memory footprints and overheads and such with
>the score editor, why is that all supposed to go by the wayside here?

It isn't. But presumably Sibelius has already gone through a lot
to get its memory footprint optimal. It was doing things with
graphics on 1999-era computers that had never been seen before,
so I know that's true.

-Carl

🔗Jon Szanto <jszanto@...>

Mike,

Ok, now you are really losing me, quite fast.

If you aren't talking DAW, then don't say DAW - say sequencer. Stick
to correct terminology or *everyone* is going to be on different pages!

I'm a Sonar user as well. And I go so far back in time that I actually
used Cakewalk 1.0. On Windows 3.1. In the studio.

*Of course* these applications don't include native support for any
kind of microtonal musical work - why would they? Because some
infinitesimally small number of musicians would *like* them to? And
yet it sounds like what you are asking an ad hoc group of people to do
is to recreate all the work that went into these products, most of
which have been refined over many years, and on top of doing that same
sequence/mix tango, you want it to seamlessly manage microtonality -
through MIDI - under the hood.

I'm going to have to get off this bus.

I'm not sure you've really thought through the complexities you are
staring at right in front of you. Making non-microtonal
synths/instruments work... by pitch bends? Or somehow, somewhere,
create new instruments with microtonal support? Or?

I've made my peace with the difficulties inherent in using the tools
we have, electronically and otherwise, to make non-12 music. I take
full advantage of a fair number of VST instruments that DO support
microtuning, and I manage with other instruments to varying degrees. I
input music with a MIDI keyboard controller with a design that, for
the last couple hundred years, has been fixed in the 7-5 format. I
look at a staff view that shows me pitches that don't represent what I
hear.

I don't let it get in my way. And if I had the choice of either trying
to build your system from scratch or try to get a group to do it, OR
use the tools that are out there now, I'm just going to get on with
the dance, and take up any improved widgets as they get developed down
the road.

That's just me.

Cheers,
Jon

P.S. I'm no stranger to tilting at windmills. The guy I learned
microtonality from started by researching and then creating his own
entirely different tuning scheme, created an ensemble of acoustic
instruments to play in that tuning over the period of about 40 years,
created a body of music to perform (by writing on score paper), got
ensembles together, and did public performances, all without - for the
most part - independent or institutional financial support. Just a
vision, and a maniacal focus to see that it came to pass.

Only a few people like this ever pass our way.

🔗Mike Battaglia <battaglia01@...>

Short quotes, for your viewing pleasure.

On Thu, Jul 10, 2008 at 3:32 AM, Jon Szanto <jszanto@...> wrote:
> If you aren't talking DAW, then don't say DAW - say sequencer. Stick
> to correct terminology or *everyone* is going to be on different pages!

To clarify: I want to have a sequencer that can, at some point, be
expanded outward into a DAW.

Version 1.0 will be the sequencer and have no audio. I'll be happy
with that. I want to design the architecture with the mindset that
there may in the future be audio support. Does that make sense?

But if we're going to make sure the score editor is partitioned in the
way I suggest, then I don't have a problem putting the DAW on hold to
focus on that stuff before forking this off.

> *Of course* these applications don't include native support for any
> kind of microtonal musical work - why would they?

I don't expect them to. If we want a sequencer with microtonal
support, we'll have to make it ourselves, or it just won't get made.

> And yet it sounds like what you are asking an ad hoc group of people to do
> is to recreate all the work that went into these products

I think you're getting confused as to what I want to tackle for 1.0
and what I see as a potential long term goal. Let me try to make it as
precise as possible:

For version 1.0, I just want to make a simple sequencer that is based
on the principle that the internal events list shouldn't be rooted in
MIDI. The internal events list will be able to be translated into MIDI
or OSC or anything. This means that microtonal stuff will be easy to
implement because we're going to create the data model ourselves, the
same as the score editor group is doing. I want the internal events
list to be able to be parsed with any one of a number of different
"views", and for version 1.0, I'd be happy with nothing but a track
view and a notation view and perhaps a piano roll. It sounds like the
same thing as the score editor, but under the hood, it's not, but not
too much harder to tackle. At first perhaps we'll only have OSC
support, or only MIDI with MTS support.

Sound simple enough? And, if we partition the score editor design
correctly (which is good practice regardless), the notation view and
the playback engine will already be done from work on that.
Furthermore, the score editor will get done faster, as I and other
people will be able to work on the score editor knowing that we're
doing things that are also helping to get the sequencer done, which is
my main concern.

Things to be added later, in some kind of loose chronological order:
- VST wrappers in the program, so we can have synths right in it
without a separate rack
- Developing algorithms to play our stuff back using MIDI without MTS
support (pitch bends and channel swapping)
- Anything involving automation
- Other views such as a pattern view or whatever
- Anything involving audio

Does that make sense?

> I'm going to have to get off this bus.

Well hopefully now that you know what I'm talking about, you can hop
on the roof. I'm not looking to write SONAR right away, you know.

> I'm not sure you've really thought through the complexities you are
> staring at right in front of you. Making non-microtonal
> synths/instruments work... by pitch bends? Or somehow, somewhere,
> create new instruments with microtonal support? Or?

Scala already does the pitch bend and channel swapping. Carl was
talking about trying to see if we could just get a copy of the
algorithm from the developer. Creating new instruments would be great
some 15 projects down the road. That's not going to be a part of this.

> I've made my peace with the difficulties inherent in using the tools
> we have
//
> I'm just going to get on with
> the dance, and take up any improved widgets as they get developed down
> the road.

Fair enough. I don't know if everyone realizes that most of the
intellectual work has been done already. I'm just sort of trying to
round up the pieces and put them into one project.

If you see anything that you'd like to help out with, we'd could
always use more developers. I don't think that it's as complicated as
you thought it was - complicated, yes, but only slightly so than the
score editor, which is already going to incorporate a staff view and a
piano roll and a playback engine.

Furthermore, if we make the score editor partitioned as I suggest, and
if I partition this project effectively as well, we'll have for the
purposes of future development, notation API's, sequencer API's, piano
roll API's, etc. That means we'll see -much- more software in the
future.

-Mike

🔗hstraub64 <straub@...>

🔗MDK <mdk@...>

> > I'm not sure you've really thought through the complexities you are
> > staring at right in front of you. Making non-microtonal
> > synths/instruments work... by pitch bends? Or somehow, somewhere,
> > create new instruments with microtonal support? Or?
> > Scala already does the pitch bend and channel swapping. Carl was
> talking about trying to see if we could just get a copy of the
> algorithm from the developer. Creating new instruments would be great
> some 15 projects down the road. That's not going to be a part of this.

well, actually thats one thing that I would happily do alongside any sequencer development (albeit instruments constructed using toolkits like SynthMaker / Reaktor / Max-MSP rather than coded from scratch)

I already built a .tun file parser module SynthMaker some time ago and would happily build microtuning modules for that and other environments...provided there is some kind of protocol and/or file format that is agreed on, or at least some kind of interoperability contract between the proposed sequencer and instruments / environments.

I think the pitchbend / channel swapping algorithm wouldnt be too difficult to implement as its basically a variation on the standard polyphonic voice assignment techniques.

Its a similar issue to the one i was trying elucidate in my earlier post in the tools list about developing libraries for instrument / plugin developers to use so that adding microtonal support is as easy as possible. If we can prototype the necessary pieces (sequencer, some instruments, protocol, file format etc) with open source code then it should hopefully provide a great reference for others.

btw, wouldnt it be better if all this was kept on the microtools list, rather than spread across 2 lists :)

🔗Jon Szanto <jszanto@...>

🔗Mike Battaglia <battaglia01@...>

On Thu, Jul 10, 2008 at 4:23 AM, Jon Szanto <jszanto@...> wrote:
> <sigh>
>
> I wish you had it in you to compose brief, concise posts because,
> Mike, gods love you, virtually every message I've seen from you is
> really really long. It's late, and I can't reply to a couple pages of
> new text. I'll try tomorrow, but here are my two comments:

Hahaha, ah, I'm sorry. Here, this one will actually be short.

> 1. You repeatedly use the terms "simple" and "easy". There is nothing
> simple or easy about creating, essentially from scratch, a sequencer
> capable of recording and reproducing microtonal data.

That isn't how I was using those terms. I was using those terms to
explain what I was meaning in the "simplest" possible way.

> 2. Here's something for you to think about: Pitch bends are not a
> panacea for microtonality.

So you didn't read the message then. I was quite clear on that pitch
bends were going to be some sort of backwards compatibility feature
that will NOT be a part of 1.0.

The goal, again, is to have an events list of notes and what not that
are NOT stored in MIDI. They will be stored in our own data model.

We will output those note however we want. For 1.0, I think we should
only implement MIDI/MTS, which has nothing to do with pitch bends, and
OSC. THAT should be pretty close to a panacea for microtonality.

-Mike

🔗plopper6 <billwestfall@...>

🔗Graham Breed <gbreed@...>

This is on MMM, is it? I'll copy to microtools. It's best we collate things there.

plopper6 wrote:

> The focus on notation up to now seems perplexing: notate for what > reason? For who to play? Is there a realistic assumption that anyone > will ever actually use the scores?

It's nice for Mike to canvas for his rival project but we still haven't fixed the requirements for the original one. I've copied some use cases I proposed below. You (and anybody else) can vote on whether you're interested in them.

The focus on staff notation was because that's what people at the time asked for. It's notation for a composition tool. For the computer to play. Getting printed output is another question, and there are use cases for that. Here are mine for the input:

1) User enters notes with typewriter-style keyboard and mouse.

2) User enters pitches from MIDI keyboard with typewriter-style keyboard and mouse determining the durations.

3) User enters notes as a real-time MIDI performance and expects the timing to be preserved exactly.

4) User enters notes as a real-time MIDI performance and expects the timing to be quantized.

5 and 6) Like (3) and (4) but with a MIDI file.

7 and 8) Like (3) and (4) but with an OSC device.

9) User edits durations in a piano roll view and expects the changes to be reflected accurately in the staff.

10) User edits durations in a piano roll view to tweak the MIDI timing but expects the staff view to be unchanged.

> But something that can actually push some microtonal through with > more than that same mind numbing MIDI string sound, now you're > talking.

You're losing grammar there and I don't know what you're proposing.

> Seems to me that Scala is 90% of the way there, doesn't seem > impossible to add that extra 10% to something Scala-like to get what > you're talking about. > (Just the non-technical, maybe non-realistic opinion of a sometime > Scala user)

What does Scala have to do with any of this?

Graham

🔗hstraub64 <straub@...>

--- In MakeMicroMusic@yahoogroups.com, "Mike Battaglia"
<battaglia01@...> wrote:
>
> To clarify: I want to have a sequencer that can, at some point, be
> expanded outward into a DAW.
>
> Version 1.0 will be the sequencer and have no audio. I'll be happy
> with that. I want to design the architecture with the mindset that
> there may in the future be audio support. Does that make sense?
>

IMHO, expanding into a DAW makes little to no sense, because:

1) The existing DAW around are gorgeous and offer terrific
functionality that any newly created DAW will not be able to offer
for years. (This holds for sequencer, too - but if audio is involved,
the complexity is several orders of magintude higher...)

2) Every decent DAW supports import from MIDI files.

SO I would say: just make a sequencer that produces midi, and let
everybody us his favorite DAW for production - by it Abletop, be it
Cubase, Samplituide or whatever.

But, well, it is not forbidden to start coding a DAW - and in version
1.0, this is not a question anyway, so we can leave this for later...
--
Hans Straub

🔗Steve Morris <barbershopsteve@...>

Joe,

As much as I agree with your "first make something work" request in my
experience it is important to consider the whole big desired end
result up front and THEN choose a design strategy that allows you to
implement a tiny key subset, which can THEN grow incrementally into
fuller functionality. Rushing into starting something small with no
consideration of the big picture often takes you down blind alleys
that limit eventual functionality. You want to design extensibility in
upfront. It is to easy to preclude important things with the wrong
design choices.

Designing an effective growth path is part of good design. You can't
do that without thinking about what you want to grow into.

Talking about the big picture is not the same thing as planning to
implement the big picture whole hog. That would obviously fail and
that is your legitimate concern. However it is also possible to throw
out the baby with the bath water by going too far in the other
direction.

I emphasize this because I have been responsible for projects that
have failed both ways. II'm not sure which is more painful.

Steve

On Thu, Jul 10, 2008 at 1:44 AM, Jon Szanto <jszanto@...> wrote:
> Mike,
>
> For starters, it might be helpful, communication-wise, if you could
> have a small reduction in your "walls of text" posts! To tap the
> feeling of the MMM community for your project, you needn't have placed
> paragraphs and paragraphs of ... stuff. Try boiling things down to the
> nitty-gritty, and I guarantee you'll get more eyeballs reading, which
> means more people responding.
>
> Next: as you know, I've joined over at the Google group as well, and
> will give my support as I am able. But I plead with you:
>
> Start simple. Make something work.
>
> Any of us who have been here for more than a few months can tell you
> of the many projects, all well-intentioned, that simply foundered on
> the rocks of over-optimism, wanting to please everyone in the room,
> and lack of concrete, step-by-step goals. I'd like this to succeed, so
> please be realistic. The people on board are talented, but they aren't
> gods.
>
> --- In MakeMicroMusic@yahoogroups.com, "Mike Battaglia"
>
> <battaglia01@...> wrote:
>> So to the people on this forum: does this sound like something that
>> you would be interested in having?
>
> Of course.
>
>> Does it sound like having
>> everything rounded together in a package like this would make
>> production easier for you?
>
> Only if it is done exceedingly well, which to me means that it has to
> match, or at least come very close, to the best of the commercial apps
> in any particular area you choose to look at (i.e. notation has to be
> as good as Finale/Sibelius/etc, anything going towards audio
> production has to be as good as what's out their (Logic/Sonar/etc).
>
> If the goal is smaller (great score editor with some sound capability)
> you'll have a chance to make it. Making it the last microtonal music
> production app anyone will ever need might be a bit much to bite off.
>
>> Many of the microtonal works that I've
>> heard are extremely interesting, but simply run through some sort of
>> GM-sounding synth, and so I thought that having a production
>> environment like this might make it easier for people to focus on the
>> production side of creating music. I also thought it might make it
>> easier for people who are musicians and composers first and foremost
>> to jump right into this kind of stuff without having to learn how to
>> use multiple pieces of software and connect them all.
>
> Wellll, that would sure be great, but... :) One of the things I
> enjoyed most when I was more active on the list was to help people put
> together systems to create their music. Always fun when it finally
> comes together! And not all of us cram the stuff into GM:
>
> http://www.microtonal.org/music/DoSomething.mp3
>
> Written for Prent's "Making Microtonal Music Day" back in... uh...
> 2006 I think.
>
> Crap. I've just created another wall of text.
>
> Cheers,
> Jon
>
>

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

🔗Carl Lumma <carl@...>

plopper6 wrote...

>Yes!
>The focus on notation up to now seems perplexing: notate for what
>reason? For who to play? Is there a realistic assumption that anyone
>will ever actually use the scores?

There are two important points here:

1. Musicians can't play the scores if they don't exist. There's
a slightly higher chance if they do. I personally have no plans
to shop music to musicians in the immediate future, but I've done
it in the past and may do again. But at least one of the people
on the mailing list is a professional microtonal composer that
expects his notation to go in front of artists.

2. But even more important is the value of notation as a
language for music. If you think a multitrack recorder is as
good a medium for composing as a sheet of paper, then you won't
see the value. But I think languages empower content, and I
think even the very best genres to operate without notation
(bebop and progressive rock to my taste) lack something that
the classical masterpieces have.

>But something that can actually push some microtonal through with
>more than that same mind numbing MIDI string sound, now you're
>talking.

Well you don't need a notation editor for that. You just need
any one of the two dozen excellent microtonal synth that are
currently available, ranging in price from free to very expensive.

>Seems to me that Scala is 90% of the way there, doesn't seem
>impossible to add that extra 10% to something Scala-like to get what
>you're talking about.

Scala is a fantastic piece of software, but I don't think it's
more than 5% of what Mike is after.

-Carl

🔗Mike Battaglia <battaglia01@...>

🔗Robin Perry <jinto83@...>

Mike, Count me in as a customer for a program of this description.

--- In MakeMicroMusic@yahoogroups.com, "Mike Battaglia"
<battaglia01@...> wrote:
>
> (Cross-posted to MMM and MicroTools)
>
> Besides the score editor we're currently working on, there was once
> talk of creating a full-fledged cross-platform production environment,
> something like a DAW. Something that might have a track view, a piano
> roll, VST support, possibly a mixer or console view, etc., all with
> microtonal features build in under the hood. Something in which you
> can route to different MIDI devices and use different VST synths and
> such. A microtonal Rosegarden, or Logic, or SONAR, or anything like
> that, if you will. The focus wouldn't be so much on making the score
> pretty for printing (although that might be nice), but on making it
> easy to produce microtonal works in terms of the actual sound of the
> end result wise. A production environment, if you will. There is going
> to be a very, very strong emphasis on making this software easy to
> use, so that those of us who are less computer-literate can still jump
> into writing microtonal music.
>
> I do envision it having a very robust notation and staff view, a lot
> of which I want to "borrow" from the score editor we're working on
> (and possibly even design the score editor with that kind of
> portability in mind from the getgo). I want to have the notes in the
> staff view look like 72-tet or JI or whatever tuning or notation
> system it is you're using, and then translate all of that behind the
> scenes into MIDI/MTS/Scala, or pitch bent/channel swapped MIDI, or
> OSC, or whatever else. Things that are extremely difficult to
> implement or extraneous to this specific goal, such as audio support
> or a CSound GUI or anything even resembling a synth engine are not an
> immediate priority for this program, but would be future
> considerations later if we can get this off the ground first. In other
> words, let's just make it a MIDI sequencer with some fancy views at
> first.
>
> So to the people on this forum: does this sound like something that
> you would be interested in having? Does it sound like having
> everything rounded together in a package like this would make
> production easier for you? Many of the microtonal works that I've
> heard are extremely interesting, but simply run through some sort of
> GM-sounding synth, and so I thought that having a production
> environment like this might make it easier for people to focus on the
> production side of creating music. I also thought it might make it
> easier for people who are musicians and composers first and foremost
> to jump right into this kind of stuff without having to learn how to
> use multiple pieces of software and connect them all.
>
> I've spoken to a few of you off-list, so I know there is at least some
> demand for it. If there is enough demand, I'll kick this off as a
> project in its own right alongside the score editor. It's a pretty big
> goal and could take some time to complete, but there is a huge wealth
> of talent on these lists, so I am pretty optimistic.
>
> Most importantly, this could determine the design route for a few
> different projects. I've also been throwing around the idea of first
> creating some general purpose toolkits before jumping into either one
> of these programs. I like this approach even just on the merit that it
> will make microtonal software development in the future much easier
> for whoever has the next big idea. A few people on the score editor
> team think that it'll be too much work to go that route.
>
> However, if there is going to be a score editor and a production
> environment, both projects might move along more quickly if we code
> together on architectures that will be common to both projects. So we
> might end up with some toolkits just out of necessity. For example, it
> makes sense to code the notation GUI in this way, or else we're going
> to have the people from the score editor working on their GUI, and the
> people from the production environment working on another GUI, which
> is just wasted time for everyone. It also determines whether it's
> necessary to come up with some kind of universal Microtonal Event
> List, as AKJ suggested, and to what extent the programs will be able
> to communicate with one another.
>
> Carl has requested that I actually go write some wireframe diagrams
> and go into how I think the production environment should work and
> how, if at all, it overlaps with the score editor. Before I actually
> take the time to do that, though, I want to see if there is any sort
> of interest for it. So speak up! We need to hear some feedback right
> now. And if you'd be interested in helping to code such a project, any
> little bit of effort would certainly help move things along real, real
> nice-like.
>
> -Mike
>

🔗Mike Battaglia <battaglia01@...>

🔗Jon Szanto <jszanto@...>

🔗Carl Lumma <carl@...>

🔗Jon Szanto <jszanto@...>

🔗Carl Lumma <carl@...>

🔗Pete McRae <professorsidewinder@...>

Howdy, all,

Of course, a ready-to-run recording package with
easily programmed microtonal, high-resolution JI,
octaves up to a jillion EDO, or nonoctave whatevers,
all the pi and phi and golden generators etc., with
audiophile/pro-audio sound quality would be fantastic!

I think the idea of using a notation system based on
common-practice period music is great, if all you want
to do retune common-practice period music, or its
ancestors and descendants. To think you might win
converts from good sight-readers out there is a bit
ridiculous in my opinion, because it's like asking a
race-car driver to fly a fighter jet, and calling it a
"casual gig". Hee! The Chromelodeon solution was
brilliant, but isn't that kind of like encouraging
your secretary to listen to an audiobook to keep him
amused while he types your manuscript? You know what I
mean? I thought I read somewhere that Chromelodeon
notation was cruel to someone who's, like, a brilliant
sight reader with perfect pitch, and it's probably
true, ...anyway...

I guess things are changing some for the better in
that regard, because common-practice period music and
its derivatives probably ARE dying out, so there may
be fewer situations where asking a musician to play
music in other than a general sort of twelve-equal
intervallic construction no longer amounts to a
calling out, or a declaration of war, but it has been,
and still is, in some areas.

BUT I think a completely new notation scheme is in
order, leave common-practice where it belongs: in a
museum. Hee! Sorry, I love Bach and Ravel, too! But a
Bosanquet or a qwerty kind of system seems a lot more
promising and practicable to me. But then I guess
there would have to be an eminently PLAYABLE (as in
feels good, responds to musical coaxing) keyboard in
every parlor for about 200 years for THAT to work, eh?
Sorry, again. And 100 years of great literature for
parlor musicians who respect that keyboard, too, eh?

Still, I really hate (so to speak) the idea of bowing
to historical pressure, when it's clear that something
really new is really needed.

The short answer is, YO YO YO I'm all for it!

Cheers,

Pete

--- Robin Perry <jinto83@...> wrote:

> Mike, Count me in as a customer for a program of
> this description.
>
>
>

🔗Carl Lumma <carl@...>

Pete -- the idea is that the editor will support many
different kinds of notation. We're currently taking
requests. Here's what we have so far:

http://groups.google.com/group/microtools/web/types-of-notation

-Carl

--- In MakeMicroMusic@yahoogroups.com, Pete McRae
<professorsidewinder@...> wrote:
>
> Howdy, all,
>
> Of course, a ready-to-run recording package with
> easily programmed microtonal, high-resolution JI,
> octaves up to a jillion EDO, or nonoctave whatevers,
> all the pi and phi and golden generators etc., with
> audiophile/pro-audio sound quality would be fantastic!
>
>
> I think the idea of using a notation system based on
> common-practice period music is great, if all you want
> to do retune common-practice period music, or its
> ancestors and descendants. To think you might win
> converts from good sight-readers out there is a bit
> ridiculous in my opinion, because it's like asking a
> race-car driver to fly a fighter jet, and calling it a
> "casual gig". Hee! The Chromelodeon solution was
> brilliant, but isn't that kind of like encouraging
> your secretary to listen to an audiobook to keep him
> amused while he types your manuscript? You know what I
> mean? I thought I read somewhere that Chromelodeon
> notation was cruel to someone who's, like, a brilliant
> sight reader with perfect pitch, and it's probably
> true, ...anyway...
>
> I guess things are changing some for the better in
> that regard, because common-practice period music and
> its derivatives probably ARE dying out, so there may
> be fewer situations where asking a musician to play
> music in other than a general sort of twelve-equal
> intervallic construction no longer amounts to a
> calling out, or a declaration of war, but it has been,
> and still is, in some areas.
>
> BUT I think a completely new notation scheme is in
> order, leave common-practice where it belongs: in a
> museum. Hee! Sorry, I love Bach and Ravel, too! But a
> Bosanquet or a qwerty kind of system seems a lot more
> promising and practicable to me. But then I guess
> there would have to be an eminently PLAYABLE (as in
> feels good, responds to musical coaxing) keyboard in
> every parlor for about 200 years for THAT to work, eh?
> Sorry, again. And 100 years of great literature for
> parlor musicians who respect that keyboard, too, eh?
>
> Still, I really hate (so to speak) the idea of bowing
> to historical pressure, when it's clear that something
> really new is really needed.
>
> The short answer is, YO YO YO I'm all for it!
>
> Cheers,
>
> Pete

🔗Pete McRae <professorsidewinder@...>

Dig. Thanks for pointing me over there. I guess if I'm
gonna grump about it, I might see about applying
myself to what I would imagine would be more fun to
read ;-). Hope so. I think it might have something to
do with focusing on streamling for subsets, like "key
signatures", but that's just offhand. And the rhythm
problem is more truly daunting...the remark about
quantized/non-quantized 'quanta' was pretty good, you
know, the machine that'll play it like you _meant_ to
play it, hee! And line everything else up with it,
too...(smile)

And, yo, I want to know *why* -when I go to
Process/Audio/Quantize- there isn't an ->Elvin Jones
button?

I notice even Erv, who may be the greatest tonal
adventurer I've run across, expressed great "comfort"
with traditional staff, and still seemed a bit
constrained by its overwhelming...familiarity. Like I
said, time for me to put my brainstorm gear on, if I'm
gonna squeak over it.

--- Carl Lumma <carl@...> wrote:

> Pete -- the idea is that the editor will support
> many
> different kinds of notation. We're currently taking
> requests. Here's what we have so far:
>
>
http://groups.google.com/group/microtools/web/types-of-notation
>
> -Carl
>
> --- In MakeMicroMusic@yahoogroups.com, Pete McRae
> <professorsidewinder@...> wrote:
> >
> > Howdy, all,
> >
> > Of course, a ready-to-run recording package with
> > easily programmed microtonal, high-resolution JI,
> > octaves up to a jillion EDO, or nonoctave
> whatevers,
> > all the pi and phi and golden generators etc.,
> with
> > audiophile/pro-audio sound quality would be
> fantastic!
> >
> >
> > I think the idea of using a notation system based
> on
> > common-practice period music is great, if all you
> want
> > to do retune common-practice period music, or its
> > ancestors and descendants. To think you might win
> > converts from good sight-readers out there is a
> bit
> > ridiculous in my opinion, because it's like asking
> a
> > race-car driver to fly a fighter jet, and calling
> it a
> > "casual gig". Hee! The Chromelodeon solution was
> > brilliant, but isn't that kind of like encouraging
> > your secretary to listen to an audiobook to keep
> him
> > amused while he types your manuscript? You know
> what I
> > mean? I thought I read somewhere that Chromelodeon
> > notation was cruel to someone who's, like, a
> brilliant
> > sight reader with perfect pitch, and it's probably
> > true, ...anyway...
> >
> > I guess things are changing some for the better in
> > that regard, because common-practice period music
> and
> > its derivatives probably ARE dying out, so there
> may
> > be fewer situations where asking a musician to
> play
> > music in other than a general sort of twelve-equal
> > intervallic construction no longer amounts to a
> > calling out, or a declaration of war, but it has
> been,
> > and still is, in some areas.
> >
> > BUT I think a completely new notation scheme is in
> > order, leave common-practice where it belongs: in
> a
> > museum. Hee! Sorry, I love Bach and Ravel, too!
> But a
> > Bosanquet or a qwerty kind of system seems a lot
> more
> > promising and practicable to me. But then I guess
> > there would have to be an eminently PLAYABLE (as
> in
> > feels good, responds to musical coaxing) keyboard
> in
> > every parlor for about 200 years for THAT to work,
> eh?
> > Sorry, again. And 100 years of great literature
> for
> > parlor musicians who respect that keyboard, too,
> eh?
> >
> > Still, I really hate (so to speak) the idea of
> bowing
> > to historical pressure, when it's clear that
> something
> > really new is really needed.
> >
> > The short answer is, YO YO YO I'm all for it!
> >
> > Cheers,
> >
> > Pete
>
>
>
>

🔗Mike Battaglia <battaglia01@...>

On Thu, Jul 10, 2008 at 4:20 PM, Jon Szanto <jszanto@...> wrote:
> --- In MakeMicroMusic@yahoogroups.com, "Mike Battaglia"
> <battaglia01@...> wrote:
>>
>> Robin: You know, I am a bit curious, what do you use now to accomplish
>> all of this?
>
> I know you didn't ask me, but I use Sonar in conjunction with VSTi
> that are microtunable via .scl or .tun files (all of these I generate
> with Scala). I might leave some out, but the ones that come to mind are:
>
> Wusikstation
> Rhino
> Cronos
> z3ta+
> Albino
> Rapture
>
> ... and some custom sample sets that I've retuned in various ways.
>
> I'm hoping to use the Garritan Personal Orchestra that I have when the
> Kompakt player finally (as they've said for a long time) incorporates
> the microtuning features built into Kontakt.

Kompakt's getting all of that together? Man, that'd be awesome.
EastWest right now uses Kontakt, and if you use GPO, you oughta check
out EastWest... really.

VSL is the best out of all of them, but it's $10000 and 550 GB
large... Overkill.

-Mike

🔗Pete McRae <professorsidewinder@...>

🔗Carl Lumma <carl@...>

🔗anklesjuggle07 <anklesjuggle07@...>

🔗Jon Szanto <jszanto@...>

🔗Mike Battaglia <battaglia01@...>

🔗Jon Szanto <jszanto@...>

🔗Graham Breed <gbreed@...>

Mike Battaglia wrote:
>> It's nice for Mike to canvas for his rival project but we
>> still haven't fixed the requirements for the original one.
>> I've copied some use cases I proposed below. You (and
>> anybody else) can vote on whether you're interested in them.
> > Again, Graham, it isn't not really supposed to be much of a "rival"
> project. I probably spent an hour responding to your post earlier and
> detailing my ideas about how best to organize even just the first
> project. Specifically the approach where we make this toolkit. This is
> probably the fifth time I've written to you about the toolkit idea
> specifically and I still have gotten zero feedback from you on the
> idea. Clearly this is important enough that I keep mentioning it, it
> would be nice to hear what you think about it rather than you to keep
> telling me about "stop focusing on the DAW", which ISN'T THE POINT OF
> THE TOOLKIT. Thank you.

If you're dividing your attention between two projects then they're certainly rivals. And if you're trying to get me to comment on your other project it's a clear rival for my attention. I say no.

Graham

🔗Mike Battaglia <battaglia01@...>

>> Again, Graham, it isn't not really supposed to be much of a "rival"
>> project. I probably spent an hour responding to your post earlier and
>> detailing my ideas about how best to organize even just the first
>> project. Specifically the approach where we make this toolkit. This is
>> probably the fifth time I've written to you about the toolkit idea
>> specifically and I still have gotten zero feedback from you on the
>> idea. Clearly this is important enough that I keep mentioning it, it
>> would be nice to hear what you think about it rather than you to keep
>> telling me about "stop focusing on the DAW", which ISN'T THE POINT OF
>> THE TOOLKIT. Thank you.
>
> If you're dividing your attention between two projects then
> they're certainly rivals. And if you're trying to get me to
> comment on your other project it's a clear rival for my
> attention. I say no.

At this point, which is probably the 8th time I've addressed my idea
about incorporating the toolkit and libraries approach into the score
editor from the outset, I'm either going to assume you are either a)
not reading my posts or b) ignoring my posts. Specifically the fact
that I made it a point to say this, in all caps:

>> it would be nice to hear what you think about it rather than you to keep
>> telling me about "stop focusing on the DAW", which ISN'T THE POINT OF
>> THE TOOLKIT. Thank you.

And then your responding with this:

> And if you're trying to get me to
> comment on your other project it's a clear rival for my
> attention. I say no.

Boggles my mind. I'd love to work with you on a score editor and other
future projects, but if your communications with me involve using 3%
of your overall brain capacity, it probably won't work.

If you disagree with the approach that both groups should work
together to code general-purpose libraries that will be beneficial to
both and future projects, then that's fine. As it stands, I haven't
heard anything from you that even indicates you understand my idea,
and I've tried only like a thousand times to get some feedback on it.

If you don't understand what I'm saying, I'd be happy to clarify
further. But if you insist on taking your first misconception of my
post and then dismissing offhand all of the future comments where I
correct you, then your approach sucks. It screws up the mechanics of
the group, and I expect it isn't going to really work well off in the
long run. If you want the score editor to be your and Carl's project,
then that's fine, but let's not keep pretending otherwise.

-Mike

🔗Robin Perry <jinto83@...>

Hi Mike,

Other than Sibelius for composing in 12=, I'm not using anything.
I've attempted to use Scala and FTS to bend my Sib files without
success. (Not blaming either program, mind you. I'm just an ijit.)
I'm looking for a Sibelius or Finale-like bit of software that'll do
all of that sorting out of pitches and channels for me. I do
appreciate the bells and whistles in a program. Anything that frees
up my time is good stuff. Good luck!

Robin

--- In MakeMicroMusic@yahoogroups.com, "Mike Battaglia"
<battaglia01@...> wrote:
>
> Robin: You know, I am a bit curious, what do you use now to accomplish
> all of this? Do you use scala files to retune the MIDI stream, or
> pitch bending and channel swapping, or Csound/osc, or what? I'm trying
> to figure out all of the different ways people accomplish this now,
> hopefully to round them up in one environment in the future.
>
> I can't promise that this will make it any easier to use archaic
> synths microtonally, but at least it might make a consistent work
> flow, you know what I mean? Just an IDE for microtonal music.
>
> -Mike
>

🔗Kraig Grady <kraiggrady@...>

🔗Pete McRae <professorsidewinder@...>

But which one will top the Billboard charts?

Terry Bozzio?

Or Paul Leim?

;-(

Andrew Cyrille?

I saw him for the first time just a few months ago.
Blew my mind.

--- Kraig Grady <kraiggrady@...> wrote:

> i prophetized that in the future there will be DNA
> chips where one will
> be able to access the likes of such. Right now i
> need a more chaotic
> drummer, ah here we go
> the Tony W. chip
> should do it!
>
>
>
> /^_,',',',_ //^ /Kraig Grady_ ^_,',',',_
> Mesotonal Music from:
> _'''''''_ ^North/Western Hemisphere:
> North American Embassy of Anaphoria Island
> <http://anaphoria.com/>
>
> _'''''''_ ^South/Eastern Hemisphere:
> Austronesian Outpost of Anaphoria
> <http://anaphoriasouth.blogspot.com/>
>
>
',',',',',',',',',',',',',',',',',',',',',',',',',',',',',
>
>
>
>
> Mike Battaglia wrote:
> >
> > On Thu, Jul 10, 2008 at 9:11 PM, Pete McRae
> > <professorsidewinder@...
> > <mailto:professorsidewinder%40yahoo.com>> wrote:
> > > And, yo, I want to know *why* -when I go to
> > > Process/Audio/Quantize- there isn't an ->Elvin
> Jones
> > > button?
> >
> > Haha, whoa, a jazz reference on MMM? Am I losing
> my mind here?
> >
> > -Mike
> >
> >
>

🔗Prent Rodgers <prentrodgers@...>

Mike wrote:

--- In MakeMicroMusic@yahoogroups.com, "Mike Battaglia"
<battaglia01@...> wrote:
> Let me try to make it as
> precise as possible:
>
> For version 1.0, I just want to make a simple sequencer that is based
> on the principle that the internal events list shouldn't be rooted in
> MIDI. The internal events list will be able to be translated into MIDI
> or OSC or anything. This means that microtonal stuff will be easy to
> implement because we're going to create the data model ourselves, the
> same as the score editor group is doing. I want the internal events
> list to be able to be parsed with any one of a number of different
> "views", and for version 1.0, I'd be happy with nothing but a track
> view and a notation view and perhaps a piano roll. It sounds like the
> same thing as the score editor, but under the hood, it's not, but not
> too much harder to tackle. At first perhaps we'll only have OSC
> support, or only MIDI with MTS support.
>

My thoughts on this. I use Csound, with a front end I wrote a long
time ago, that has an internal data structure that meets my current
needs. I have channels, and channels have notes. If you are going to
create a data structure, here's one that works for me.

These are all vital to humanize a sound. Fake but accurate is my
model. Imagine a musician playing the instrument who had the ability
to hit any pitch, move it anywhere, and control the amplitude after it
began. Too much synthesizer music sounds like someone playing a keyboard.

Here's my data structure. It's in Pascal, of course. Doesn't everyone
use Pascal today?

AudNoteType = Record
Octave: Byte; { What octave is the note? 0..11 }
ToneInScale: Byte; { What note in the scale? 0..some reasonable
maximum - you can have a table of possible values elsewhere. I have a
table of 53 TET, another of Partch 43. Let the composer choose. Mine
all have octave repetitions. Some won't like that. }
Velocity: Byte; { How Loud? 0..127}
Rand: Byte; { Random chance that note will play 0 - 16. This is one
of my favorites. Why insist that a note always sounds? Make it
optional sometimes. }
Stereo: Byte; { Stereo Pan from 0 left to 15 right. Where is the
note in the sound field? }
Perturb: Byte; { Make the note start a few milliseconds early or
late, your choice. If it's 0 is no change, 10 is plus or minus 10
milliseconds of the expected start time }
Glisand: Byte; { 0 is flat, 1-100 are 1024 element tables with sets
of values. This is useful for glissandos that move up at different
speed, may have vibrato when they reach a destination, or start
without and add vibrato as the note progresses }
Upsample: Byte; { Allow for munchkinization under program control.
In other words, instead of picking the right sample, pick one that
makes the sound a bit more biting or mellow than intended }
Envelope: Byte; { Pick an Envelope Function Table. Premade tables
with envelopes. When the envelope is the same for all the notes, it
starts to sound like someone on a keyboard playing a synthesizer. Ugh.
Pick from a few dozen envelopes, including some that start soft and
grow, others that die quickly, and some that shrink and grow over time. }
Duration: Integer; { How long until the next note in the channel?
0..32767 }
HoldDuration: Integer; { How long does it sound? A combination of 0
duration and long holdDuration permits chords in a single channel
0..32767 }
WarEnvelope: Byte; { Second envelope for the other stereo channel
0..100 }
end;

Each channel is one instrument, with the ability to play multiple
notes in any intonation system. Ideally, your program should support a
fair number of them. I max out at 20 or so. The channel has the
ability to add crescendo and decrescendo and a few other things to
override these values.

Prent Rodgers