Using Scala to insert pitch-bends (Was t-m: "does not work in the 11-limit")

I am replying on the main list and changing the subject line, since
the topic was no longer appropriate.

--- In tuning-math@yahoogroups.com, "Manuel Op de Coul"
<manuel.op.de.coul@e...> wrote (message #7898):
>
> George wrote:
> >I wanted to see if I could create
> >midi files (consisting of only a single track) from scratch in
Scala
> >(which would save me the trouble of calculating and manually
> >inserting pitch-bends), which I could then import into Cakewalk
(one
> >track at a time).
>
> Ah, I assumed you were using Cakewalk to enter the notes more
quickly,
> but you want to use Scala to enter the notes, and use Cakewalk to
adjust
> the tuning at places afterwards. Well, this is a use case I hadn't
> envisioned, since with Scala you can change the tuning quickly, but
> typing note commands is very slowly.

I'm sorry, but I guess that what I said was misleading. Forget about
everything that I said previously and let me start fresh.

What I originally had in mind was to create a midi file in Cakewalk
without any pitch bends. All of the notes in each track would be on
the same channel, with no simultaneous notes in any track being
separated by an interval other than an octave (or multiple octave).
Each track would have its own channel, and a change of channel would
never occur on any track, so that there would be a one-to-one
correspondence between tracks and channels.

Once the file was created, I then wanted to import it into Scala,
load a scale, and then have Scala insert the pitch-bends into my file
(deleting any pitch-bends that might already be there), but without
making any changes to the track or channel assignments in my source
file. I would then save the result as a midi file and import it back
into Cakewalk. If Scala doesn't allow this at present, I wouldn't
think that it would be difficult to provide that option (hint, hint).

However, let me ask something. In a Cakewalk work file I'm able to
specify whether a note will display as a sharp or flat (e.g., G# or
Ab), but if I save it as a midi file, would that distinction be lost
(such that Scala would not tell them apart)? If so, I would then
have to restrict myself to scales having no more than 12 pitches in
the octave.

Unless: if the insert-pitch-bend operation would allow the user to
select which channel(s) would be affected in a pass, then a new scale
could be loaded between passes to allow for additional pitches
(supposing, for example, that my midi source file were to have two
channels on each track (say channels 1 and 2 on track 1, channels 3
and 4 on track 2, chs. 5 and 6 on trk. 3, etc.)

Does this make any sense?

> >Your Scala documentation indicates that pitch-bend
> >events are minimized, so that you are constantly *changing
channels*
> >from one note to the next (rather than inserting *pitch-bend
events*
> >for a single channel).
>
> This is not entirely true anymore, I forgot to update the
documentation
> for that. There are also possibly program change and parameter
change
> events involved in channel switching. So minimising pitch bend
events
> doesn't make sense if it causes many more other messages.
>
> There may be a way to do what you want but I've never tried it.
> You can exclude midi channels from being used. So if you exclude all
> channels except the first for the first track, then generate the
> midi file for that track and for the next track exclude all
> channels except the second one, generate that, etc.
> I don't see why that wouldn't work.

I did see that feature in the documentation, but I've come to the
conclusion that doing this a track at a time may be as time-consuming
as inserting pitch-bends manually, if this involves importing and
exporting each track to and from Scala as separate midi files --
unless it is possible to generate the pitch-bends in Scala one track
at a time, then reset the channel exclusions and then do the next
track, etc., as I suggested above.

> Generating MTS from .seq files isn't a good solution because it
keeps
> the channels, but switches the note numbers on a round-robin
> basis. That will be even more confusing to look at in Cakewalk :-)
>
> But perhaps still the most efficient solution would be to discard
> Cakewalk from the process, and do all changes in one seq file, not
> looking at the midi file.

And how convenient is it to display and edit the notes in a seq
file? Cakewalk has features that I would not want to lose.

--George

George wrote:
>If Scala doesn't allow this at present, I wouldn't
>think that it would be difficult to provide that option (hint, hint).

It doesn't no. You might get it by accident, perhaps if all
channels use different parameters, but it's not probable.
I'll think about adding it, wouldn't be difficult indeed.

> In a Cakewalk work file I'm able to
>specify whether a note will display as a sharp or flat (e.g., G# or
>Ab), but if I save it as a midi file, would that distinction be lost

Yes, but there's a but. If Cakewalk allows inserting key change
messages, then Scala can write it to a seq files with proper (meantone)
sharp or flat. But it's not completely flexible then.

>If so, I would then
>have to restrict myself to scales having no more than 12 pitches in
>the octave.

Or borrow keys from unused octaves and use a keyboard mapping.
Probably easier than the method above.

>Does this make any sense?

I think so, instead of abusing pitch bend statements for this, one
could use an unregistered midi parameter for switching scales.
I have considered implementing it, but no one has asked for it yet.

>And how convenient is it to display and edit the notes in a seq
>file? Cakewalk has features that I would not want to lose.

Depends how quick you are with Wordpad or some such.
But you can type Sagittal names...

Manuel