Yahoo Tuning Groups Ultimate Backup makemicromusic [MMM] Scala 2 SynthEdit Microtuner

Robert Strauss,

> Hi - I've recently coded a tuning module for SynthEdit,
> and I'd be grateful if a couple of folks on the MMM list
> would be willing to test it.

Yay! This is really great news for the community. I've always hoped
someone would add such capability to Synthedit. This should open up wide
possibilities for tuning people to make their own VST components.

> I've developed a microtuner object for this model that browses
> and loads Scala files for real-time polyphonic tuning.

I see you solved the problem of needing .kbm files by assuming the tuning
is to be spread across the keyboard with a starting key note value &
frequency. Does this exactly emulate what Scala does with a .scl file when
it creates a .tun file for output?

Personally, I prefer ".tun" files, and they are used in many other VSTs
out there (Wusik, Rhino, VAZ Modular, Chameleon, Anamark, etc). And it is
trivial to add .tun file support. You can use the publicly available
Anamark source:
Info: http://www.anamark.de/download_e.php
Files: http://www.anamark.de/files/tuning.zip

My sales pitch: I like .tun files because they're a final form, and I have
software besides Scala which can generate them. And I use some tunings
that I would find difficult to describe in terms of Scala. And you're
already most of the way to getting .tun support. You write on your web
page:

> Clicking the Load button runs an internal process that translates
> the scale to cents and places it in the selected tuning slot of
> the current patch.

If you do that, supporting .tun format is trivial. If you don't want to
use the existing code from Anamark to load them, you could read the files
and scale the .tun values to match your frequencies in cents, and then
proceed exactly as for Scala files. But the Anamark code should be trivial
to incorporate. Then users could choose .scl or .tun files.

> The most notable feature of the microtuner is that it implements
> real-time, ensemble scale and key change that can be 'played' by
> midi note events,

This is a very nice feature. On your web page, it sounds like you use a
separate MIDI channel to control "key" information. Is that right? So, for
example, you would have a secondary channel in a score which would contain
midi "notes" that actually control the key for the other channels... right?

> If you would be interested in trying it out sometime over the course
> of the next two or three weeks, please email me...

Well, sure. I'll e-mail you... :-)

Rick

🔗Carl Lumma <carl@...>

🔗Robert Strauss <robert@...>

Hi Rick -
Thanks for your interest! I chose .scl over .tun because
I felt the ability to calculate tunings note by note on the fly
would give greater flexibility than .tun, which is based on
a prepopulated array for 128 midi notes. Although in years
past the .tun approach may have had a deciding performance
advantage, the CPU usage for on-the-fly tuning is negligible
for the current crop of PCs. The result of the .scl based
tuning is similar to the cents portion of the .tun specification,
scaled for compatibility with the SynthEdit 'voltage' model.

To me, the .tun approach is problematic for real-time key
modulation. My thought is it would take a separate .tun
array for each modulation one wished to support. In the
current .scl based scheme, key changes are handled by
just moving the centerpoint and playing out the current
tuning as needed by the oncoming note stream. The neat
thing is that key change centerpoints can be set just as
easily from any tuning in memory as from the tuning that
is being played.

The Microtuner uses configurable, dedicated midi channels
(e.g. channels 15 and 16) to control real-time key and scale
change for an ensemble of microtuned VSTs (or instances
of the same VST with different timbral settings) on any of
the other midi channels. Note-based control changes are
based on note position relative to a control channel's
centerpoint. So to modulate to the third step of the selected
modulation tuning, the third midi note above the control
channel centerpoint would be played or scored. The control
channel centerpoints can be set off to one end of the midi
note range to support split keyboards, footpedals, etc.

I initially developed this scheme to retune Kontakt 2, but found
that the price of Kontakt 2 is a factor to some folks who might
otherwise be interested in it. The SynthEdit community has
quite a few developers turning out some really remarkable,
low-priced VST components, and I'm hoping the new
Microtuner will find a role in that ecosystem.

Robert

Quoting Rick McGowan <rick@...>:

> Robert Strauss,
>
>> Hi - I've recently coded a tuning module for SynthEdit,
>> and I'd be grateful if a couple of folks on the MMM list
>> would be willing to test it.
>
> Yay! This is really great news for the community. I've always hoped
> someone would add such capability to Synthedit. This should open up wide
> possibilities for tuning people to make their own VST components.
>
>> I've developed a microtuner object for this model that browses
>> and loads Scala files for real-time polyphonic tuning.
>
> I see you solved the problem of needing .kbm files by assuming the tuning
> is to be spread across the keyboard with a starting key note value &
> frequency. Does this exactly emulate what Scala does with a .scl file when
> it creates a .tun file for output?
>
> Personally, I prefer ".tun" files, and they are used in many other VSTs
> out there (Wusik, Rhino, VAZ Modular, Chameleon, Anamark, etc). And it is
> trivial to add .tun file support. You can use the publicly available
> Anamark source:
> Info: http://www.anamark.de/download_e.php
> Files: http://www.anamark.de/files/tuning.zip
>
> My sales pitch: I like .tun files because they're a final form, and I have
> software besides Scala which can generate them. And I use some tunings
> that I would find difficult to describe in terms of Scala. And you're
> already most of the way to getting .tun support. You write on your web
> page:
>
>> Clicking the Load button runs an internal process that translates
>> the scale to cents and places it in the selected tuning slot of
>> the current patch.
>
> If you do that, supporting .tun format is trivial. If you don't want to
> use the existing code from Anamark to load them, you could read the files
> and scale the .tun values to match your frequencies in cents, and then
> proceed exactly as for Scala files. But the Anamark code should be trivial
> to incorporate. Then users could choose .scl or .tun files.
>
>> The most notable feature of the microtuner is that it implements
>> real-time, ensemble scale and key change that can be 'played' by
>> midi note events,
>
> This is a very nice feature. On your web page, it sounds like you use a
> separate MIDI channel to control "key" information. Is that right? So, for
> example, you would have a secondary channel in a score which would contain
> midi "notes" that actually control the key for the other channels... right?
>
>> If you would be interested in trying it out sometime over the course
>> of the next two or three weeks, please email me...
>
> Well, sure. I'll e-mail you... :-)
>
> Rick
>

🔗Carl Lumma <carl@...>

I just remember really liking the music you had load
in the background of the Kontakt page. I'm not getting
it now. What was that?

-Carl

At 07:32 PM 9/16/2007, you wrote:
>Hi Rick -
>Thanks for your interest! I chose .scl over .tun because
>I felt the ability to calculate tunings note by note on the fly
>would give greater flexibility than .tun, which is based on
>a prepopulated array for 128 midi notes. Although in years
>past the .tun approach may have had a deciding performance
>advantage, the CPU usage for on-the-fly tuning is negligible
>for the current crop of PCs. The result of the .scl based
>tuning is similar to the cents portion of the .tun specification,
>scaled for compatibility with the SynthEdit 'voltage' model.
>
>To me, the .tun approach is problematic for real-time key
>modulation. My thought is it would take a separate .tun
>array for each modulation one wished to support. In the
>current .scl based scheme, key changes are handled by
>just moving the centerpoint and playing out the current
>tuning as needed by the oncoming note stream. The neat
>thing is that key change centerpoints can be set just as
>easily from any tuning in memory as from the tuning that
>is being played.
>
>The Microtuner uses configurable, dedicated midi channels
>(e.g. channels 15 and 16) to control real-time key and scale
>change for an ensemble of microtuned VSTs (or instances
>of the same VST with different timbral settings) on any of
>the other midi channels. Note-based control changes are
>based on note position relative to a control channel's
>centerpoint. So to modulate to the third step of the selected
>modulation tuning, the third midi note above the control
>channel centerpoint would be played or scored. The control
>channel centerpoints can be set off to one end of the midi
>note range to support split keyboards, footpedals, etc.
>
>I initially developed this scheme to retune Kontakt 2, but found
>that the price of Kontakt 2 is a factor to some folks who might
>otherwise be interested in it. The SynthEdit community has
>quite a few developers turning out some really remarkable,
>low-priced VST components, and I'm hoping the new
>Microtuner will find a role in that ecosystem.
>
>Robert
>
>Quoting Rick McGowan <rick@...>:
>
>> Robert Strauss,
>>
>>> Hi - I've recently coded a tuning module for SynthEdit,
>>> and I'd be grateful if a couple of folks on the MMM list
>>> would be willing to test it.
>>
>> Yay! This is really great news for the community. I've always hoped
>> someone would add such capability to Synthedit. This should open up wide
>> possibilities for tuning people to make their own VST components.
>>
>>> I've developed a microtuner object for this model that browses
>>> and loads Scala files for real-time polyphonic tuning.
>>
>> I see you solved the problem of needing .kbm files by assuming the tuning
>> is to be spread across the keyboard with a starting key note value &
>> frequency. Does this exactly emulate what Scala does with a .scl file when
>> it creates a .tun file for output?
>>
>> Personally, I prefer ".tun" files, and they are used in many other VSTs
>> out there (Wusik, Rhino, VAZ Modular, Chameleon, Anamark, etc). And it is
>> trivial to add .tun file support. You can use the publicly available
>> Anamark source:
>> Info: http://www.anamark.de/download_e.php
>> Files: http://www.anamark.de/files/tuning.zip
>>
>> My sales pitch: I like .tun files because they're a final form, and I have
>> software besides Scala which can generate them. And I use some tunings
>> that I would find difficult to describe in terms of Scala. And you're
>> already most of the way to getting .tun support. You write on your web
>> page:
>>
>>> Clicking the Load button runs an internal process that translates
>>> the scale to cents and places it in the selected tuning slot of
>>> the current patch.
>>
>> If you do that, supporting .tun format is trivial. If you don't want to
>> use the existing code from Anamark to load them, you could read the files
>> and scale the .tun values to match your frequencies in cents, and then
>> proceed exactly as for Scala files. But the Anamark code should be trivial
>> to incorporate. Then users could choose .scl or .tun files.
>>
>>> The most notable feature of the microtuner is that it implements
>>> real-time, ensemble scale and key change that can be 'played' by
>>> midi note events,
>>
>> This is a very nice feature. On your web page, it sounds like you use a
>> separate MIDI channel to control "key" information. Is that right? So, for
>> example, you would have a secondary channel in a score which would contain
>> midi "notes" that actually control the key for the other channels... right?
>>
>>> If you would be interested in trying it out sometime over the course
>>> of the next two or three weeks, please email me...
>>
>> Well, sure. I'll e-mail you... :-)
>>
>> Rick
>>
>

[MMM] Scala 2 SynthEdit Microtuner - Beta testers wanted

🔗Rick McGowan <rick@...>

🔗Carl Lumma <carl@...>

🔗Robert Strauss <robert@...>

🔗Carl Lumma <carl@...>

🔗Robert Strauss <robert@...>

🔗Carl Lumma <carl@...>