Yahoo Tuning Groups Ultimate Backup makemicromusic New microabc software (31-12-2007)

Hello people,

A new version of microabc, a software for microtonal music, was released:

Direct download of the newest version:
http://br.geocities.com/hfmlacerda/abc/microabc.zip
Description:
http://br.geocities.com/hfmlacerda/abc/microabc-about.html
http://br.geocities.com/hfmlacerda/abc/microabc.html
Index of commands:
http://br.geocities.com/hfmlacerda/abc/microabc.html#indice
History of changes:
http://br.geocities.com/hfmlacerda/abc/microabc-Changes.txt

It contains several new features, like:

[0] Revised and amplied tutorial (subfolder tutorial/tutorial.pdf),
with hyperlinks. Included in the package, and also available online:
http://br.geocities.com/hfmlacerda/abc/microabc-tutorial.pdf

[1] Easier to use (for beginners):

- Don't require the program abcpp. microabc includes a specialised
preprocessor.

- Sagittal font is embedded in the program (flag -e), so it is not
required install the *.pfb font or the abcm2ps *.fmt files.

- Flag -E makes simpler the command lines (it is equivalent to the
combination of: -S -e -i- -oEasyFile.abp). It also does without
installing the Sagittal *.pfb font and the abcm2ps *.fmt files.
Example:
microabc -E -Pmusic.abp
abcm2ps EasyFile.abc -O music.ps
microabc -E -Mmusic.abp
abc2midi EasyFile.abc -o music.mid

[2] Conditional instructions blocks (still experimental):
FOR_PS:BEGIN
{instructions for PS (-P)}
FOR_PS:END
FOR_MIDI:BEGIN
{instructions for MIDI (-M)}
FOR_MIDI:END

[3] Auto generation of test file (testfile.abp), to hear/view the scale.

Happy new year!
Hudson Lacerda

P.S.:
If someone is able to compile binaries for any non-GNU system, please
do it, and tell me: send a message to this e-mail:
hfml @ brfree dot com dot br
Thanks,
Hudson

🔗Aaron Andrew Hunt <aaronhunt@...>

Dear Hudson,

Thanks for your work on this. The new tutorial is very nice,
and it all really sounds great. I think what keeps most
people from using it is the lack of package and a simple
front-end to generate scripts, but I think I read once
Prent Rogers has done some work on that. Is that right?
Seems like it could all be done with simple text
processing and file manipulation.

Thanks,
Aaron Hunt
H-Pi Instruments

--- In MakeMicroMusic@yahoogroups.com, "hfmlacerda" <hfmlacerda@...> wrote:
>
> Hello people,
>
> A new version of microabc, a software for microtonal music, was released:
>
> Direct download of the newest version:
> http://br.geocities.com/hfmlacerda/abc/microabc.zip
> Description:
> http://br.geocities.com/hfmlacerda/abc/microabc-about.html
> http://br.geocities.com/hfmlacerda/abc/microabc.html
> Index of commands:
> http://br.geocities.com/hfmlacerda/abc/microabc.html#indice
> History of changes:
> http://br.geocities.com/hfmlacerda/abc/microabc-Changes.txt
>
> It contains several new features, like:
>
> [0] Revised and amplied tutorial (subfolder tutorial/tutorial.pdf),
> with hyperlinks. Included in the package, and also available online:
> http://br.geocities.com/hfmlacerda/abc/microabc-tutorial.pdf
>
> [1] Easier to use (for beginners):
>
> - Don't require the program abcpp. microabc includes a specialised
> preprocessor.
>
> - Sagittal font is embedded in the program (flag -e), so it is not
> required install the *.pfb font or the abcm2ps *.fmt files.
>
> - Flag -E makes simpler the command lines (it is equivalent to the
> combination of: -S -e -i- -oEasyFile.abp). It also does without
> installing the Sagittal *.pfb font and the abcm2ps *.fmt files.
> Example:
> microabc -E -Pmusic.abp
> abcm2ps EasyFile.abc -O music.ps
> microabc -E -Mmusic.abp
> abc2midi EasyFile.abc -o music.mid
>
> [2] Conditional instructions blocks (still experimental):
> FOR_PS:BEGIN
> {instructions for PS (-P)}
> FOR_PS:END
> FOR_MIDI:BEGIN
> {instructions for MIDI (-M)}
> FOR_MIDI:END
>
> [3] Auto generation of test file (testfile.abp), to hear/view the scale.
>
> Happy new year!
> Hudson Lacerda
>
> P.S.:
> If someone is able to compile binaries for any non-GNU system, please
> do it, and tell me: send a message to this e-mail:
> hfml @ brfree dot com dot br
> Thanks,
> Hudson
>
>
>
>
>
>
>
>
>
>
> .
>

🔗hfmlacerda <hfmlacerda@...>

--- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
<aaronhunt@...> wrote:
>
> Dear Hudson,
>
> Thanks for your work on this. The new tutorial is very nice,
> and it all really sounds great.

Dear Aaron,

Many thanks for your feedback.

> I think what keeps most
> people from using it is the lack of package

It would be easy to include a Makefile to compile and install the
executable files (microabc and abc2alias) into /usr/local/bin or
/usr/share/bin, but I don't know to install the Sagittal PS font in a
compatible way. For example, the new version of ghostscript (in
Debian) changed the place where fonts are declared.

Another related issue is the installation of the auxiliary tools
(install abcm2ps, abc2midi, abcpp; suggest timidity++). That would be
an interesting thing to do with *.deb or *.rpm packages.

It would be very nice have binaries for other systems than GNU+Linux,
but I have no way to compile them.

Maybe some day I try to do a FreeDOS 16bit version, but that would
probably require drastic reduction of the size of static buffers that
microabc uses currently. I have tried to compile microabc with gcc on
FreeDOS, but the executables did not work.

> and a simple
> front-end to generate scripts,
> but I think I read once
> Prent Rogers has done some work on that. Is that right?

AFAIK, Prent Rogers wrote scripts for Csound and LilyPond, using for
notation only the traditional quarter-tone accidentals.

microabc is for ABC notation, which also supports quarter-tone
notation. But with microabc extensions, one can use also an
eighth-tone notation and all Sagittal accidentals (except Sagittal
accents).

> Seems like it could all be done with simple text
> processing and file manipulation.

I am not certain of what you mean with ``front-end to generate
scripts'', but I am going to think about put the current 53 microabc
commands on a tcl-tk window (just like I did in tkdnoise [0] and tk+-
[1])... I am not yet convinced of the advantages (at least it would
make easy learning/using the commands), but anyway people might like
to use such a front-end.

[0]
http://br.geocities.com/hfmlacerda/misc/tkdnoise.zip
[1] http://geocities.yahoo.com.br/hfmlacerda/misc/maisoumenos-0.0.4.zip

Thank your again for your helpful comments.

Cheers,
Hudson Lacerda

🔗Prent Rodgers <prentrodgers@...>

🔗hfmlacerda <hfmlacerda@...>

--- In MakeMicroMusic@yahoogroups.com, "Prent Rodgers"
<prentrodgers@...> wrote:
>
> Hudson, Aaron,
>
> My front end to Csound generated Lilypond input. But I never was able
> to integrate Sagittal font support into Lilypond. I was over my head,
> software-wise.
>
> I'd love to try to generate ABC input, since the Sagittal support is
> there. Basically, my program has a data structure of notes, with their
> times, durations, and other characteristics. When the preprocessor is
> done, it creates a flat file that Csound and Lilypond understand. I
> could create one for ABC if I knew the input format and put the work
> into it.

Hi Prent,

A good reference to learn ABC is:
http://abcplus.sourceforge.net/#ABCGuide

Compared to LilyPond, ABC is more restrictive, mainly for rhythm. The
durations need to be written measure by measure as they read on score,
and there is no support for durations that cross bar lines or like. In
its turn, LilyPond can break down strange/complex durations into valid
(tied) figures.

If you want just write scores with ABC, use the Sagittal character
code in the accidental: ^/196A is A#, _/134E is E\, etc. ; and
instruct abcm2ps to load sagittal.fmt or sagittal-pfb.fmt. This case,
microabc is not required, but the ABC cannot be converted to MIDI,
only to PS.

However, you could use Sagittal macros for microabc ([A#], [E\] etc.);
that allows converting the ABP (ABC Before Processing) file to both PS
and MIDI.

There are some additional issues (like key signatures and hidden
accidentals), but we can broach them in their time.

The microtonal support in ABC uses extensions which are specific to
abcm2ps and abc2midi. To understand how the things work, it is
recommended to read the documentation of both programs (in special
abcm2ps*/features.txt and abcmidi/doc/abcguide.txt).

Some links:

http://abcplus.sourceforge.net/
http://abcplus.sourceforge.net/#abctools

http://abcplus.sourceforge.net/#abcMIDI
http://ifdo.pugmarks.com/%7Eseymour/runabc/top.html

http://abcplus.sourceforge.net/#abcm2ps
http://moinejf.free.fr/
http://br.geocities.com/hfmlacerda/abc/format.html
http://br.geocities.com/hfmlacerda/abc/abcm2ps-html-en.zip

🔗hfmlacerda <hfmlacerda@...>

Hello all,

Good news:

I managed to compile a DOS version of microabc, using gcc4dos on a
FreeDOS operating system (running inside qemu on Debian GNU+Linux). It
is based on microabc-2007-12-31, with slight (but important) changes.

microabc.exe seems to be working fine, but I did not test it in any
systematic ways.

Here on my computer it worked on the FreeDOS 1.0 operating system
(inside qemu), and also inside DOSBOX (running on a GNU+Linux
operating system).

The only problem I found is that the program doesn't stop with actions
like Ctrl-D, Ctrl-X or Ctrl-C; for example, when reading input from
the keyboard. But this may be just a limitation (or perhaps a
``feature'') of the emulators I used (dosbox, qemu)... Later I may
boot FreeDOS (without hardware emulation) to check this. However there
is no problem if the users don't miss the flag -i (or -E).

The program cwsdpmi.exe is required by both FreeDOS and DOSBOX. I
don't know if cwsdpmi.exe is also required on Windows. The package
csdpmi4b.zip, which provides the program, is included.

I compiled also abc2alias, but the binary was named abcalias.exe
(without the '2') in order to fit in the DOS file-name length.

I will compile and include .EXE files in further releases of microabc.

-----------------

Here are the microabc binaries:
http://br.geocities.com/hfmlacerda/abc/muAbcDOS.zip
Here are other required ABC binaries for Windows:
http://abcplus.sourceforge.net/#abctools
I would suggest you to use the stable version of abcm2ps:
http://abcplus.sourceforge.net/abcm2ps-4.12.30-win32.zip

To install the .EXE programs, follow the Guido Gonzato's instruction:
<<<
Extract them and copy them to C:\Windows (Windows 9x/XP) or C:\Winnt
(Windows 2000).
>>>

Download also the microabc package. It contains the documentation, the
Sagittal font, the format files for abcm2ps, and several examples:
http://br.geocities.com/hfmlacerda/abc/microabc.zip

And, if you are new to ABC, this is a good guide:
http://abcplus.sourceforge.net/#ABCGuide
http://abcplus.sourceforge.net/abcplus_en-1.1.0.zip

If you still don't have a program to view PostScript files, install
GhostScript (first) and (then) GSView:
http://mirror.cs.wisc.edu/pub/mirrors/ghost/GPL/gs860/gs860w32.exe
http://mirror.cs.wisc.edu/pub/mirrors/ghost/ghostgum/gsv49w32.exe
A small-sized, also gratis (but non-free -- argh!!!) and limited
alternative might be:
http://www.rops.org/download/freescript53.exe

...waiting for your feedback... :-)
Hudson Lacerda
http://br.geocities.com/hfmlacerda/abc/microabc-about.html

P.S.: I am planning a GUI front-end to control the command-line
programs, as suggested by Aaron Hunt. It will be a tcl-tk script.

🔗Aaron Andrew Hunt <aaronhunt@...>

Dear Hudson (and Prent),

I am always amazed when such tremendous effort goes into
the creation of tools and ways to get microtonal music to
happen, especially when there is so much low-level work
being done. You guys have my utmost respect for your
expertise using computers in these amazing ways.

When I make a naive comment like I did about a front-end,
as a programmer I come from the other side of the universe,
in a way. Comments I make about programming usually drive
real programmers bonkers, because I have only done high-
level programming myself and have never had the inclination
or patience to get into low-level work. I design programs
starting with a GUI in an environment which hides all the
low-level work from me. And I also hide everything I
possibly can from the user, to make it all as point and click
as possible. Working this way has its trade-offs, such as
unnecessarily bulky programs, but the result is basically a
point and click multi-platform package.

It appears to be a problem with all the Linux open-source etc.
projects (which can be amazing in terms of what they
accomplish) that they don't work easily. Most people expect
drag and drop, point and click, plug and play stuff, and
relatively few folks will want to take the time to do anything
else. I guess on Windows everyone still expects an installer,
but on Mac everyone expects one-step installation. Personally,
anytime I have tried to install something that requires
putting many things in many places, and configuring some
of them, I _never_ have success. I think first most people will
never even try something like that and if they do they
probably have an experience like mine, and so most people
never try anything that is being done this way; there just
isn't time and patience enough to go around.

But in no way do I want to be discouraging. On the contrary,
I just want to see software that is packaged and works
without the user having to worry about _any_ low-level tasks.
That has become a practical requirement for me from software
that I use, and it is what I want to accomplish in the software
that I write. I try, anyway.

I applaud your work and I'm sure it will continue to become
more streamlined in future releases. Maybe something I said
is useful. If not, please just ignore it and keep working your
own way!

Yours,
Aaron Hunt
H-Pi Instruments

--- In MakeMicroMusic@yahoogroups.com, "hfmlacerda" <hfmlacerda@...> wrote:
>
> Hello all,
>
> Good news:
>
> I managed to compile a DOS version of microabc, using gcc4dos on a
> FreeDOS operating system (running inside qemu on Debian GNU+Linux). It
> is based on microabc-2007-12-31, with slight (but important) changes.
>
> microabc.exe seems to be working fine, but I did not test it in any
> systematic ways.
>
> Here on my computer it worked on the FreeDOS 1.0 operating system
> (inside qemu), and also inside DOSBOX (running on a GNU+Linux
> operating system).
>
> The only problem I found is that the program doesn't stop with actions
> like Ctrl-D, Ctrl-X or Ctrl-C; for example, when reading input from
> the keyboard. But this may be just a limitation (or perhaps a
> ``feature'') of the emulators I used (dosbox, qemu)... Later I may
> boot FreeDOS (without hardware emulation) to check this. However there
> is no problem if the users don't miss the flag -i (or -E).
>
> The program cwsdpmi.exe is required by both FreeDOS and DOSBOX. I
> don't know if cwsdpmi.exe is also required on Windows. The package
> csdpmi4b.zip, which provides the program, is included.
>
> I compiled also abc2alias, but the binary was named abcalias.exe
> (without the '2') in order to fit in the DOS file-name length.
>
> I will compile and include .EXE files in further releases of microabc.
>
> -----------------
>
> Here are the microabc binaries:
> http://br.geocities.com/hfmlacerda/abc/muAbcDOS.zip
> Here are other required ABC binaries for Windows:
> http://abcplus.sourceforge.net/#abctools
> I would suggest you to use the stable version of abcm2ps:
> http://abcplus.sourceforge.net/abcm2ps-4.12.30-win32.zip
>
> To install the .EXE programs, follow the Guido Gonzato's instruction:
> <<<
> Extract them and copy them to C:\Windows (Windows 9x/XP) or C:\Winnt
> (Windows 2000).
> >>>
>
> Download also the microabc package. It contains the documentation, the
> Sagittal font, the format files for abcm2ps, and several examples:
> http://br.geocities.com/hfmlacerda/abc/microabc.zip
>
> And, if you are new to ABC, this is a good guide:
> http://abcplus.sourceforge.net/#ABCGuide
> http://abcplus.sourceforge.net/abcplus_en-1.1.0.zip
>
> If you still don't have a program to view PostScript files, install
> GhostScript (first) and (then) GSView:
> http://mirror.cs.wisc.edu/pub/mirrors/ghost/GPL/gs860/gs860w32.exe
> http://mirror.cs.wisc.edu/pub/mirrors/ghost/ghostgum/gsv49w32.exe
> A small-sized, also gratis (but non-free -- argh!!!) and limited
> alternative might be:
> http://www.rops.org/download/freescript53.exe
>
>
>
> ...waiting for your feedback... :-)
> Hudson Lacerda
> http://br.geocities.com/hfmlacerda/abc/microabc-about.html
>
>
>
> P.S.: I am planning a GUI front-end to control the command-line
> programs, as suggested by Aaron Hunt. It will be a tcl-tk script.
>
>
>
>
>
>
>
>
>
>
> .
>

🔗hfmlacerda <hfmlacerda@...>

Dear Aaron,

--- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
<aaronhunt@...> wrote:
>
> Dear Hudson (and Prent),
>
> I am always amazed when such tremendous effort goes into
> the creation of tools and ways to get microtonal music to
> happen, especially when there is so much low-level work
> being done. You guys have my utmost respect for your
> expertise using computers in these amazing ways.
>
> When I make a naive comment like I did about a front-end,
> as a programmer I come from the other side of the universe,
> in a way. Comments I make about programming usually drive
> real programmers bonkers, because I have only done high-
> level programming myself and have never had the inclination
> or patience to get into low-level work. I design programs
> starting with a GUI in an environment which hides all the
> low-level work from me. And I also hide everything I
> possibly can from the user, to make it all as point and click
> as possible. Working this way has its trade-offs, such as
> unnecessarily bulky programs, but the result is basically a
> point and click multi-platform package.

Many of such programs are not for me, since I prefer make every single
input from the keyboard and leave the mouse to use only in the moments
of panic (when a GUI program misses a keystroke or is too complex)... :-)

Likely due to such preference, I never had the inclination or patience
to learn how to develop GUIs (I do programming just for hobby, and
frequently a simple command-line interface is all that I need).

Concerning to packages and installers, I should assume that I spent a
lot of time dowloading, configuring and compiling programs when I was
using Mandrake 9.0.

But since I switched to the facilities of Debian GNU+Linux, I became
so lazy that I manage pratically all the programs/packages on my
system with Synaptic (or, sometimes, apt-get), as precompiled
binaries. Nothing better! However I still download, compile and
install the ABC programs by hand from the sources, once I like to have
the newest versions.

When I started to write microabc, I rejected any possibility of
writting a GUI for it. microabc is for use in command line along with
other command line tools (abcm2ps, abc2midi, abcpp...) to process
plain text files containing code (ABC notation, program instructions).

That time, microabc did not handle any 'standard' microtonal notation,
thus the user should choose from scratch the note names, accidentals
and several details on how to desing the input and how to get the
desired output (PS, PDF, MIDI, OGG...), by using several combinations
of the instructions known by the program.

Then, the implementation of the support for Sagittal as well as the
built-in preprocessor turned the things easier and more flexible.
Those changes made possible to simplify the program usage, as the
Sagittal system allowed an uniform procedure for different scales.

Now I think that such uniformisation may render feasible to write a
useful graphical front-end which does not restrict (significantly) the
user, but would even simplify some tasks and avoid line editing.

Thus, I started to design a graphical front-end for microabc. It will
be a sort of IDE.

Here are a few screenshots of the first sketch (just the window:
commands are not implemented yet):

TKmicroabc:
http://br.geocities.com/hfmlacerda/abc/tkmicroabc.png

TKmicroabc (the two small windows top/right), Jef Moine's tkabc (the
top window, editing quartertone accidentals), scala (bottom/right), gv
(showing a PostScript score) and timidity++ (using XAW interface):
http://br.geocities.com/hfmlacerda/abc/tkmicroabc2.png

The irony of the first screenshot is that a typical microabc session
may be written as a bash script with 3 ~ 8 lines...

The session represented in that first figure will correspond (in its
essence) to the commands:

abc2alias < input.abc > sagittal.abp
microabc -iinput.txt -S1 -Psagittal.abp -ooutput-ps.abc
abcm2ps output-ps.abc -Fsagittal.pfb -Ooutput.ps
microabc -iinput.txt -S1 -Msagittal.abp -ooutput-mid.abc
abc2midi -RS output-mid.abc 1 -o output.mid
gv output.ps &
timidity output.mid

(TKmicroabc will supply the full paths for the programs and files, and
handle temporary files.)

I am planning to export the commands as bash scripts or Makefiles
(besides saving the sessions as tcl scripts), so that the users can
get rid of the point-and-click torment and just issue a simple command
on a terminal window as soon as the script is generated! 8^D

>
> It appears to be a problem with all the Linux open-source etc.
> projects (which can be amazing in terms of what they
> accomplish) that they don't work easily. Most people expect
> drag and drop, point and click, plug and play stuff, and
> relatively few folks will want to take the time to do anything
> else.

Problem with all the projects???

There are programs which are not easy to _configure_, but finding and
installing packaged programs for GNU+Linux is rather simple, for
example, by using Synaptic. (Have you tried Debian or Ubuntu?)

Yet, all the best distributions install by default the most commonly
required dependencies, like tcl-tk and ghostscript. abc2midi and
abcm2ps also are available in the repositories of several 'distros'.

...and they have the advantage of to respecting the user freedom and
being morally correct. ;-)

> I guess on Windows everyone still expects an installer,
> but on Mac everyone expects one-step installation.

Interested programmers always can create such installers, since the
programs related to microabc are all multi-plataform and free
software. I am not in either OSes, so don't expect more than FreeDOS
binaries or GNU Makefiles from me... some day I might create a *.deb
package...

Note that there are ABC installers for Windows out there. For
instance, ABCEdit ``is a Windows program that integrates abcm2ps,
abc2midi and GhostView in a single package.'':
http://abcplus.sourceforge.net/#ABCEdit

It only misses microabc :-) (and the optional abcpp).

> Personally,
> anytime I have tried to install something that requires
> putting many things in many places, and configuring some
> of them, I _never_ have success.
> I think first most people will
> never even try something like that and if they do they
> probably have an experience like mine, and so most people
> never try anything that is being done this way; there just
> isn't time and patience enough to go around.
>

The front-end TKmicroabc will not change too much the things in this
respect, since it will depend on a Tcl-Tk interpreter installed on the
system.

By the other hand, the choice of tcl-tk is intended exactly to make
TKmicroabc plataform-independent, with no need of compiling. Another
advantage is that the configuration of programs (paths, auxiliary
files) may be centralised, and stored in a resource file.

(There are ways to make stand-alone executables from tcl-tk scripts.
See for instance http://www.equi4.com/tclkit/ . But that is not a task
I would put in my TODO list.)

>
> But in no way do I want to be discouraging. On the contrary,
> I just want to see software that is packaged and works
> without the user having to worry about _any_ low-level tasks.
> That has become a practical requirement for me from software
> that I use, and it is what I want to accomplish in the software
> that I write. I try, anyway.
>
> I applaud your work and I'm sure it will continue to become
> more streamlined in future releases. Maybe something I said
> is useful. If not, please just ignore it and keep working your
> own way!

Thanks for you inputs. Yes, they has been useful. ;-)

>
> Yours,
> Aaron Hunt
> H-Pi Instruments

Hudson Lacerda

🔗John Loffink <jloffink@...>

🔗kraiggrady@...

🔗aum <aum@...>

🔗kraiggrady@...

🔗Aaron Andrew Hunt <aaronhunt@...>

Thank you, Hudson, for this further explanation and screen shots.
I think this is a big step in the right direction. At least this way
the user can keep track of each of the components and exactly
what commands are being sent to them at all times.

Maybe the most important question fo you to consider as you
work on this is whether you want to make a tool mostly for your
own use, or for use by the open-source community, or for use
by the greatest number of people.

It sounds like you really want as many other people as possible
to be able to use this, or you would not be putting so much
effort into changing the interface at all, since you prefer
command line. But then it should be recognized that most
people who want to get music notation and playback from
a computer do not want to have an experience at the machine
which feels like programming, and the ideal is to have
an interface which feels essentially like a graphic design
tool for music. Thus, ideally all of the processing in its various
components should be hidden from the user, who is not
interested in how they fit together or what they do, or how
they must be configured. They just want to see and hear
music, so the program should take care of all those
low-level tasks.

On the other hand, if you are writing for the open-source
community, the opposite is true. People who use Linux and
open-source software tend to be at least hobbyist
computer programmers who actually enjoy tinkering
around with every last component of the system. I think it
should be emphasized that is a minority community, and
most people absolutely do _not_ want to tinker with the
system - on the contrary it is the last thing they want to
worry about.

But then it could be said that the general user (who is not
a computer programmer of any kind) will just buy Finale
or Sibelius. Maybe that is true, but those programs are
very expensive, of course.

Regarding user interface for music notation, I think
relatively few notation programs feel like writing music
with a pencil. Finale has never felt that way (it's a terrible
interface in my opinion). Sibelius is a lot better. A program
called Overture (which fewer people use and which is quite
poorly supported by its designer, at least on Mac) is closest
to what I am talking about. It essentially works like a graphic
design program, giving postscript and MIDI output. I realize
now that these examples are way beyond what you are aiming
for with your microabc work, particularly when this is just your
hobby! But, I think even so it is probably helpful to have well
in mind that the majority of folks who would be interested
in trying out some notation software want something that
feels a lot like writing music with a pencil, so to minimize
the command-line feeling of it, to hide as much of the
inner workings under the hood, so to speak, and to package
it so that it installs easily will increase the user pool, I think.

Again, this is just my opinion and I highly commend your
efforts!

Yours,
Aaron Hunt
H-Pi Instruments

--- In MakeMicroMusic@yahoogroups.com, "hfmlacerda" <hfmlacerda@...> wrote:
>
>
> Dear Aaron,
>
> --- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
> <aaronhunt@> wrote:
> >
> > Dear Hudson (and Prent),
> >
> > I am always amazed when such tremendous effort goes into
> > the creation of tools and ways to get microtonal music to
> > happen, especially when there is so much low-level work
> > being done. You guys have my utmost respect for your
> > expertise using computers in these amazing ways.
> >
> > When I make a naive comment like I did about a front-end,
> > as a programmer I come from the other side of the universe,
> > in a way. Comments I make about programming usually drive
> > real programmers bonkers, because I have only done high-
> > level programming myself and have never had the inclination
> > or patience to get into low-level work. I design programs
> > starting with a GUI in an environment which hides all the
> > low-level work from me. And I also hide everything I
> > possibly can from the user, to make it all as point and click
> > as possible. Working this way has its trade-offs, such as
> > unnecessarily bulky programs, but the result is basically a
> > point and click multi-platform package.
>
> Many of such programs are not for me, since I prefer make every single
> input from the keyboard and leave the mouse to use only in the moments
> of panic (when a GUI program misses a keystroke or is too complex)... :-)
>
> Likely due to such preference, I never had the inclination or patience
> to learn how to develop GUIs (I do programming just for hobby, and
> frequently a simple command-line interface is all that I need).
>
> Concerning to packages and installers, I should assume that I spent a
> lot of time dowloading, configuring and compiling programs when I was
> using Mandrake 9.0.
>
> But since I switched to the facilities of Debian GNU+Linux, I became
> so lazy that I manage pratically all the programs/packages on my
> system with Synaptic (or, sometimes, apt-get), as precompiled
> binaries. Nothing better! However I still download, compile and
> install the ABC programs by hand from the sources, once I like to have
> the newest versions.
>
> When I started to write microabc, I rejected any possibility of
> writting a GUI for it. microabc is for use in command line along with
> other command line tools (abcm2ps, abc2midi, abcpp...) to process
> plain text files containing code (ABC notation, program instructions).
>
> That time, microabc did not handle any 'standard' microtonal notation,
> thus the user should choose from scratch the note names, accidentals
> and several details on how to desing the input and how to get the
> desired output (PS, PDF, MIDI, OGG...), by using several combinations
> of the instructions known by the program.
>
> Then, the implementation of the support for Sagittal as well as the
> built-in preprocessor turned the things easier and more flexible.
> Those changes made possible to simplify the program usage, as the
> Sagittal system allowed an uniform procedure for different scales.
>
> Now I think that such uniformisation may render feasible to write a
> useful graphical front-end which does not restrict (significantly) the
> user, but would even simplify some tasks and avoid line editing.
>
> Thus, I started to design a graphical front-end for microabc. It will
> be a sort of IDE.
>
> Here are a few screenshots of the first sketch (just the window:
> commands are not implemented yet):
>
> TKmicroabc:
> http://br.geocities.com/hfmlacerda/abc/tkmicroabc.png
>
> TKmicroabc (the two small windows top/right), Jef Moine's tkabc (the
> top window, editing quartertone accidentals), scala (bottom/right), gv
> (showing a PostScript score) and timidity++ (using XAW interface):
> http://br.geocities.com/hfmlacerda/abc/tkmicroabc2.png
>
> The irony of the first screenshot is that a typical microabc session
> may be written as a bash script with 3 ~ 8 lines...
>
> The session represented in that first figure will correspond (in its
> essence) to the commands:
>
> abc2alias < input.abc > sagittal.abp
> microabc -iinput.txt -S1 -Psagittal.abp -ooutput-ps.abc
> abcm2ps output-ps.abc -Fsagittal.pfb -Ooutput.ps
> microabc -iinput.txt -S1 -Msagittal.abp -ooutput-mid.abc
> abc2midi -RS output-mid.abc 1 -o output.mid
> gv output.ps &
> timidity output.mid
>
> (TKmicroabc will supply the full paths for the programs and files, and
> handle temporary files.)
>
> I am planning to export the commands as bash scripts or Makefiles
> (besides saving the sessions as tcl scripts), so that the users can
> get rid of the point-and-click torment and just issue a simple command
> on a terminal window as soon as the script is generated! 8^D
>
> >
> > It appears to be a problem with all the Linux open-source etc.
> > projects (which can be amazing in terms of what they
> > accomplish) that they don't work easily. Most people expect
> > drag and drop, point and click, plug and play stuff, and
> > relatively few folks will want to take the time to do anything
> > else.
>
> Problem with all the projects???
>
> There are programs which are not easy to _configure_, but finding and
> installing packaged programs for GNU+Linux is rather simple, for
> example, by using Synaptic. (Have you tried Debian or Ubuntu?)
>
> Yet, all the best distributions install by default the most commonly
> required dependencies, like tcl-tk and ghostscript. abc2midi and
> abcm2ps also are available in the repositories of several 'distros'.
>
> ...and they have the advantage of to respecting the user freedom and
> being morally correct. ;-)
>
> > I guess on Windows everyone still expects an installer,
> > but on Mac everyone expects one-step installation.
>
> Interested programmers always can create such installers, since the
> programs related to microabc are all multi-plataform and free
> software. I am not in either OSes, so don't expect more than FreeDOS
> binaries or GNU Makefiles from me... some day I might create a *.deb
> package...
>
> Note that there are ABC installers for Windows out there. For
> instance, ABCEdit ``is a Windows program that integrates abcm2ps,
> abc2midi and GhostView in a single package.'':
> http://abcplus.sourceforge.net/#ABCEdit
>
> It only misses microabc :-) (and the optional abcpp).
>
> > Personally,
> > anytime I have tried to install something that requires
> > putting many things in many places, and configuring some
> > of them, I _never_ have success.
> > I think first most people will
> > never even try something like that and if they do they
> > probably have an experience like mine, and so most people
> > never try anything that is being done this way; there just
> > isn't time and patience enough to go around.
> >
>
> The front-end TKmicroabc will not change too much the things in this
> respect, since it will depend on a Tcl-Tk interpreter installed on the
> system.
>
> By the other hand, the choice of tcl-tk is intended exactly to make
> TKmicroabc plataform-independent, with no need of compiling. Another
> advantage is that the configuration of programs (paths, auxiliary
> files) may be centralised, and stored in a resource file.
>
> (There are ways to make stand-alone executables from tcl-tk scripts.
> See for instance http://www.equi4.com/tclkit/ . But that is not a task
> I would put in my TODO list.)
>
> >
> > But in no way do I want to be discouraging. On the contrary,
> > I just want to see software that is packaged and works
> > without the user having to worry about _any_ low-level tasks.
> > That has become a practical requirement for me from software
> > that I use, and it is what I want to accomplish in the software
> > that I write. I try, anyway.
> >
> > I applaud your work and I'm sure it will continue to become
> > more streamlined in future releases. Maybe something I said
> > is useful. If not, please just ignore it and keep working your
> > own way!
>
> Thanks for you inputs. Yes, they has been useful. ;-)
>
> >
> > Yours,
> > Aaron Hunt
> > H-Pi Instruments
>
> Hudson Lacerda
>

🔗Carl Lumma <carl@...>

🔗hfmlacerda <hfmlacerda@...>

--- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
<aaronhunt@...> wrote:
>
> Thank you, Hudson, for this further explanation and screen shots.
> I think this is a big step in the right direction. At least this way
> the user can keep track of each of the components and exactly
> what commands are being sent to them at all times.
>
> Maybe the most important question fo you to consider as you
> work on this is whether you want to make a tool mostly for your
> own use, or for use by the open-source community, or for use
> by the greatest number of people.
[...]

Hi Aaron,

The information you need is:

------------------------------
microabc is addressed to people that use (or are willing to use) ABC
notation, and want to do microtonal music with it.
------------------------------

(I thought that this was clear from the very first phrase of microabc
description, but I will add the phrase above to it for more clarity.)

ABC is a sort of music representation using characters (plain text
files). You type C D E F G A B to get the notes.

ABC is easy to learn, compact and fast to write, and software like
abcm2ps and abcMIDI are indeed very powerful and flexible.

There are graphical front-ends to edit, display and print pieces, and
to manage ABC collections (a single ABC file may contain hundreds or
even thousands of music pieces, and of course you may have a
collection with several ABC files). Such front-ends typically control
command-line programs.

There are also graphical music notation programs which export/save ABC
files. Free examples are: denemo, noteedit and tkabc (tkabc is that
one in the second screenshot of my previous message). A non-free
example is Harmony Assistant.

The community of ABC users is very diversified: it includes users of
several plataforms/OSes, (GNU+Linux, Windows, MacOS, DOS... and yet
handhelds), with various degrees of computer literacy (from beginners
to experts). Many ABC users are folk musicians.

Here is a short ABC example that you would love to try out online
_right now_:

X:1
T:Scale of G minor
K:Gm
|: GA Bc d=e ^fg |1 =f_e dc BA G2 :|2 =f/_e/d/c/ BA G4 |]

To convert it to MIDI and PDF, copy it and paste to this webform, then
press Submit:

http://www.concertina.net/tunes_convert.html

Here is a microtonal (quartertone) example:

X:2
T:Quartertones in ABC
L:1/4
K:C
C ^/C ^C ^3/C | D _/D _D _3/D | !fermata!C2 z2 |]

microabc was created to simplify the use of different tunings and
notation systems, without abandon the rich features of ABC programs,
in special those ones of abcm2ps (the score render).

For instance, with microabc, you can write any Sagittal pitch as
easily as in this example (file 'sa.abp'):

X:3
L:1/4
M:none
K:C
%%postscript sagmixed
"Mixed Sagittal notation"
[C] [Eb/] [Ee] [D#f] [Fj] [F^] [At] [Ab] [Abf] [G]2 |
%%postscript sagpure
"Pure Sagittal notation"
[C] [Eb/] [Ee] [D#f] [Fj] [F^] [At] [Ab] [Abf] [G]2 |

This couple of commands is sufficient to get a score (PS) file and a
MIDI file:

microabc -E -Psa.abp -o- | abcm2ps - -O sa.ps
microabc -E -Msa.abp -o- | abc2midi - -o sa.mid

Here are the outputs:
http://br.geocities.com/hfmlacerda/abc/sa.ps (134kB)
http://br.geocities.com/hfmlacerda/abc/sa.mid (1kB)
The score as PDF, for convenience:
http://br.geocities.com/hfmlacerda/abc/sa.pdf (8kB)

microabc and abcm2ps are flexible enough to allow personal ways to
notate microtonal music (choose note names you wish for the input
file, define how to place the notes on staff, their frequencies for
MIDI, which glyphs to show as accidental or note head, etc.). All this
is automated, so that the settings are done once for all music pieces
using the same scale.

The flexibility for non-conventional notation I need cannot be
achieved with Finale or Sibelius. These programs are difficult to use
and require too many tweaks to do almost anything which is not 12-EDO
and common time. Typically, most work has to be redone for every
piece. And their file formats are impossible to use along other
programs. ABC is text-based, thus it is easy to process and integrate
in personalised composition systems/environments. Another interesting
notation program is Lilypond. Its format is being used by several
computer music programs, as well as notation export format by the
sequencer Rosegarden, for instance.

Now, concerning to TKmicroabc, I am not sure about the direction to
go. Personally, I don't need of it, although I think it may be useful
to generate a shell (or tcl) script or Makefile for a music project. I
have started TKmicroabc from your suggestion of ``a simple front-end
to generate scripts'', also considering that Windows users might
prefer use it rather than running the programs in that awful
``Command'' interpreter (TKmicroabc will save the paths for the
programs to execute them).

The Sagittal engine of microabc can save work for many users/uses (it
can do equal/linear temperaments, as well as just intonation notated
relative to pythagorean fifhts, with no need to write settings files).
In TKmicroabc, that couple of commands above should be available
ready-to-use as a project template, so that a newbie could start using
it with no need to understand the commands before.

Anyway, people need learn ABC to use microabc.

...as simple as possible, but not simpler!

Cheers,
Hudson Lacerda
http://br.geocities.com/hfmlacerda/abc/microabc-about.html
http://br.geocities.com/hfmlacerda/abc/microabc-tutorial.pdf

🔗Aaron Andrew Hunt <aaronhunt@...>

Hi Hudson.

This becomes more and more interesting!

I want to point out that what you say about Sibelius here:

> The flexibility for non-conventional notation I need
> cannot be achieved with Finale or Sibelius. These
> programs are difficult to use and require too many
> tweaks to do almost anything which is not 12-EDO
> and common time. Typically, most work has to be
> redone for every piece. And their file formats are
> impossible to use along other programs.

is not quite accurate. Sibelius can work with musicxml files.
Finale used to export enigma files, I don't know if it
now outputs musicxml. Changing the time signature
is certainly not a problem in these programs. As for
tuning, AFAIK you are correct.

I could bet that to do anything complicated in
something like abc will be more trouble than doing it in
a WYSIWYG program like Sibelius, but as I don't
actually use either of these programs, this is
mere conjecture coming from me.

Thanks so much for the examples and additional
information; your messages are all very helpful.
The web script input is amazing!

Part of the reason all of this interests me is that I am
looking for a text scripting format for MegaScore files.
<http://www.h-pi.com/MSCintro.html>
Presently files are text but are not very human
readable. So something like abc makes sense. I have
to look into all of this further.

Cheers,
Aaron Hunt
H-Pi instruments

--- In MakeMicroMusic@yahoogroups.com, "hfmlacerda" <hfmlacerda@...> wrote:
>
> --- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
> <aaronhunt@> wrote:
> >
> > Thank you, Hudson, for this further explanation and screen shots.
> > I think this is a big step in the right direction. At least this way
> > the user can keep track of each of the components and exactly
> > what commands are being sent to them at all times.
> >
> > Maybe the most important question fo you to consider as you
> > work on this is whether you want to make a tool mostly for your
> > own use, or for use by the open-source community, or for use
> > by the greatest number of people.
> [...]
>
> Hi Aaron,
>
> The information you need is:
>
> ------------------------------
> microabc is addressed to people that use (or are willing to use) ABC
> notation, and want to do microtonal music with it.
> ------------------------------
>
> (I thought that this was clear from the very first phrase of microabc
> description, but I will add the phrase above to it for more clarity.)
>
> ABC is a sort of music representation using characters (plain text
> files). You type C D E F G A B to get the notes.
>
> ABC is easy to learn, compact and fast to write, and software like
> abcm2ps and abcMIDI are indeed very powerful and flexible.
>
> There are graphical front-ends to edit, display and print pieces, and
> to manage ABC collections (a single ABC file may contain hundreds or
> even thousands of music pieces, and of course you may have a
> collection with several ABC files). Such front-ends typically control
> command-line programs.
>
> There are also graphical music notation programs which export/save ABC
> files. Free examples are: denemo, noteedit and tkabc (tkabc is that
> one in the second screenshot of my previous message). A non-free
> example is Harmony Assistant.
>
> The community of ABC users is very diversified: it includes users of
> several plataforms/OSes, (GNU+Linux, Windows, MacOS, DOS... and yet
> handhelds), with various degrees of computer literacy (from beginners
> to experts). Many ABC users are folk musicians.
>
> Here is a short ABC example that you would love to try out online
> _right now_:
>
> X:1
> T:Scale of G minor
> K:Gm
> |: GA Bc d=e ^fg |1 =f_e dc BA G2 :|2 =f/_e/d/c/ BA G4 |]
>
> To convert it to MIDI and PDF, copy it and paste to this webform, then
> press Submit:
>
> http://www.concertina.net/tunes_convert.html
>
> Here is a microtonal (quartertone) example:
>
> X:2
> T:Quartertones in ABC
> L:1/4
> K:C
> C ^/C ^C ^3/C | D _/D _D _3/D | !fermata!C2 z2 |]
>
> microabc was created to simplify the use of different tunings and
> notation systems, without abandon the rich features of ABC programs,
> in special those ones of abcm2ps (the score render).
>
> For instance, with microabc, you can write any Sagittal pitch as
> easily as in this example (file 'sa.abp'):
>
> X:3
> L:1/4
> M:none
> K:C
> %%postscript sagmixed
> "Mixed Sagittal notation"
> [C] [Eb/] [Ee] [D#f] [Fj] [F^] [At] [Ab] [Abf] [G]2 |
> %%postscript sagpure
> "Pure Sagittal notation"
> [C] [Eb/] [Ee] [D#f] [Fj] [F^] [At] [Ab] [Abf] [G]2 |
>
> This couple of commands is sufficient to get a score (PS) file and a
> MIDI file:
>
> microabc -E -Psa.abp -o- | abcm2ps - -O sa.ps
> microabc -E -Msa.abp -o- | abc2midi - -o sa.mid
>
> Here are the outputs:
> http://br.geocities.com/hfmlacerda/abc/sa.ps (134kB)
> http://br.geocities.com/hfmlacerda/abc/sa.mid (1kB)
> The score as PDF, for convenience:
> http://br.geocities.com/hfmlacerda/abc/sa.pdf (8kB)
>
> microabc and abcm2ps are flexible enough to allow personal ways to
> notate microtonal music (choose note names you wish for the input
> file, define how to place the notes on staff, their frequencies for
> MIDI, which glyphs to show as accidental or note head, etc.). All this
> is automated, so that the settings are done once for all music pieces
> using the same scale.
>
> The flexibility for non-conventional notation I need cannot be
> achieved with Finale or Sibelius. These programs are difficult to use
> and require too many tweaks to do almost anything which is not 12-EDO
> and common time. Typically, most work has to be redone for every
> piece. And their file formats are impossible to use along other
> programs. ABC is text-based, thus it is easy to process and integrate
> in personalised composition systems/environments. Another interesting
> notation program is Lilypond. Its format is being used by several
> computer music programs, as well as notation export format by the
> sequencer Rosegarden, for instance.
>
> Now, concerning to TKmicroabc, I am not sure about the direction to
> go. Personally, I don't need of it, although I think it may be useful
> to generate a shell (or tcl) script or Makefile for a music project. I
> have started TKmicroabc from your suggestion of ``a simple front-end
> to generate scripts'', also considering that Windows users might
> prefer use it rather than running the programs in that awful
> ``Command'' interpreter (TKmicroabc will save the paths for the
> programs to execute them).
>
> The Sagittal engine of microabc can save work for many users/uses (it
> can do equal/linear temperaments, as well as just intonation notated
> relative to pythagorean fifhts, with no need to write settings files).
> In TKmicroabc, that couple of commands above should be available
> ready-to-use as a project template, so that a newbie could start using
> it with no need to understand the commands before.
>
> Anyway, people need learn ABC to use microabc.
>
> ...as simple as possible, but not simpler!
>
> Cheers,
> Hudson Lacerda
> http://br.geocities.com/hfmlacerda/abc/microabc-about.html
> http://br.geocities.com/hfmlacerda/abc/microabc-tutorial.pdf
>

🔗hfmlacerda <hfmlacerda@...>

--- In MakeMicroMusic@yahoogroups.com, "Aaron Andrew Hunt"
<aaronhunt@...> wrote:
>
> Hi Hudson.
>
> This becomes more and more interesting!
>
> I want to point out that what you say about Sibelius here:
>
> > The flexibility for non-conventional notation I need
> > cannot be achieved with Finale or Sibelius. These
> > programs are difficult to use and require too many
> > tweaks to do almost anything which is not 12-EDO
> > and common time. Typically, most work has to be
> > redone for every piece. And their file formats are
> > impossible to use along other programs.
>
> is not quite accurate. Sibelius can work with musicxml files.
> Finale used to export enigma files, I don't know if it
> now outputs musicxml.

I know of that, but have you tried to read or to write a musicxml
file, or to implement it in any program? Are you sure it is able to
represent every feature of Finale or Sibelius? That representation is
documented so that users can explore it?

musicxml seems like designed to be a fake standard. Is is not suitable
for real usage. ENIGMA (a binary format) also seems too complex for
users who want just, for example, to import/modify/export a music file
with a automated-composition environment.

We need a transparent, high-level, easy-to-use, yet powerful form of
notation.

> Changing the time signature
> is certainly not a problem in these programs.
> As for
> tuning, AFAIK you are correct.

Til some time ago it was difficult to get independent time signatures
for each voice with programs like Finale, Sibelius or Encore. I don't
know about the actual stage of development.

ABC also has its limitations in this issue (abcm2ps cannot align
voices with different tempi), but Lilypond is really flexible:
http://lilypond.org/doc/v2.10/input/proportional

Sibelius has a script language which may be useful, though. Finale
supports plugins, but it seems that only in binary form. However,
those programs are not free software, they belong to that evil group
of software packages that are subject to _artificial scarcity_ and
enclose users into proprietary cages. Their secret and incompatible
native file formats are part of the cages. They are not made for the
users, but for their owners. They are not in the ``right direction''.

>
> I could bet that to do anything complicated in
> something like abc will be more trouble than doing it in
> a WYSIWYG program like Sibelius, but as I don't
> actually use either of these programs, this is
> mere conjecture coming from me.

All my experiences with Sibelius and Encore were completely
frustrating. I haven't used Finale for any real work, though.

Complex things may be labourious to do with abcm2ps, but so far I am
happy with the results. The tasks can be automated, and it is
practical to reuse customised extensions in other files. Also it is
easy to mix text and music in a single file, or to include music
excerpts in LaTeX documents, as I did in microabc-tutorial.pdf.

>
> Thanks so much for the examples and additional
> information; your messages are all very helpful.
> The web script input is amazing!
>
> Part of the reason all of this interests me is that I am
> looking for a text scripting format for MegaScore files.
> <http://www.h-pi.com/MSCintro.html>
> Presently files are text but are not very human
> readable. So something like abc makes sense. I have
> to look into all of this further.

Have a look also in LilyPond. There are several programs using its format:
http://www.lilypond.org

Cheers,
Hudson Lacerda

>
> Cheers,
> Aaron Hunt
> H-Pi instruments
>
[...]

🔗George D. Secor <gdsecor@...>

--- In MakeMicroMusic@yahoogroups.com, "John Loffink" <jloffink@...>
wrote:
>
> US ebay acution item 170183030371 shows a TV/monitor labeled as a
Motorola
> Scalatron.
>
> Does anyone have further information on the monitor? George?

It's the newer, less expensive model of the Scalatron tuner, which I
described here:

/tuning/topicId_67422.html#67428

We called it the "consolidated tuner", since it combined both the
original programmable tone generator and (video-display) pitch
monitor in a single box.

> My comments:
>
> The Motorola Scalatron was a dual rank keyboard based upon organ
divide down
> technology, built into home organ type packaging, and invented by
George
> Secor in the early 1970s.

I didn't invent it. It was the idea of Herman Pedtke, an organist
and faculty member of the School of Music at De Paul University,
Chicago. Herm discussed the idea with his friend, Dick Harasek, who
subsequently started the Scalatron company as a "New Venture"
subsidiary of Motorola.

The Scalatron already existed as a two-manual electronic organ (with
no pedalboard) at the time that I contacted the company to explain my
idea of using a generalized keyboard to better exploit the resources
of alternative tunings.

I also recommended adding filtering and enveloping, by which the
instrument became a microtonal polyphonic synthesizer.

I've discussed the generalized-keyboard Scalatron at various times on
the tuning lists, e.g. here:
/tuning/topicId_39323.html#39407

> It had a cassette interface.

Well yes, sort of. You could connect a cassette recorder to either
the input or output jacks of the two-piece version, but those were
normally used for a microphone and for the video display (pitch)
monitor, respectively. I don't know whether the consolidated tuner
had an output jack.

> I am not aware of a
> video interface, but it is possible it was added later.

The pitch monitor displayed the pitches as horizontal black bars.
(See the above link.)

> This auction is just
> for the monitor, not the keyboard, which would be a real find as
less than
> 20 Scalatrons were ever made. Some versions of the keyboard used a
hexagonal
> array rather than the standard piano style keyboard.
>
> Adding to this, one of the patent numbers does appear to match a
pedal tone
> decay patent that is now reassigned to Yamaha, who went through a
splurge of
> activity in patenting microtonal technology. So the device may be a
> legitimate attachment to the Scalatron.
>
> Patent 4085643 - Truncated decay system

Although the company did offer an accessory pedalboard, AFAIK none
was ever made. That particular patent might have had something to do
with that.

> As the first knob on the monitor is labeled with a note symbol, I
wonder if
> this was used to assist in retuning the microtonal scales in the
Scalatron.

As I explained in the above link, the newer (consolidated) tuner
(shown on eBay) is not very microtonal. It's capable of only 12-
equal, although it does give you the ability to shift the pitch
upward or downward by roughly 4-cent increments within a limited
range: the knob allows you to set the note "A" in 1-cent increments,
from 438 to 445 Hz. There's another knob to select the chromatic
tone that sounds, and a third one to select the octave. (Of course,
there was also an on-off/volume control knob.)

--George

🔗George D. Secor <gdsecor@...>

--- In MakeMicroMusic@yahoogroups.com, aum <aum@...> wrote:
>
> Dear Friends,
> I am working on the second volume of my book on electromechanical
and
> electronic instruments history. Just yesterday I was collecting
> Scalatron information - a nice coincidence. I have found something
in
> Xenharmonikon 3 and in few books but there is almost nothing about
> Scalatron technology.
> Does anybody here know any details on frequency generating,
synthesis,
> etc.? Do you have any picture which can be published? Any patent
numbers?
> Thanks
> Milan

The Scalatron derived all of its pitches from a quartz-crystal-
controlled master oscillator, originally at 3579545 Hz, later changed
to 3581600 Hz (which resulted in better overall approximations to
pitches for certain equal divisions of the octave). Pitch
programming was accomplished by a set of 10 binary switches, which
divided the frequency by a number ranging from 1025 to 2048 for each
tone of the top octave; all of the lower octaves changed pitch
automatically (via frequency division by 2). The statement in the
Scalatron flyer (in XH3) about some huge number of pitches per octave
is both false and misleading; I don't know who was responsible for
that.

The two-manual instrument had 24 sets of switches, which controlled
the pitch of each of the 12 notes/octave on each of the 2 keyboards.
The three generalized-keyboard instruments had only a single
keyboard, with either 31 or 55 sets of binary switches. (For more
details, see my reply to John Loffink.)

I have a bunch of pictures of the instrument from years past on color
negative film, but only one digital picture taken recently:
/makemicromusic/files/secor/GenKbd1a.jpg
This is a close-up of the generalized keyboard and the synthesizer
controls; the tuning is selected by pressing a button in the far left
column. The actual pitch programming for the variable tunings
(presets 1, 2, & 3) is set by flipping small switches on a back
panel, not visible here.

You're welcome to use it in your book, if you desire.

--George Secor

🔗Carl Lumma <carl@...>

🔗Rick McGowan <rick@...>

It might be getting off topic, but... hfmlacerda wrote:

> those programs are not free software, they belong to that evil group
> of software packages that are subject to _artificial scarcity_ and
> enclose users into proprietary cages. Their secret and incompatible
> native file formats are part of the cages. They are not made for the
> users, but for their owners. They are not in the "right direction".

Not all software can just be "free". Someone has to write it, and there
are lots of people who write software who like to take care of their homes
& families. Do you find crowds of people making free furniture, or farmers
giving away free vegetables?

And what is "artificial scarcity"? We're talking about software, not
diamonds! Just buy a copy. It's as easily available as anything else that
isn't quite "free", and since it's software it can be replicated basically
infinitely. What you pay for is the development cost.

As for proprietary formats, well... Who cares what it looks like on disk?
Some miniscule percentage of dilettantes? Nobody can make a viable business
out of producing software for a vanishingly small audience who wants to
diddle the disk format. (And, in case you've never worked in a production
software shop: once you make a format public, you have to document and
support it, and that can eat up development & documentation budgets that
might be better spent working on features and bug fixes.)

Finale and other packages can export to PDF and print onto paper. What
more open and compatible format does the musician want? Wasn't paper good
enough for Bach? And if it doesn't do what you want, then just get
something else. And if you can't find the right software for money or free,
I guess you could write it yourself and give it away instead of
complaining about how much software costs.

> musicxml seems like designed to be a fake standard. Is is not
> suitable for real usage.

Like most of these "ML" standards, isn't Music XML developed by a
basically open community? So why would they knowingly make a "fake"
standard? Do you really think that standards people set out to make
something that isn't useful, at least for some restricted purposes? Just
because it isn't as flexible as paper & pencil doesn't mean it won't work
for some musicians for some purposes. When was the last time you personally
tried to solve all music notation problems in one big software system? Why
not joint the Music XML development community and work on making it
better?

Anyway, enough of that. Let's get back to the regularly scheduled
microtonal mayhem.

Rick

🔗Carl Lumma <carl@...>

At 11:38 AM 1/7/2008, you wrote:
>It might be getting off topic, but... hfmlacerda wrote:
>
>> those programs are not free software, they belong to that evil group
>> of software packages that are subject to _artificial scarcity_ and
>> enclose users into proprietary cages. Their secret and incompatible
>> native file formats are part of the cages. They are not made for the
>> users, but for their owners. They are not in the "right direction".
>
>Not all software can just be "free". Someone has to write it, and there
>are lots of people who write software who like to take care of their homes
>& families. Do you find crowds of people making free furniture, or farmers
>giving away free vegetables?
>
>And what is "artificial scarcity"? We're talking about software, not
>diamonds! Just buy a copy. It's as easily available as anything else that
>isn't quite "free", and since it's software it can be replicated basically
>infinitely. What you pay for is the development cost.

Without having this explode into a flame war, I generally agree
with this. However, I do think software has a special status above
that things like carpentry don't share. It's more like literacy.
There should still be room for professional writers, but everybody
should be able to write.

>As for proprietary formats, well... Who cares what it looks like on disk?

Now here I disagree strongly. When the fate of a huge body of
information rests with one company, that's not good. If proprietary
software is so good, it shouldn't fear open file formats. The
ability to exchange data between programs is also really empowering
in its own right. Things like VST do come out of the industry, but
not often enough if you ask me.

>Finale and other packages can export to PDF and print onto paper. What
>more open and compatible format does the musician want?

This strikes me as a very weak argument.

>Wasn't paper good enough for Bach?

Yes, but we hope art can move beyond Bach. If not in absolute
quality, then in some cultural sense that's meaningful.

-Carl

🔗hfmlacerda <hfmlacerda@...>

🔗George D. Secor <gdsecor@...>

🔗Rick McGowan <rick@...>

Carl wrote,

> software has a special status above
> that things like carpentry don't share. It's more like literacy.
> There should still be room for professional writers, but everybody
> should be able to write.

I don't really buy that. Anyone can write software. Nothing in the
software industry prevents people from rolling their own. In fact a good
part of the software industry actively supports rolling your own --
compilers, development environments, etc.

> When the fate of a huge body of
> information rests with one company, that's not good.

But there isn't any "fate" resting with the Finale company. The software
will continue to exist and run even if the company goes out of business;
and so will the data. The bigger problem is that when the hardware wears
out and the upgrade path doesn't support the old software *then* you are
screwed. This isn't actually a problem that is *caused* by Finale having a
proprietary file format, and it isn't their fault.

And, can you prove that they "fear" open file formats? After all, they do
support exporting to XML and they support 3rd party plugins. Not making
one's file formats publicly open, in my experience, has more to do with the
resulting support and documentation burdens on the development
organization than it does with inherent fear of such formats. (Having said
that, however, of course companies want to have some competitive edge so
that all of their work isn't immediately stolen or pirated and they go out
of business in a month.)

> Yes, but we hope art can move beyond Bach. If not in absolute
> quality, then in some cultural sense that's meaningful.

OK, so can't we do that whether the disk format of some software package
is proprietary or not? How does that really matter in the production of the
resulting art? Every age lives with the limitations of available tools.
And if the individual won't or can't do that, then they can make their own
tools. Software or violins or chromeloeons.

Rick

🔗Carl Lumma <carl@...>

Hi Rick,

> > software has a special status above
> > that things like carpentry don't share. It's more like
> > literacy. There should still be room for professional
> > writers, but everybody should be able to write.
>
> I don't really buy that. Anyone can write software. Nothing
> in the software industry prevents people from rolling their
> own. In fact a good part of the software industry actively
> supports rolling your own -- compilers, development
> environments, etc.

Sure, I agree. But if you say, "Who wants to write software?
Only freaks" (as you seemed to say earlier), I'm going to say
that's a pretty grim view of the 21st century. When a
disruptive technology like literacy or computer programming
comes along, I really do think that it's so powerful that you
either control it or are controlled by those who do. And I'm
not looking forward to a 'clergy' of programmers. Or maybe
more accurately, of IP owners, who employ programmers as the
church did guilds.

> > When the fate of a huge body of
> > information rests with one company, that's not good.
>
> But there isn't any "fate" resting with the Finale company.
> The software will continue to exist and run even if the
> company goes out of business; and so will the data.

Not when it's no longer supported by any OS or hardware.
Then it's either lost or there's a burden on content owners
to shift it over (which is often illegal, thanks to the
DCMA).

> The bigger problem is that when the hardware wears
> out and the upgrade path doesn't support the old software
> *then* you are screwed. This isn't actually a problem that
> is *caused* by Finale having a proprietary file format, and
> it isn't their fault.

It's a fact of life that we need to take into account when
choosing software, and when debating ideal software industry
setups.

> And, can you prove that they "fear" open file formats?
> After all, they do support exporting to XML and they support
> 3rd party plugins. Not making one's file formats publicly
> open, in my experience, has more to do with the resulting
> support and documentation burdens on the development
> organization than it does with inherent fear of such formats.
> (Having said that, however, of course companies want to have
> some competitive edge so that all of their work isn't
> immediately stolen or pirated and they go out of business
> in a month.)

It's useful to think about what the 'proprietary binaries'
market rewards. Software companies have incentives to lock
their data formats, yes. And they have incentives to add
features with every release. And they have incentives to
make their software hard to use. And they have incentives
to encourage piracy of their software. Perhaps it's the
last two that are the most counter-intuitive...

Hard to use:
Different application niches function in different ways.
But the music DAW niche is a typical kind of niche: there
are several large, expensive packages with rough feature
parity, which are mainly distinguished by having different
groups of loyal users. The users stick to their package.
Subsequent versions of the software are released mainly
to capture upgrades, and so features have to be added.
Left unattended, this process will create arcane, hard to
use software (interfaces must be 'refactored' every time
features are added to prevent this). And that's dandy,
because the more arcane the interface is, the harder it
will be for any user to switch to the competition. They've
already invested in learning the bizarre tricks and traps
of one package, so they're not about to do it again unless
forced.
Something similar happens with cars. It's isn't a steep
learning curve that keeps people loyal to a brand and
model, but rather fear of making a huge investment on an
unknown (this has actually been studied). But the bottom
line is people are loyal, they go to get the new Civic,
and to sell it to them Honda makes it bigger and fancier.
So cars go "upmarket". The Civic today is bigger than the
Accord was in 1990 (I'm making up this example). Hyundai
is the new Honda, and Kia is the new Hyundai.

Encourage piracy:
I can't think of a successful software package that did
anything serious about piracy until the 3rd or 4th release.
There's now ample evidence, from multiple high-level people
within Microsoft, that they actively encouraged piracy of
Windows and Office throughout the '90s. It's really quite
a trick; they get the 'spread' benefit of free software
without giving up legal ownership. They can come along
later and try to monetize those users (and MS has in fact
done this).

So the question is: Can we imagine markets that would provide
incentives for better software? Having open source is an
interesting try, but it's far from a complete picture and I'm
not saying an approach with closed source won't wind up being
the answer. But open, standard data formats seem like a
no-brainer.

> > Yes, but we hope art can move beyond Bach. If not in absolute
> > quality, then in some cultural sense that's meaningful.
>
> OK, so can't we do that whether the disk format of some software
> package is proprietary or not? How does that really matter in
> the production of the resulting art? Every age lives with the
> limitations of available tools. And if the individual won't or
> can't do that, then they can make their own tools. Software or
> violins or chromeloeons.

I think the benefits of data portability on the creative space
are obvious. There are limitations to technology, and then
there are social limitations imposed on technology. It's the
latter I think we should examine.

-Carl

🔗kraiggrady@...

🔗Rick McGowan <rick@...>

> Sure, I agree. But if you say, "Who wants to write software?
> Only freaks" (as you seemed to say earlier), I'm going to say..

Wait a minute. I said no such thing. Please re-read. And I certainly
didn't use the word "freaks"!

What I said was, in effect, that companies who make end-user products
don't necessarily want the support burden that comes with opening their
file formats to the vanishingly small percentage of "users" who want to
diddle them. Most users just want to use the software in the intended
manner. And unless a platform changes out from under them -- not the fault
of the music software maker -- they can continue to use the software and
their data.

> When a
> disruptive technology like literacy or computer programming
> comes along, I really do think that it's so powerful that you
> either control it or are controlled by those who do. And I'm
> not looking forward to a 'clergy' of programmers.

Hmmm, well... Programming is difficult enough to learn and practice that
while it's theoretically open to all, not everyone has the perseverance to
actually do it. But there isn't any secret cabal of programmers who are
trying to form a clergy and disallow anyone from learning it... As for "IP
owners", yeah, I'm dismayed by the power that IP owners have in some areas.

> There are limitations to technology, and then
> there are social limitations imposed on technology. It's the
> latter I think we should examine.

Yeah, perhaps. I think there's an over-arching problem that is exhibited
by just about every field, and a potentially fatal problem inherent in our
civilization: the expectation of infinitely growing economies (or expanding
markets), and the the effective enforcement of obsolescence. It's not the
fault of company X that they make something that isn't portable to the next
generation of operating system (or hardware, or whatever)... That is a
side-effect of the general problem that our tools keep changing
incompatibly. As they get "better" some things get left behind.

Anyway, this is way off topic for this list, and we're not going to solve
it here. I don't think that music software companies are inherently
evildoers just because they don't publish their file formats, so I wanted
to say something about it.

Rick

🔗hfmlacerda <hfmlacerda@...>

--- In MakeMicroMusic@yahoogroups.com, Rick McGowan <rick@...> wrote:
>
> It might be getting off topic, but... hfmlacerda wrote:
>
> > those programs are not free software, they belong to that evil group
> > of software packages that are subject to _artificial scarcity_ and
> > enclose users into proprietary cages. Their secret and incompatible
> > native file formats are part of the cages. They are not made for the
> > users, but for their owners. They are not in the "right direction".
>
> Not all software can just be "free". Someone has to write it, and
there
> are lots of people who write software who like to take care of their
homes
> & families. Do you find crowds of people making free furniture, or
farmers
> giving away free vegetables?

Dear Rick,

Your reaction is mainly due to a wrong interpretation (or
incomprehension) of the meaning of the expression ``free software''.

Bear in mind:

Free software as in freedom! Free as in freedom!

<<<
``Free software'' is a matter of liberty, not price. To understand the
concept, you should think of ``free'' as in ``free speech'', not as in
``free beer''.
Free software is a matter of the users' freedom to run, copy,
distribute, study, change and improve the software.
>>>>
http://www.gnu.org/philosophy/free-sw.html

>
> And what is "artificial scarcity"? We're talking about software, not
> diamonds! Just buy a copy.

There are no significant reproduction costs in simply copying streams
of bits. If you want to know what is artificial scarcity, just search
in the web. You will find information there.

BTW, artificial scarcity also occurs in the material world, as one can
see in statistics on, for instance, homeless families X unused
properties, or hungry people X produced food.

There are severe ``bugs'' in the economical market system, which cause
and increase such social problems. The example of the programmer who
needs to write proprietary software to live may be compared to that of
a worker who destroys native trees to live. I can understand that such
problems are too complex to get a rapid solution, but this is not the
same to say that these are not problems. Those individual workers may
have no alternative for a while, but there are other people that _can_
do choices to make the world better.

> It's as easily available as anything else that
> isn't quite "free", and since it's software it can be replicated
basically
> infinitely. What you pay for is the development cost.

Don't agree with the argument. Restricting further copies, obfuscating
the sources/binaries/files, installing spywares, etc. -- all those
very common practices in the proprietary software world --, are not,
in my opinion, justified by the ``development cost''. The opposite:
several of those practices make the development costs higher.

Development costs can be shared without affecting other people
negatively. There are several ways to fund software.

And, after all, I should point out again that free software is not
gratis. Any software has a development cost :-0 , and it is not
uncommon today that people pay for copies of free software.

I can say for myself: I have bought _several_ copies of free software
packages in _several_ circumstances. I have paid for free software.
Haven't you?

>
> As for proprietary formats, well... Who cares what it looks like on
disk?
> Some miniscule percentage of dilettantes? Nobody can make a viable
business
> out of producing software for a vanishingly small audience who wants
to
> diddle the disk format. (And, in case you've never worked in a
production
> software shop: once you make a format public, you have to document and
> support it, and that can eat up development & documentation budgets
that
> might be better spent working on features and bug fixes.)

I am a profesional musician. I do programming just for fun and for
personal needs, as I said in a previous message.

There are many programs which native formats are plain text (sometimes
compressed as zip or equivalent). This may be taken as a sort of
self-documented format, which is easy for programmers to figure out
how to use, even when there is no formal documentation. There are also
binary formats which are not too difficult to analyse (that is not the
case of obfuscated binaries).

BTW, I read recently that Microsoft announced the end of support for
``old'' files by Microsoft Office. This will affect a large number of
those people that didn't care how their files look in the disk :-0.
Meanwhile, I just continue using my files in open formats, with no
problems... 8-)

>
> Finale and other packages can export to PDF and print onto paper.

LOL... :^D

> What
> more open and compatible format does the musician want? Wasn't paper
good
> enough for Bach?

From the perspective of a proprietary-software owner, the user should
never wish any feature that is not already implemented: anything the
user needs is ready-to-use... until the next update, when the ``user
needs'' change suddenly to match the new features!

> And if it doesn't do what you want, then just get
> something else.

That is what I do.

(I believe I have also the right to make public the reasons for that,
mainly when I am asked about, as it was the case. You have also the
right to disagree with me.)

> And if you can't find the right software for money or free,
> I guess you could write it yourself and give it away instead of
> complaining about how much software costs.

Yes! That is exactly what I do! ;-D

But, again: ``free as in freedom''!

And I am not complainting about any software prices. If you think this
is not true, please show me _where_ I wrote a single complaint about
software _prices_ in this thread.

>
> > musicxml seems like designed to be a fake standard. Is is not
> > suitable for real usage.
>
> Like most of these "ML" standards, isn't Music XML developed by a
> basically open community? So why would they knowingly make a "fake"
> standard? Do you really think that standards people set out to make
> something that isn't useful, at least for some restricted purposes?

My criticisms were addressed to the lack of transparency and
flexibility to inter-operate with the _native_ secret formats of
certain software.

Then, I pointed out that -- in my opinion, of course -- those
supported open formats cannot solve, in a satisfactory way, that
inter-operability problem for the end user (in special the composer).

> Just
> because it isn't as flexible as paper & pencil doesn't mean it won't
work
> for some musicians for some purposes.

Indeed. Aaron and I were concerning to certain special purposes, and
how those purposes could (or not) be arrived by using certain programs.

> When was the last time you personally
> tried to solve all music notation problems in one big software system?

Why should I do it? Why should anyone do it?

I am extending the possibilities of use of _existing_ free software,
which uses _open_ formats, rather than building a new big software
system from scratch.

Complex tasks should be split in manageable parts; these parts may be
worked out by different people, and their programs, using
inter-operable formats, may be combined in a harmonic way to
accomplish that complex task.

Several free/open-source projects work this way. Recall: we had
Xwindow, we had LaTeX, we had Emacs, then GNU Bash, GCC, GhostScript,
then Linux, ALSA, Jack... at the end, we have a complete software
system for both general and specific use. Why should anyone write a
complete OS and software collection from scratch? There are people
that do it, but it is not necessary for most of us. Ask Richard
Stallman why the ``GNU Hurd'' kernel is not a high priority for Free
Software Foundation and he will reply: why we already have a free
kernel we can use.

Therefore, I would not spent time writting a complete new notation
software when I can explore to its limits a very good existing program
-- abcm2ps. I am doing just what I need (and can) do.

> Why not joint the Music XML development community and work on making
it better?

That might be a possibility if at least I had the required expertise
for that.

Anyway, as far as I can do within my limitations, I do test software
programs, I do send bug reports, I do send suggestions to developers,
I follow and share information in some userlists.

The time and effort I devote to such activities also counts, of
course, as development/maintainment/distribution/(...) cost of the
respective (free) software. And the output is available for everyone
who wish use it (and perhaps help to improve it too).

>
> Anyway, enough of that. Let's get back to the regularly scheduled
> microtonal mayhem.

OK...

Regards,
Hudson Lacerda
(Going back to microabc coding...)

>
> Rick
>

🔗Carl Lumma <carl@...>

--- In MakeMicroMusic@yahoogroups.com, Rick McGowan <rick@...> wrote:
>
> > Sure, I agree. But if you say, "Who wants to write software?
> > Only freaks" (as you seemed to say earlier), I'm going to say..
>
> Wait a minute. I said no such thing. Please re-read. And I
> certainly didn't use the word "freaks"!

That's why I put it in single quotes.

> What I said was, in effect, that companies who make end-user
> products don't necessarily want the support burden that comes
> with opening their file formats to the vanishingly small
> percentage of "users" who want to diddle them.

They don't have to support the diddling.

> Most users just want to use the software in the intended
> manner. And unless a platform changes out from under
> them -- not the fault of the music software maker -- they
> can continue to use the software and their data.

Yes, this is what I was trying to get at with my freaks
remark. The idea of software as a one-way tool is exactly
what I'm on about. It's been a useful paradigm, but I
can imagine a world where users are software literate, and
they interact with and plug together their software in
deep ways. If you read a blog like Create Digital Music,
you know there is a growing body of musicians who DO do
this. Cycling74 doesn't support my Max scripts, but they
do support Max itself.

> > When a
> > disruptive technology like literacy or computer programming
> > comes along, I really do think that it's so powerful that you
> > either control it or are controlled by those who do. And I'm
> > not looking forward to a 'clergy' of programmers.
>
> Hmmm, well... Programming is difficult enough to learn and
> practice that while it's theoretically open to all, not everyone
> has the perseverance to actually do it.

You could say the same thing about reading and writing. Actually
many cultures do not have a written language, or if they do,
it's sort of a separate thing from the spoken language (Chinese
for example). Even in the West our writing system is only
a rough approximation of how we speak. The problems with
tone-of-voice in e-mail are case and point. Similarly,
programming is only a rough approximation of how we think. But
if I suddenly invented a black box that could do whatever you
could think of, that'd be pretty amazing. And if half of the
Earth's six billion people carried the boxes in their pockets,
that'd be even more amazing. Except the boxes weren't doing
anything the people could think of, they were only doing what
a small subset of people thought of. That's the sad situation
we're in. Sad not because the small group are despots, but sad
because what they can think of is not NEARLY as amazing as what
everybody could think of. The Church was not evil, but by
keeping literacy a secret it set civilization back 1,000 years.
The protestants started by holding church services in a language
they could understand!

Seymour Papert, in his book Mindstorms, suggested that the
language learning skills of children can and should also tackle
programming languages. And he demonstrated elementary school
kids could learn a simple but Turing-complete language called
Logo, and use it to study problems in geometry, and to create
art, and...

> But there isn't any secret cabal of programmers who are
> trying to form a clergy and disallow anyone from learning it...

No. Nor would I say the early church was a secret conspiracy.
It's just economics. And we do have the power to create
markets that do what we want, if we can figure out how.

> It's not the fault of company X that they make something that
> isn't portable to the next generation of operating system (or
> hardware, or whatever)... That is a side-effect of the general
> problem that our tools keep changing incompatibly. As they get
> "better" some things get left behind.

It's not their fault, but it's their fault for not doing
everything they can to help people help themselves. It's no
different with books. What percentage of books published in
1910 have any value at all to a modern reader? 1810? 1010?
Ideas move fast, and they're moving faster than ever. This
is a good thing. The ideas even provide technologies that
let us keep up. Software can be copied and updated and kept
current. New interfaces can talk to old APIs. But they can't
if there's some otherwise-unnecessary cultural or practical
gumming up the works.

-Carl

🔗John Loffink <jloffink@...>

🔗Graham Breed <gbreed@...>

🔗Carl Lumma <carl@...>

🔗Graham Breed <gbreed@...>

🔗Carl Lumma <carl@...>

🔗Graham Breed <gbreed@...>

🔗Carl Lumma <carl@...>

🔗hfmlacerda <hfmlacerda@...>

Hi Graham,

--- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
[...]
> The 9 note magic notation, which will generalize to any
> temperament with 225:224 as a unison vector and these
> nominals (use fixed-width font for maximum satisfaction):
>
> * 5/3
> *-----------------14/9---------------------
> * 35/24
> *- - - - - - - - - - - - - - - - - - - - -
> * 4/3
> *------------------5/4---------------------
> * 7/6
> *- - - - - - - - - - - - - - - - - - - - -
> * 16/15
> *------------------1/1---------------------
> * 14/15
>
> Relative to that you can use whatever sagittal accidentals
> you need. My best idea for a name is "tripod notation"
> because you can think of it as three feet each with three toes.

It looks feasible.

For a scale with no accidentals, seems easy to do.

If you want to mix conventional staves with special ones in a single
staves system, it is not so easy, but it can be done for sure.

If the ratios are intended to be printed, we just replace the note
heads (automatically, of course), as in this example, inspired by a
tablature by Dante Rosati:
http://br.geocities.com/hfmlacerda/abc/ratios.pdf

For a coincidence, just two days ago I was reading this page, and
trying to figure out how to implement it in microabc:
http://x31eq.com/decimal_notation.htm

I could not yet find a general way to implement the version with
accidentals with microabc. There is a conflict with ABC pitch
positions (octaves as 3.5 interlines) and the pitch positions of a
10-notes scale (octaves as 4 interlines). One need to output, for
instance "E" for the first line (pc 0), and "f" for the fifth line,
and then "a" is pc 0 again. microabc can do a ``diatonic'' mapping of
pitches, but then every note would use a different staff position,
thus one could not use accidentals.

We could though write a small specialised program to generate the
microabc input file while I try finding a good general solution for
special staves.

This is an example of special staves made with microabc and abcm2ps.
As you can see, it uses lines with different widths and also dashed lines:
http://br.geocities.com/hfmlacerda/abc/special.pdf

>
> The simplest way of getting it to work with an existing
> notation engine is to use the normal 5 lines but print two
> of them dotted, and use custom key signatures. There also
> has to be a different mapping from note names to staff
> positions which maybe a pre-processor could handle. (I
> don't know what to call the nominals. They're numbered 1 to
> 9 for now. Is there anything like ABC for numerical
> notation?) Ideally the note spacing should be optimized to
> bring notes either side of the dotted line closer together.
[...]

The next release of microabc will include a basic miracle (10 pcs)
example.

This is a simple "ABC for numerical notation" code:

X:1
T:Miracle example
K:C clef=treble
[8,][9,] \
[0][1][2][3] \
[4][5][6] \
[7][8][9] \
[0'][1'][2']

Here is an excerpt of the corresponding pure ABC output, using a
microabc file not shown here:

X:1
T:Miracle example
K:C clef=treble
B,C \
DEFG \
ABc \
def \
gab

Here is a PDF of it:
http://br.geocities.com/hfmlacerda/abc/MiracleExample.pdf

Cheers,
Hudson

🔗Aaron Andrew Hunt <aaronhunt@...>

Dear Hudson,

The obvious question for me is: can microabc be tweaked to
do MegaScore notation? From your description I assume so,
but for really good output both on screen and in pdf, staff
lines not only vary in thickness but also in luminosity, so
some staff lines are greyscale rather than black.

The really powerful utility would be abc translation between
sagittal scripts and megascore scripts.

One thing I notice with both abc output and lilypond output
is that ledger lines are of incorrect thickness. They should be
the same thickness as staff lines, but in both abc and
lilypond, they are about 3 times thicker. This is surprising
for lilypond when their creators make such bold claims
about typesetting propriety in their "essay".

Anyway, if it can be done and you are interested, please
let's discuss off-list about megascore implementation in
microabc.

Cheers,
Aaron Hunt
H-Pi Instruments

--- In MakeMicroMusic@yahoogroups.com, "hfmlacerda" <hfmlacerda@...> wrote:
>
> Hi Graham,
>
> --- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@> wrote:
> [...]
> > The 9 note magic notation, which will generalize to any
> > temperament with 225:224 as a unison vector and these
> > nominals (use fixed-width font for maximum satisfaction):
> >
> > * 5/3
> > *-----------------14/9---------------------
> > * 35/24
> > *- - - - - - - - - - - - - - - - - - - - -
> > * 4/3
> > *------------------5/4---------------------
> > * 7/6
> > *- - - - - - - - - - - - - - - - - - - - -
> > * 16/15
> > *------------------1/1---------------------
> > * 14/15
> >
> > Relative to that you can use whatever sagittal accidentals
> > you need. My best idea for a name is "tripod notation"
> > because you can think of it as three feet each with three toes.
>
> It looks feasible.
>
> For a scale with no accidentals, seems easy to do.
>
> If you want to mix conventional staves with special ones in a single
> staves system, it is not so easy, but it can be done for sure.
>
> If the ratios are intended to be printed, we just replace the note
> heads (automatically, of course), as in this example, inspired by a
> tablature by Dante Rosati:
> http://br.geocities.com/hfmlacerda/abc/ratios.pdf
>
> For a coincidence, just two days ago I was reading this page, and
> trying to figure out how to implement it in microabc:
> http://x31eq.com/decimal_notation.htm
>
> I could not yet find a general way to implement the version with
> accidentals with microabc. There is a conflict with ABC pitch
> positions (octaves as 3.5 interlines) and the pitch positions of a
> 10-notes scale (octaves as 4 interlines). One need to output, for
> instance "E" for the first line (pc 0), and "f" for the fifth line,
> and then "a" is pc 0 again. microabc can do a ``diatonic'' mapping of
> pitches, but then every note would use a different staff position,
> thus one could not use accidentals.
>
> We could though write a small specialised program to generate the
> microabc input file while I try finding a good general solution for
> special staves.
>
> This is an example of special staves made with microabc and abcm2ps.
> As you can see, it uses lines with different widths and also dashed lines:
> http://br.geocities.com/hfmlacerda/abc/special.pdf
>
> >
> > The simplest way of getting it to work with an existing
> > notation engine is to use the normal 5 lines but print two
> > of them dotted, and use custom key signatures. There also
> > has to be a different mapping from note names to staff
> > positions which maybe a pre-processor could handle. (I
> > don't know what to call the nominals. They're numbered 1 to
> > 9 for now. Is there anything like ABC for numerical
> > notation?) Ideally the note spacing should be optimized to
> > bring notes either side of the dotted line closer together.
> [...]
>
> The next release of microabc will include a basic miracle (10 pcs)
> example.
>
> This is a simple "ABC for numerical notation" code:
>
> X:1
> T:Miracle example
> K:C clef=treble
> [8,][9,] \
> [0][1][2][3] \
> [4][5][6] \
> [7][8][9] \
> [0'][1'][2']
>
> Here is an excerpt of the corresponding pure ABC output, using a
> microabc file not shown here:
>
> X:1
> T:Miracle example
> K:C clef=treble
> B,C \
> DEFG \
> ABc \
> def \
> gab
>
> Here is a PDF of it:
> http://br.geocities.com/hfmlacerda/abc/MiracleExample.pdf
>
> Cheers,
> Hudson
>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗kraiggrady@...

The question of luminosity on screen makes me question whether someone is reading scores off a screen. or why is this a concern for you

-----Original Message-----
From: Aaron Andrew Hunt [mailto:aaronhunt@...]
Sent: Tuesday, January 8, 2008 11:38 AM
To: MakeMicroMusic@yahoogroups.com
Subject: [MMM] Re: For Windows/DOS users: microabc.exe

Dear Hudson,

The really powerful utility would be abc translation between
sagittal scripts and megascore scripts.

Anyway, if it can be done and you are interested, please
let's discuss off-list about megascore implementation in
microabc.

Cheers,
Aaron Hunt
H-Pi Instruments

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

🔗aum <aum@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

Hi Kraig,

I should have said "contrast" rather than "luminosity". I was
referring to grey scale. But, since you mention it, grey scale
staff lines do present a small problem for viewing music
on a computer screen, because luminosity can change with
the viewing angle, making relative grey scales difficult to
distinguish. I think new technologies are improving this
problem, however.

Cheers,
Aaron Hunt
H-Pi Instruments

--- In MakeMicroMusic@yahoogroups.com, kraiggrady@... wrote:
>
> The question of luminosity on screen makes me question whether someone is reading
scores off a screen. or why is this a concern for you
>
> -----Original Message-----
> From: Aaron Andrew Hunt [mailto:aaronhunt@...]
> Sent: Tuesday, January 8, 2008 11:38 AM
> To: MakeMicroMusic@yahoogroups.com
> Subject: [MMM] Re: For Windows/DOS users: microabc.exe
>
> Dear Hudson,
>
> The obvious question for me is: can microabc be tweaked to
> do MegaScore notation? From your description I assume so,
> but for really good output both on screen and in pdf, staff
> lines not only vary in thickness but also in luminosity, so
> some staff lines are greyscale rather than black.
>
> The really powerful utility would be abc translation between
> sagittal scripts and megascore scripts.
>
> One thing I notice with both abc output and lilypond output
> is that ledger lines are of incorrect thickness. They should be
> the same thickness as staff lines, but in both abc and
> lilypond, they are about 3 times thicker. This is surprising
> for lilypond when their creators make such bold claims
> about typesetting propriety in their "essay".
>
> Anyway, if it can be done and you are interested, please
> let's discuss off-list about megascore implementation in
> microabc.
>
> Cheers,
> Aaron Hunt
> H-Pi Instruments
>
> --- In MakeMicroMusic@yahoogroups.com, "hfmlacerda" <hfmlacerda@> wrote:
> >
> > Hi Graham,
> >
> > --- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@> wrote:
> > [...]
> > > The 9 note magic notation, which will generalize to any
> > > temperament with 225:224 as a unison vector and these
> > > nominals (use fixed-width font for maximum satisfaction):
> > >
> > > * 5/3
> > > *-----------------14/9---------------------
> > > * 35/24
> > > *- - - - - - - - - - - - - - - - - - - - -
> > > * 4/3
> > > *------------------5/4---------------------
> > > * 7/6
> > > *- - - - - - - - - - - - - - - - - - - - -
> > > * 16/15
> > > *------------------1/1---------------------
> > > * 14/15
> > >
> > > Relative to that you can use whatever sagittal accidentals
> > > you need. My best idea for a name is "tripod notation"
> > > because you can think of it as three feet each with three toes.
> >
> > It looks feasible.
> >
> > For a scale with no accidentals, seems easy to do.
> >
> > If you want to mix conventional staves with special ones in a single
> > staves system, it is not so easy, but it can be done for sure.
> >
> > If the ratios are intended to be printed, we just replace the note
> > heads (automatically, of course), as in this example, inspired by a
> > tablature by Dante Rosati:
> > http://br.geocities.com/hfmlacerda/abc/ratios.pdf
> >
> > For a coincidence, just two days ago I was reading this page, and
> > trying to figure out how to implement it in microabc:
> > http://x31eq.com/decimal_notation.htm
> >
> > I could not yet find a general way to implement the version with
> > accidentals with microabc. There is a conflict with ABC pitch
> > positions (octaves as 3.5 interlines) and the pitch positions of a
> > 10-notes scale (octaves as 4 interlines). One need to output, for
> > instance "E" for the first line (pc 0), and "f" for the fifth line,
> > and then "a" is pc 0 again. microabc can do a ``diatonic'' mapping of
> > pitches, but then every note would use a different staff position,
> > thus one could not use accidentals.
> >
> > We could though write a small specialised program to generate the
> > microabc input file while I try finding a good general solution for
> > special staves.
> >
> > This is an example of special staves made with microabc and abcm2ps.
> > As you can see, it uses lines with different widths and also dashed lines:
> > http://br.geocities.com/hfmlacerda/abc/special.pdf
> >
> > >
> > > The simplest way of getting it to work with an existing
> > > notation engine is to use the normal 5 lines but print two
> > > of them dotted, and use custom key signatures. There also
> > > has to be a different mapping from note names to staff
> > > positions which maybe a pre-processor could handle. (I
> > > don't know what to call the nominals. They're numbered 1 to
> > > 9 for now. Is there anything like ABC for numerical
> > > notation?) Ideally the note spacing should be optimized to
> > > bring notes either side of the dotted line closer together.
> > [...]
> >
> > The next release of microabc will include a basic miracle (10 pcs)
> > example.
> >
> > This is a simple "ABC for numerical notation" code:
> >
> > X:1
> > T:Miracle example
> > K:C clef=treble
> > [8,][9,] \
> > [0][1][2][3] \
> > [4][5][6] \
> > [7][8][9] \
> > [0'][1'][2']
> >
> > Here is an excerpt of the corresponding pure ABC output, using a
> > microabc file not shown here:
> >
> > X:1
> > T:Miracle example
> > K:C clef=treble
> > B,C \
> > DEFG \
> > ABc \
> > def \
> > gab
> >
> > Here is a PDF of it:
> > http://br.geocities.com/hfmlacerda/abc/MiracleExample.pdf
> >
> > Cheers,
> > Hudson
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

🔗kraiggrady@...

I guess i was following up on the idea of whether people read music from a computer screen directly or not.
i always read it off of paper and PDF seems like a good format, but seemed to be not up to par to someone, i forgot who, in this thread.
It is an interesting idea in the sense that someone could do a score say in something like flash that might give one choices over what was available on the screen at any one time.
In example, play this note, these before it dissappears off the screen. maybe DVD might be better in order to see it on a large screen.

On another issue on whether one can or cannot program, i can only say that composing music i find difficult enough and requires for me extremely long periods of concentrated effort. As ilike to follow an idea quite a way down a path before i commit to working with material mainly just so the activity can hold my own attention by it worth. I can not see how one would have the time to do both without something being sacrificed down the line. maybe one after another.

I can think of other worthwhile sofeware designs, for instance something that could show all the constant structures of a scale (since i am interested in scales of unequal size steps) down to the second or third layer and from there be able to choose tones and show all the scales and subscales where it is found. This seems like a fairly easy thing to do but have yet to find something that will do it.
Frankly i would be fine with just the last feature.

-----Original Message-----
From: Aaron Andrew Hunt [mailto:aaronhunt@...]
Sent: Tuesday, January 8, 2008 05:54 PM
To: MakeMicroMusic@yahoogroups.com
Subject: [MMM] Re: For Windows/DOS users: microabc.exe

Hi Kraig,

Cheers,
Aaron Hunt
H-Pi Instruments

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

🔗Graham Breed <gbreed@...>

hfmlacerda wrote:
> Hi Graham,
> > --- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
> [...]
>> The 9 note magic notation, which will generalize to any >> temperament with 225:224 as a unison vector and these >> nominals (use fixed-width font for maximum satisfaction):
>>
>> * 5/3
>> *-----------------14/9---------------------
>> * 35/24
>> *- - - - - - - - - - - - - - - - - - - - -
>> * 4/3
>> *------------------5/4---------------------
>> * 7/6
>> *- - - - - - - - - - - - - - - - - - - - -
>> * 16/15
>> *------------------1/1---------------------
>> * 14/15
>>
>> Relative to that you can use whatever sagittal accidentals >> you need. My best idea for a name is "tripod notation" >> because you can think of it as three feet each with three toes.
> > It looks feasible.
> > For a scale with no accidentals, seems easy to do.

Well, a scale with no accidentals isn't *that* useful...

> If you want to mix conventional staves with special ones in a single
> staves system, it is not so easy, but it can be done for sure.

I can't foresee that, except that I'll want to show the same example in different notations. But I'd make each one a different image anyway.

If I use it in anger, though, I'd expect to mix it with percussion notation. Maybe that isn't a "single staves system" though.

> If the ratios are intended to be printed, we just replace the note
> heads (automatically, of course), as in this example, inspired by a
> tablature by Dante Rosati:
> http://br.geocities.com/hfmlacerda/abc/ratios.pdf

That could certainly be useful for explanatory purposes!

> For a coincidence, just two days ago I was reading this page, and
> trying to figure out how to implement it in microabc:
> http://x31eq.com/decimal_notation.htm
> > I could not yet find a general way to implement the version with
> accidentals with microabc. There is a conflict with ABC pitch
> positions (octaves as 3.5 interlines) and the pitch positions of a
> 10-notes scale (octaves as 4 interlines). One need to output, for
> instance "E" for the first line (pc 0), and "f" for the fifth line,
> and then "a" is pc 0 again. microabc can do a ``diatonic'' mapping of
> pitches, but then every note would use a different staff position,
> thus one could not use accidentals.

I don't follow this. Are you saying ABC expects the note names to repeat for normal octaves?

> We could though write a small specialised program to generate the
> microabc input file while I try finding a good general solution for
> special staves.

And here you're suggesting a pre-processor to substitute normal names? That's fine if it works. In general, of course, we'll need to handle numbers of lines other than 5.

> This is an example of special staves made with microabc and abcm2ps.
> As you can see, it uses lines with different widths and also dashed lines:
> http://br.geocities.com/hfmlacerda/abc/special.pdf

That looks good! How about my recent evil plan of different colored lines?

> The next release of microabc will include a basic miracle (10 pcs)
> example.
> > This is a simple "ABC for numerical notation" code:
> > X:1
> T:Miracle example
> K:C clef=treble
> [8,][9,] \
> [0][1][2][3] \
> [4][5][6] \
> [7][8][9] \
> [0'][1'][2']

Okay, that works.

The clef should be an arabic numeral, as under "Absolute Pitch" on the web page you have. So a treble clef could be either 4 or 5.

> Here is an excerpt of the corresponding pure ABC output, using a
> microabc file not shown here:
> > X:1
> T:Miracle example
> K:C clef=treble
> B,C \
> DEFG \
> ABc \
> def \
> gab
> > Here is a PDF of it:
> http://br.geocities.com/hfmlacerda/abc/MiracleExample.pdf

That looks good, but then it looks exactly like conventional notation without the accidentals and clef symbol!

There's one other thing, though. I think the [0'] at the top should be slightly raised, and maybe written below a leger line. This is to emphasize that it belongs with the other clef, and that there's a larger interval in the nominals here. I can see that this isn't how I write on paper, but it is what I expected the printed version to look like. At least, it looks strange to me that the leger lines are so close to the core stave.

Graham

🔗Herman Miller <hmiller@...>

🔗hfmlacerda <hfmlacerda@...>

--- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> hfmlacerda wrote:
[...]
> > If you want to mix conventional staves with special ones in a single
> > staves system, it is not so easy, but it can be done for sure.
>
> I can't foresee that, except that I'll want to show the same
> example in different notations. But I'd make each one a
> different image anyway.
>
> If I use it in anger, though, I'd expect to mix it with
> percussion notation. Maybe that isn't a "single staves
> system" though.

I've wrote: not _so_ easy, but still feasible. There are not problems
in using other staves, this would just take a bit more of time to set up.

[...]
> > I could not yet find a general way to implement the version with
> > accidentals with microabc. There is a conflict with ABC pitch
> > positions (octaves as 3.5 interlines) and the pitch positions of a
> > 10-notes scale (octaves as 4 interlines). One need to output, for
> > instance "E" for the first line (pc 0), and "f" for the fifth line,
> > and then "a" is pc 0 again. microabc can do a ``diatonic'' mapping of
> > pitches, but then every note would use a different staff position,
> > thus one could not use accidentals.
>
> I don't follow this. Are you saying ABC expects the note
> names to repeat for normal octaves?

It is not easy to explain, as it has to do with current microabc
features. But the basic idea is that the _output_ ABC file will use
"normal" pitches (which repeat at octaves) in different meanings.

>
> > We could though write a small specialised program to generate the
> > microabc input file while I try finding a good general solution for
> > special staves.
>
> And here you're suggesting a pre-processor to substitute
> normal names? That's fine if it works. In general, of
> course, we'll need to handle numbers of lines other than 5.

Yes, that is the idea. The funny part is that microabc _is_ a
preprocessor, but it cannot still do _that_ specific kind of task. The
input file will need be, to say, very detailed :-)

>
> > This is an example of special staves made with microabc and abcm2ps.
> > As you can see, it uses lines with different widths and also
dashed lines:
> > http://br.geocities.com/hfmlacerda/abc/special.pdf
>
> That looks good! How about my recent evil plan of different
> colored lines?

No problem. Here is an example I wrote for Aaron Hunt:
http://br.geocities.com/hfmlacerda/abc/megascore.pdf
It uses grayscale, but could use colors as well.

[...]
> > Here is a PDF of it:
> > http://br.geocities.com/hfmlacerda/abc/MiracleExample.pdf
>
> That looks good, but then it looks exactly like conventional
> notation without the accidentals and clef symbol!

Your basic description leads to that...

The clef-number and other tweaks might help.

>
> There's one other thing, though. I think the [0'] at the
> top should be slightly raised, and maybe written below a
> leger line. This is to emphasize that it belongs with the
> other clef, and that there's a larger interval in the
> nominals here. I can see that this isn't how I write on
> paper, but it is what I expected the printed version to look
> like. At least, it looks strange to me that the leger lines
> are so close to the core stave.

You wrote before that the note heads should be placed in inequal
vertical distances. Maybe we can do something like that Bohlen example.

Have you a graphical sample of what you want?

Hudson

🔗Graham Breed <gbreed@...>

hfmlacerda wrote:

> It is not easy to explain, as it has to do with current microabc
> features. But the basic idea is that the _output_ ABC file will use
> "normal" pitches (which repeat at octaves) in different meanings.

Maybe an accidental applied to one note will get inherited by a completely unrelated note that's supposed to be an octave equivalent?

>>> We could though write a small specialised program to generate the
>>> microabc input file while I try finding a good general solution for
>>> special staves.
>> And here you're suggesting a pre-processor to substitute >> normal names? That's fine if it works. In general, of >> course, we'll need to handle numbers of lines other than 5.
> > Yes, that is the idea. The funny part is that microabc _is_ a
> preprocessor, but it cannot still do _that_ specific kind of task. The
> input file will need be, to say, very detailed :-)

And I see you wrote it in C! How courageous ;-)

>>> This is an example of special staves made with microabc and abcm2ps.
>>> As you can see, it uses lines with different widths and also
> dashed lines:
>>> http://br.geocities.com/hfmlacerda/abc/special.pdf
>> That looks good! How about my recent evil plan of different >> colored lines?
> > No problem. Here is an example I wrote for Aaron Hunt:
> http://br.geocities.com/hfmlacerda/abc/megascore.pdf
> It uses grayscale, but could use colors as well.

It confirms that dotted lines are clearer than different grayscales, at least.

> [...]
>>> Here is a PDF of it:
>>> http://br.geocities.com/hfmlacerda/abc/MiracleExample.pdf
>> That looks good, but then it looks exactly like conventional >> notation without the accidentals and clef symbol!
> > Your basic description leads to that...

Yes, I use it with normal manuscript paper. Maybe it is confusingly similar to conventional notation, because seeing this formally typeset I naturally think of it conventionally.

> The clef-number and other tweaks might help.

We'll see!

>> There's one other thing, though. I think the [0'] at the >> top should be slightly raised, and maybe written below a >> leger line. This is to emphasize that it belongs with the >> other clef, and that there's a larger interval in the >> nominals here. I can see that this isn't how I write on >> paper, but it is what I expected the printed version to look >> like. At least, it looks strange to me that the leger lines >> are so close to the core stave.
> > You wrote before that the note heads should be placed in inequal
> vertical distances. Maybe we can do something like that Bohlen example.

That was for tripod notation, but the same principle applies to decimal. The interval between 0.9 and 1.0 is 9 steps of 72, but all the other decimal steps are 7/72. So the visual distance between notes 0.9 and 1.0 should logically be 29% greater than the distance between 0.8 and 0.9, etc. Logic may not give the right results, but let's try that.

The Bohlen example looks like it does all the basic things in terms of custom spacing. I'm wondering about raising note 9 of the tripod notation from 5/3 to, er, 12/7. It means magic22 can be written with one accidental pair, the gap between staves isn't so drastic, and also the nominals contain only two step sizes in orwell (but still aren't the MOS). Anyway, the solid line followed by dotted line might be a way of showing that one interval's supposed to be a bit larger. It'd be the other way up from the Bohlen but same idea.

FWIW, here's the spacing of nominals for the original, symmetric tripod in various equal temperaments:

1 2 3 4 5 6 7 8 9 1'
2 2 2 2 2 2 2 2 3 /19
2 2 3 2 2 3 2 2 4 /22
3 3 4 3 3 4 3 3 5 /31
4 4 5 4 4 5 4 4 7 /41

and here's the modified scale:

1 2 3 4 5 6 7 8 9 1'
2 2 2 2 2 2 2 3 2 /19
2 2 3 2 2 3 2 3 3 /22
3 3 4 3 3 4 3 4 4 /31
4 4 5 4 4 5 4 6 5 /41

an alternative is to lower note 1 instead:

1 2 3 4 5 6 7 8 9 1'
3 2 2 2 2 2 2 2 2 /19
3 2 3 2 2 3 2 2 3 /22
4 3 4 3 3 4 3 3 4 /31
6 4 5 4 4 5 4 4 5 /41

The benchmark tuning, at least for magic, is 41-equal.

> Have you a graphical sample of what you want?

No, that's what I need the customized notation program for!

Graham

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

🔗Graham Breed <gbreed@...>

J.A.Martin Salinas wrote:

> I worked on a 96ET(EDO) staff for the 'conic bellophone'
> not using accidentals, so the chromatic passages look
> almost like graphs!!!
> > I had to use 3 colours to make it intuitive and after so
> much time invested the percussionist I work with told
> me he is colour blinded and that he would appreciate
> no use of colour with the scores.

Ah, but if he was colour blind, how did he know you were using colours?

> He is still the best I could find in Europe and I am sure
> that no matter if I find one almost as good as him it will
> not play better than him by using colours with the scores.

I think received wisdom is not to use colours, so I tread carefully. But I'm only suggesting the staff lines be coloured in a purely redundant way. Everything else is would still be black and if you can't see the colours you can still understand it.

> I am not sure, but I know many people who are colour
> blinded and I am only guessing but I think you may find
> that one in 10 or 20 musicians might be colour blinded too.

Very few people can see no colours at all. The commonest form, in men, is red-green blindness. You can still choose a set of colours that are distinct for such people. And the important thing for my purposes is that the staff has a distinctive look -- if some people confuse a few lines it doesn't greatly matter.

Another consideration is that it should still work printed in black and white.

> At this stage I am happy to share it with the programmers
> that may be interested in case they can come up with
> a solution, since I am preparing scores for a new ensemble
> piece and we might be able to help each other!
> > By the way Graham, around this time you must be sleeping
> with your coat there in China, right?

No, but I have two duvets and keep my underwear on.

> Anyhow Graham I would love to see your coloured
> lines to see what you came up with!

The idea is that each pair of notes in the decimal scale is associated with an element, and the corresponding line coloured according to this association. The traditional ordering of elements (from the 10 heavenly stems) is:

wood fire earth metal water

For now I'll suggest colours:

black red green orange blue

You can also extend this to diatonic scales by following days of the week, and using new colours for the sun and moon. That way different clefs on a conventional staff will lead to different colourings -- and maybe key changes as well. That may or may not be something people will find useful...

Graham

🔗hfmlacerda <hfmlacerda@...>

Hi Graham,

--- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>
> hfmlacerda wrote:
>
> > It is not easy to explain, as it has to do with current microabc
> > features. But the basic idea is that the _output_ ABC file will use
> > "normal" pitches (which repeat at octaves) in different meanings.
>
> Maybe an accidental applied to one note will get inherited
> by a completely unrelated note that's supposed to be an
> octave equivalent?

Yes. If you say: replace [0] with (ABC) "D", [1] with "E", and so on,
eventually you would replace [0'] with "g", but microabc will just
think that [0'] is "d". With no accidental, no problem. But with
accidentals, you should tell microabc what are _all_ the replacements
in the range you need:

alias:0
replaceabc:1
{...}
v8, _B,
8, B,
^8, ^B,
_9, _C
9, C
^9, ^C
_0 _D
0 D
^0 ^D
{...}
_0' _g
0' g
^0' ^g
{...}

If you make a list like that above (by hand, or by using a script),
you are done.

> And I see you wrote it in C! How courageous ;-)

Is there any easier way? ;-)

> >>> http://br.geocities.com/hfmlacerda/abc/special.pdf
> > http://br.geocities.com/hfmlacerda/abc/megascore.pdf
> > It uses grayscale, but could use colors as well.
>
> It confirms that dotted lines are clearer than different
> grayscales, at least.

Indeed. The gray lines of megascore.pdf look bad on my computer, they
are shown in several different widths on the screen (with xpdf). The
PostScript version of the same file looks much better (with gv). OTOH,
the dotted lines in special.pdf always look nice.

[...]
> > You wrote before that the note heads should be placed in inequal
> > vertical distances. Maybe we can do something like that Bohlen
example.
>
> That was for tripod notation, but the same principle applies
> to decimal. The interval between 0.9 and 1.0 is 9 steps of
> 72, but all the other decimal steps are 7/72. So the visual
> distance between notes 0.9 and 1.0 should logically be 29%
> greater than the distance between 0.8 and 0.9, etc. Logic
> may not give the right results, but let's try that.

More difficult.

>
> The Bohlen example looks like it does all the basic things
> in terms of custom spacing.

But that case all pitches are equally spaced in the vertical axis.

> I'm wondering about raising
> note 9 of the tripod notation from 5/3 to, er, 12/7. It
> means magic22 can be written with one accidental pair, the
> gap between staves isn't so drastic, and also the nominals
> contain only two step sizes in orwell (but still aren't the
> MOS). Anyway, the solid line followed by dotted line might
> be a way of showing that one interval's supposed to be a bit
> larger. It'd be the other way up from the Bohlen but same idea.
>
> FWIW, here's the spacing of nominals for the original,
> symmetric tripod in various equal temperaments:
>
> 1 2 3 4 5 6 7 8 9 1'
> 2 2 2 2 2 2 2 2 3 /19
> 2 2 3 2 2 3 2 2 4 /22
[...]

I don't expect that using inequal pitch distances will work (we are
changing only the graphics of the staff, not the notes). You can,
anyway, use equal distances, but leaving some places empty. Inspect
carefully the vertical distances in the Bohlen example.

> > Have you a graphical sample of what you want?
>
> No, that's what I need the customized notation program for!

Do you have any experience with PostScript language?

The file bp.fmt inside the folder examples/bohlen/ of microabc package
defines the customised staff.

I am now more interested in providing the microabc interface to
replace the nominals (possibly with accidentals) for special staff
mappings.

It could use a syntax like this:

alias: 0
{} replaceabcnom: 1
replacesagittalnom: 2
_0 _[0] [0]v
0 [0] [0]
^0 ^[0] [0]^

Cheers,
Hudson

🔗George D. Secor <gdsecor@...>

--- In MakeMicroMusic@yahoogroups.com, aum <aum@...> wrote:
>
> Thank you for the information and picture. Is it possible to get a
> publishable picture of whole instrument somehow?

I can't get a suitable picture for you at present, because the
instrument I have access to is surrounded by too much clutter. I'll
have to search through my film negatives to see if there's anything
you can use, and if so, we'll need to have that scanned.

> Just for proper credits: are you the author of the generalized
keyboard
> only or of the whole Scalatron basic idea and technology?
> Milan

I gave the answer to that here:
/makemicromusic/topicId_18251.html#18279
and more details in another link in that message:
/tuning/topicId_39323.html#39407
but perhaps I should give still more details, since you're intending
to publish this information.

Herman Pedtke got the idea for the Scalatron from drum machines such
as the Wurlitzer Sideman, which allowed the user to program rhythm.
He thought that if rhythm could be easily programmed in an electronic
device, then why not pitch?

He discussed his idea with his friend Richard Harasek, a Motorola
employee and amateur musician, to determine whether it might be
marketable as a keyboard instrument that would allow easy
demonstration and exploration of historical, ethnic, and experimental
tunings in music history, theory, and composition classes. They sent
out a survey to numerous university music departments to determine
what level of interest there might be in such an instrument, and the
response was nothing short of phenomenal: the response rate was
around 90% and the reaction was overwhelmingly positive. (He
explained that in a typical market survey you're doing well if you
get even 10% returned.) Around 1973 the Scalatron company was set up
as a "New Ventures" subsidiary of the Motorola corporation, with Dick
Harasek as president.

I first visited the Scalatron facility in the fall of 1974, when I
explained my idea of using a special "generalized" keyboard on their
instrument in place of the two conventional keyboards. The
generalized keyboard had been invented by Robert H. M. Bosanquet in
London around 1875, but I had independently arrived at the same
arrangement of keys (but with a different key shape) and was not yet
aware that the two were essentially the same. A short time later Erv
Wilson of Los Angeles learned of our plans and informed us that the
idea was originally Bosanquet's, and he also presented his idea for
an even better (hexagonal) key shape. An elliptical key shape was
eventually adopted, because hexagons posed the aesthetic requirement
that the sides of the keys be exactly parallel. Three generalized
keyboard Scalatrons were made, each unique and having one or more
features not possessed by the other two. As you may conclude from
the second link above, the keyboard completely lived up to my
expectations.

However, Scalatron sales came nowhere near expectations, because
those individuals who answered the market survey were generally not
the same ones who controlled the purse strings of the music
department. After several years and less than two dozen Scalatrons
sold, the parent company pulled the plug on the operation.

--George

🔗Graham Breed <gbreed@...>

hfmlacerda wrote:
> Hi Graham,
> > --- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
>> hfmlacerda wrote:
>>
>>> It is not easy to explain, as it has to do with current microabc
>>> features. But the basic idea is that the _output_ ABC file will use
>>> "normal" pitches (which repeat at octaves) in different meanings.
>> Maybe an accidental applied to one note will get inherited >> by a completely unrelated note that's supposed to be an >> octave equivalent?
> > Yes. If you say: replace [0] with (ABC) "D", [1] with "E", and so on,
> eventually you would replace [0'] with "g", but microabc will just
> think that [0'] is "d". With no accidental, no problem. But with
> accidentals, you should tell microabc what are _all_ the replacements
> in the range you need:
> > alias:0
> replaceabc:1
> {...}
> v8, _B,
> 8, B,
> ^8, ^B,
> _9, _C
> 9, C
> ^9, ^C
> _0 _D
> 0 D
> ^0 ^D
> {...}
> _0' _g
> 0' g
> ^0' ^g
> {...}
> > If you make a list like that above (by hand, or by using a script),
> you are done.

That doesn't look at all difficult then.

>> And I see you wrote it in C! How courageous ;-)
> > Is there any easier way? ;-)

I don't know how deep we're going into irony here but, without checking exactly what your code's doing, it's something I'd expect to be much easier in a scripting language.

>> The Bohlen example looks like it does all the basic things >> in terms of custom spacing.
> > But that case all pitches are equally spaced in the vertical axis.

Oh, they are? It's two staves joined together then.

>> FWIW, here's the spacing of nominals for the original, >> symmetric tripod in various equal temperaments:
>>
>> 1 2 3 4 5 6 7 8 9 1'
>> 2 2 2 2 2 2 2 2 3 /19
>> 2 2 3 2 2 3 2 2 4 /22
> [...]
> > I don't expect that using inequal pitch distances will work (we are
> changing only the graphics of the staff, not the notes). You can,
> anyway, use equal distances, but leaving some places empty. Inspect
> carefully the vertical distances in the Bohlen example.

Oh, that's a shame. Well, there are four possibilities, then:

1) The obvious one, with the dotted lines representing an empty position. As it happens this implies 12 note equal temperament.

2) Take away the dotted lines, and have two note sharing a position. This is consistent with 19 note equal temperament, although the inter-staff spacing (and also leger lines) should be a bit larger. If the staff's drawn with PostScript, it should be possible to draw those dashed lines anyway, no? I think it'd help do distinguish the two notes that share a space although my requirements aren't fundamentally different to other notations that do this.

3) Use a 22 note grid with a lot of empty places. This will be fine if the notes, clef symbols, and everything else expand to compensate for the empty spaces. Unfortunately, going by you examples, this doesn't work :(

4) Represent a single tripod staff as three distinct staves, joined with arbitrary spacing as in the Bohlen example. Is this practicable?

>>> Have you a graphical sample of what you want?
>> No, that's what I need the customized notation program for!
> > Do you have any experience with PostScript language?
> > The file bp.fmt inside the folder examples/bohlen/ of microabc package
> defines the customised staff.

Oh, I know some PostScript, but this isn't immediately meaningful to me.

> I am now more interested in providing the microabc interface to
> replace the nominals (possibly with accidentals) for special staff
> mappings.
> > It could use a syntax like this:
> > alias: 0
> {} replaceabcnom: 1
> replacesagittalnom: 2
> _0 _[0] [0]v
> 0 [0] [0]
> ^0 ^[0] [0]^

That's good! See how you get on.

Graham

🔗hfmlacerda <hfmlacerda@...>

--- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
[...]
> >> And I see you wrote it in C! How courageous ;-)
> >
> > Is there any easier way? ;-)
>
> I don't know how deep we're going into irony here but,
> without checking exactly what your code's doing, it's
> something I'd expect to be much easier in a scripting language.

Indeed. It happens that I know only a few programming languages -- C,
GNU Octave, PostScript --, thus the irony: C is the easier choice _for
me_. ;-)

[...]
> > I don't expect that using inequal pitch distances will work (we are
> > changing only the graphics of the staff, not the notes). You can,
> > anyway, use equal distances, but leaving some places empty. Inspect
> > carefully the vertical distances in the Bohlen example.
>
> Oh, that's a shame. Well, there are four possibilities, then:
>
[...]
> 4) Represent a single tripod staff as three distinct staves,
> joined with arbitrary spacing as in the Bohlen example. Is
> this practicable?

Feasible, but not ideal. The user should do by hand the staff changes
in order to put the pitches on their proper positions.

LilyPond seems to do irregular staff-lines distances (line-positions):
http://lilypond.org/doc/v2.10/Documentation/user/lilypond-internals/staff_002dsymbol_002dinterface#staff_002dsymbol_002dinterface

There is yet another way (with abcm2ps), but that would not work when
mixing special and common staves: ``inteligent note heads'' could
auto-adjust their vertical offsets according to their `y' arguments.

I used such a approach to implement shaped notes (and solfa names) in ABC:
http://br.geocities.com/hfmlacerda/abc/shapednotes.pdf

[...]
> Oh, I know some PostScript, but this isn't immediately
> meaningful to me.

You might tinkering with this part:

/dist 9 def % interline (in points)

currentdict /creator known false eq {
/staff{ .8 SLW % for first line
pop 5 1 1 3 -1 roll{
5 eq {[ 1.5 ]0 setdash}if % for fifth line
0 1 index M 1 index 0 RL dist add stroke
.35 SLW
}for pop pop []0 setdash dlw}!
}
{

/staff{.8 SLW
/cont 0 def
dlw M 2 sub {
cont 4 eq {[ 1.5 ]0 setdash}if % for fifth line
cont 0 eq {.8 SLW}if % for fifth line
dup 0 RL dup neg dist RM currentpoint stroke M
[]0 setdash /cont cont 1 add def .35 SLW}repeat
pop dlw}!

}ifelse

There are two definitions of /staff, which are dependent of abcm2ps
version. For new versions (5.2.2++), the usage is

l n x y staff

l = length of the staff (width)
n = number of lines
x,y = position

For older versions (4.8.6++), the usage is:

l y n staff

The code above detects the existence (or not) of the operator /creator
(abcm2ps version) to select the proper redefinition of /staff.

Other operators used:

RM = rmoveto
RL = rlineto
M = moveto
! = bind def
SLW = setlinewidth
dlw = set default line width, something like /dlw{.7 SLW}!

BTW, I figured out another (and better) way to create special staves:
using %%tablature. That way, both special and standard staves can be
used, once /staff is not redefined.

Here is an example:
http://br.geocities.com/hfmlacerda/abc/mega2.pdf
http://br.geocities.com/hfmlacerda/abc/mega2.abc.txt

>
> > I am now more interested in providing the microabc interface to
> > replace the nominals (possibly with accidentals) for special staff
> > mappings.
> >
> > It could use a syntax like this:
> >
> > alias: 0
> > {} replaceabcnom: 1
> > replacesagittalnom: 2
> > _0 _[0] [0]v
> > 0 [0] [0]
> > ^0 ^[0] [0]^
>
> That's good! See how you get on.

I am going to implement it right now! ;-)

Cheers,
Hudson

🔗Graham Breed <gbreed@...>

hfmlacerda wrote:

> Indeed. It happens that I know only a few programming languages -- C,
> GNU Octave, PostScript --, thus the irony: C is the easier choice _for
> me_. ;-)

Well, I'll suggest learning Python could be easier than slogging away with C where it doesn't fit. But you've got an existing code base and there's a lot of C used with ABC by the looks of it. I am familiar with C (it was the focus of my master's degree) but I don't relish looking through all that code.

> [...]
>> 4) Represent a single tripod staff as three distinct staves, >> joined with arbitrary spacing as in the Bohlen example. Is >> this practicable?
> > Feasible, but not ideal. The user should do by hand the staff changes
> in order to put the pitches on their proper positions.

But a script could reassign them.

> LilyPond seems to do irregular staff-lines distances (line-positions):
> http://lilypond.org/doc/v2.10/Documentation/user/lilypond-internals/staff_002dsymbol_002dinterface#staff_002dsymbol_002dinterface

Yes, LilyPond's another thing to look at, but as you have a microtonal project let's see how far we can push it.

> There is yet another way (with abcm2ps), but that would not work when
> mixing special and common staves: ``inteligent note heads'' could
> auto-adjust their vertical offsets according to their `y' arguments.

That sounds more like it.

> You might tinkering with this part:
<snip>

Sure, something to work on, but I don't really have the time now. I have to finish my marking and find another job. Hopefully I'll have some free time before the end of the spring break.

Please look at the equal spacing versions anyway! I'm looking forward to seeing them.

Graham

🔗hfmlacerda <hfmlacerda@...>

Hi Graham,

--- In MakeMicroMusic@yahoogroups.com, Graham Breed <gbreed@...> wrote:
[...]
> Well, I'll suggest learning Python could be easier than
> slogging away with C where it doesn't fit.

Thanks for the suggestion.

[...]
> > There is yet another way (with abcm2ps), but that would not work when
> > mixing special and common staves: ``inteligent note heads'' could
> > auto-adjust their vertical offsets according to their `y' arguments.
>
> That sounds more like it.
[...]

The 24et example in microabc uses such a approach for quartertone
accidentals: for the clarinet (first staff), they print Tartini-Couper
acciddentals, and for the guitar (second staff), they print
conventional accidentals with arrows.

+++++++++

Here are my latest tryings for your special notations:
http://br.geocities.com/hfmlacerda/abc/tripod.pdf
http://br.geocities.com/hfmlacerda/abc/test-miracle.pdf

They are included at examples/miracle, in the new microabc version I
just uploaded. I didn't make settings for MIDI though.

+++++++++

A more general implementation, for arbitrary notations, would require
more effort. I have only taken a few notes for further work:

- EXTRA GENERAL SPECIAL SCALE PREPROCESSOR:

Xnewnom: <str> <interval> [<pitch class>] [<index for map>]
Create a new nominal, defining name, interval from reference
frequency, pitch class number and index for staff notation position.

Xnewacc: <str> <interval> [<microval> | <num> <den>]
Create a new accidental, with abcm2ps/abc2midi interface.

Xusesaggitalacc: <temper2> <temper3> <temper5> <temper7> <temper11>
... <temper31>
Use Saggital accidentals, which meanings are defined by tempering the
prime factors.

Xsclmod: <float>
Set equivalence interval (formal octave) for the frequencies.

Xmapsize: <int>
Set map size (repetition interval) for staff notation.

Xmapcentre: <abc pitch>
Pitch 0 is mapped to <abc pitch> for staff notation.

Xupdown: <str> <str>
Modulo (octave) instance modifiers (like '' or ,, in ABC).

Xbasefreq: <float> <int>
Reference frequency.

Xaccpos: <after | before | any>
Whether accidentals should be written after/before the nominals in
pitch names, like in N^^ or ^^N.

+++++++++

¡¡¡Viva Chávez!!!

Hudson Lacerda

🔗Graham Breed <gbreed@...>

🔗acousticsoftombak <shahinm@...>

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

Hi Shaahim! Happy New Year to you and everyone on the list too!
(for Graham a month in advance though!)

I have been following your music from the your page and enjoyed it
all, but this two pieces are very special!

Julián Carrillo would be very proud to hear that piano piece. I loved
it,
because it brings all the hidden timbres of a piano. You have to have
it recorded on an acoustic piano, and I would be so happy to include
it in a 2010 recital of 96ET that I am already planing here in Osaka.

The other piece was also very interesting and i would love to see
scores if you do happen to work with notation.

I actually tried several times to get in touch with you, but got
emails rejected, so maybe you can mail me and I can reply:

tony@tonysalinas.com

On 2008/01/11, at 15:25, acousticsoftombak wrote:

> Hi tony
>
> Happy new year!
> If you like, please have a look at:
> /makemicromusic/topicId_18254.html#18254
> to hear my five haexatonic music in 96-EDO , as you are working on
> this EDO .
>
> best wishes for you.
>
> --- In MakeMicroMusic@yahoogroups.com, "J.A.Martin Salinas"
> <tony@...> wrote:
> >
> > >
> > >
> > > That looks good! How about my recent evil plan of different
> > > colored lines?
> > >
> > >
> > Hi my dear neighbour Graham!
> >
> > I worked on a 96ET(EDO) staff for the 'conic bellophone'
> > not using accidentals, so the chromatic passages look
> > almost like graphs!!!
> >
> > I had to use 3 colours to make it intuitive and after so
> > much time invested the percussionist I work with told
> > me he is colour blinded and that he would appreciate
> > no use of colour with the scores.
> >
> > He is still the best I could find in Europe and I am sure
> > that no matter if I find one almost as good as him it will
> > not play better than him by using colours with the scores.
> >
> > I am not sure, but I know many people who are colour
> > blinded and I am only guessing but I think you may find
> > that one in 10 or 20 musicians might be colour blinded too.
> >
> > At this stage I am happy to share it with the programmers
> > that may be interested in case they can come up with
> > a solution, since I am preparing scores for a new ensemble
> > piece and we might be able to help each other!
> >
> > By the way Graham, around this time you must be sleeping
> > with your coat there in China, right?
> >
> > Anyhow Graham I would love to see your coloured
> > lines to see what you came up with!
> >
> > Tony Salinas
> >
>
>
>

🔗hfmlacerda <hfmlacerda@...>

🔗Graham Breed <gbreed@...>

🔗hfmlacerda <hfmlacerda@...>

🔗acousticsoftombak <shahinm@...>

Hi tony

Very gald to hear about 96-edo recital in 2010.
I will work on Microhex2 score to edit and extend it for your recital.
and can you tell me what is name of the second music? (-;
and i'm sorry for rejecting mails )-;
Shaahin

--- In MakeMicroMusic@yahoogroups.com, "J.A.Martin Salinas"
<tony@...> wrote:
>
> Hi Shaahim! Happy New Year to you and everyone on the list too!
> (for Graham a month in advance though!)
>
> I have been following your music from the your page and enjoyed it
> all, but this two pieces are very special!
>
> Julián Carrillo would be very proud to hear that piano piece. I
loved
> it,
> because it brings all the hidden timbres of a piano. You have to
have
> it recorded on an acoustic piano, and I would be so happy to include
> it in a 2010 recital of 96ET that I am already planing here in
Osaka.
>
> The other piece was also very interesting and i would love to see
> scores if you do happen to work with notation.
>
> I actually tried several times to get in touch with you, but got
> emails rejected, so maybe you can mail me and I can reply:
>
> tony@...
>
>
>
>
>
>
>
> On 2008/01/11, at 15:25, acousticsoftombak wrote:
>
> > Hi tony
> >
> > Happy new year!
> > If you like, please have a look at:
> > /makemicromusic/topicId_18254.html#18254
> > to hear my five haexatonic music in 96-EDO , as you are working on
> > this EDO .
> >
> > best wishes for you.
> >
> > --- In MakeMicroMusic@yahoogroups.com, "J.A.Martin Salinas"
> > <tony@> wrote:
> > >
> > > >
> > > >
> > > > That looks good! How about my recent evil plan of different
> > > > colored lines?
> > > >
> > > >
> > > Hi my dear neighbour Graham!
> > >
> > > I worked on a 96ET(EDO) staff for the 'conic bellophone'
> > > not using accidentals, so the chromatic passages look
> > > almost like graphs!!!
> > >
> > > I had to use 3 colours to make it intuitive and after so
> > > much time invested the percussionist I work with told
> > > me he is colour blinded and that he would appreciate
> > > no use of colour with the scores.
> > >
> > > He is still the best I could find in Europe and I am sure
> > > that no matter if I find one almost as good as him it will
> > > not play better than him by using colours with the scores.
> > >
> > > I am not sure, but I know many people who are colour
> > > blinded and I am only guessing but I think you may find
> > > that one in 10 or 20 musicians might be colour blinded too.
> > >
> > > At this stage I am happy to share it with the programmers
> > > that may be interested in case they can come up with
> > > a solution, since I am preparing scores for a new ensemble
> > > piece and we might be able to help each other!
> > >
> > > By the way Graham, around this time you must be sleeping
> > > with your coat there in China, right?
> > >
> > > Anyhow Graham I would love to see your coloured
> > > lines to see what you came up with!
> > >
> > > Tony Salinas
> > >
> >
> >
> >
>

🔗acousticsoftombak <shahinm@...>

Hi again tony

can you send me a photo of yourself to upload in my 96-EDO page?
please send it to:
shahinm@...
thanks

--- In MakeMicroMusic@yahoogroups.com, "acousticsoftombak"
<shahinm@...> wrote:
>
> Hi tony
>
> Very gald to hear about 96-edo recital in 2010.
> I will work on Microhex2 score to edit and extend it for your
recital.
> and can you tell me what is name of the second music? (-;
> and i'm sorry for rejecting mails )-;
> Shaahin
>
> --- In MakeMicroMusic@yahoogroups.com, "J.A.Martin Salinas"
> <tony@> wrote:
> >
> > Hi Shaahim! Happy New Year to you and everyone on the list too!
> > (for Graham a month in advance though!)
> >
> > I have been following your music from the your page and enjoyed it
> > all, but this two pieces are very special!
> >
> > Julián Carrillo would be very proud to hear that piano piece. I
> loved
> > it,
> > because it brings all the hidden timbres of a piano. You have to
> have
> > it recorded on an acoustic piano, and I would be so happy to
include
> > it in a 2010 recital of 96ET that I am already planing here in
> Osaka.
> >
> > The other piece was also very interesting and i would love to see
> > scores if you do happen to work with notation.
> >
> > I actually tried several times to get in touch with you, but got
> > emails rejected, so maybe you can mail me and I can reply:
> >
> > tony@
> >
> >
> >
> >
> >
> >
> >
> > On 2008/01/11, at 15:25, acousticsoftombak wrote:
> >
> > > Hi tony
> > >
> > > Happy new year!
> > > If you like, please have a look at:
> > >
/makemicromusic/topicId_18254.html#18254
> > > to hear my five haexatonic music in 96-EDO , as you are working
on
> > > this EDO .
> > >
> > > best wishes for you.
> > >
> > > --- In MakeMicroMusic@yahoogroups.com, "J.A.Martin Salinas"
> > > <tony@> wrote:
> > > >
> > > > >
> > > > >
> > > > > That looks good! How about my recent evil plan of different
> > > > > colored lines?
> > > > >
> > > > >
> > > > Hi my dear neighbour Graham!
> > > >
> > > > I worked on a 96ET(EDO) staff for the 'conic bellophone'
> > > > not using accidentals, so the chromatic passages look
> > > > almost like graphs!!!
> > > >
> > > > I had to use 3 colours to make it intuitive and after so
> > > > much time invested the percussionist I work with told
> > > > me he is colour blinded and that he would appreciate
> > > > no use of colour with the scores.
> > > >
> > > > He is still the best I could find in Europe and I am sure
> > > > that no matter if I find one almost as good as him it will
> > > > not play better than him by using colours with the scores.
> > > >
> > > > I am not sure, but I know many people who are colour
> > > > blinded and I am only guessing but I think you may find
> > > > that one in 10 or 20 musicians might be colour blinded too.
> > > >
> > > > At this stage I am happy to share it with the programmers
> > > > that may be interested in case they can come up with
> > > > a solution, since I am preparing scores for a new ensemble
> > > > piece and we might be able to help each other!
> > > >
> > > > By the way Graham, around this time you must be sleeping
> > > > with your coat there in China, right?
> > > >
> > > > Anyhow Graham I would love to see your coloured
> > > > lines to see what you came up with!
> > > >
> > > > Tony Salinas
> > > >
> > >
> > >
> > >
> >
>

New microabc software (31-12-2007)

🔗hfmlacerda <hfmlacerda@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Prent Rodgers <prentrodgers@...>

🔗hfmlacerda <hfmlacerda@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗hfmlacerda <hfmlacerda@...>

🔗John Loffink <jloffink@...>

🔗kraiggrady@...

🔗aum <aum@...>

🔗kraiggrady@...

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗Carl Lumma <carl@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗hfmlacerda <hfmlacerda@...>

🔗George D. Secor <gdsecor@...>

🔗George D. Secor <gdsecor@...>

🔗Carl Lumma <carl@...>

🔗Rick McGowan <rick@...>

🔗Carl Lumma <carl@...>

🔗hfmlacerda <hfmlacerda@...>

🔗George D. Secor <gdsecor@...>

🔗Rick McGowan <rick@...>

🔗Carl Lumma <carl@...>

🔗kraiggrady@...

🔗Rick McGowan <rick@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Carl Lumma <carl@...>

🔗John Loffink <jloffink@...>

🔗Graham Breed <gbreed@...>

🔗Carl Lumma <carl@...>

🔗Graham Breed <gbreed@...>

🔗Carl Lumma <carl@...>

🔗Graham Breed <gbreed@...>

🔗Carl Lumma <carl@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗kraiggrady@...

🔗aum <aum@...>

🔗Aaron Andrew Hunt <aaronhunt@...>

🔗kraiggrady@...

🔗Graham Breed <gbreed@...>

🔗Herman Miller <hmiller@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Graham Breed <gbreed@...>

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

🔗Graham Breed <gbreed@...>

🔗hfmlacerda <hfmlacerda@...>

🔗George D. Secor <gdsecor@...>

🔗Graham Breed <gbreed@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Graham Breed <gbreed@...>

🔗hfmlacerda <hfmlacerda@...>

🔗Graham Breed <gbreed@...>

🔗acousticsoftombak <shahinm@...>

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

🔗hfmlacerda <hfmlacerda@...>

🔗Graham Breed <gbreed@...>

🔗hfmlacerda <hfmlacerda@...>

🔗acousticsoftombak <shahinm@...>

🔗acousticsoftombak <shahinm@...>

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

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

🔗aum <aum@...>

🔗Carl Lumma <carl@...>

🔗aum <aum@...>

🔗Carl Lumma <carl@...>

🔗hstraub64 <hstraub64@...>

🔗Dave Keenan <d.keenan@...>

🔗Graham Breed <gbreed@...>

🔗Dave Keenan <d.keenan@...>

🔗Graham Breed <gbreed@...>

🔗aum <aum@...>

🔗Rick McGowan <rick@...>