Hi Rene
Another happy owner of z3ta+ here.
Thanks for Scala support (main reason I bought z3ta).
Do you plan supporting .TUN format in the future upgrades ?
My other VSTi's (Cronox, Rhino, etc.) use .tun files and it's much more convenient to load same .tun file in all of them.

Regards
D. Jel.

Hello,

Usually, as far as I know, .tun files are created in Scala and exported as .tun to be used in other synths.

The native scale format is much more complete and powerful, and as you already know z3ta+ supports it directly.

Pethaps you could convince the vendors of your other instruments to go this way instead

Cheers,
René

Oh, I see now.
I'm just a beginner in these things.

Hi everyone this is my first post here.
Since monday the 27th, i'm the happy owner of z3ta+. The main reason that made me buy it is the support of the native Scala format.



And yes you're right René, .tun files are exported from Scala native format and even if the export is precise enough, there is some loss in the conversion (very small and probably negligible). But the main thing is that it's a long and cumbersome process. It took me hours to convert the scales I wanted to use the most in other synths I own. Scala is a very great piece of music software but it's not that user-friendly.

As for convincing other vendors , I approached 2 designers of software that I own and that did not support either .tun or .scl files. They were very interested in the idea and after I gave them the best explanations I could (I'm not an expert), one went with .tun and the other with .scl. I don't know why they choose what they choose. It's a lot easier for the user if an instrument uses Scala native format. But the bottom line for me is that any instrument that has the ability to use either one has my vote.

Zvon

Just for reference, I have written a little utility that converts Scala files to .TUN, and yes, it can convert multiple files in one go.
Download is here:
http://files.kickedup.com/ScalaConverter.rar

There are two types of .TUN files, the VAZ tuning uses only integer tuning values and can therefore not exactly represent the original Scala tuning, but you can also generate and include an extended Anamark tuning section which allows setting precise frequencies for every note. Most VSTis support only the regular standard though
My converter will make a file with both sections.

The main advantage of Anamark TUN over Scala is the support of a base tuning frequency to which all other note frequencies are calculated accordingly. Scala does not have this built in as far as I know.

The specifications and the source code (C++ by Mark, Delphi by me) is available on www.anamark.de and some bits and examples also on my site www.tobybear.de

Cheers

Toby

www.tobybear.de

Thanks Tobybear for the additional infos and Scala Converter !!
I use exclusively alternatives scales !
What I need now is to sort seriously those nearly 3000 files between " wise " and extremes and also dig into Scala ...

Many are more macrotuning files actually !

It can both radically and subtly change a preset, if you don't try microtuning you definitely miss something big !!

So thanks René !

Yes, you are right, tuning (no matter if macro or micro, SCL or TUN) is really a good thing and I would like to see more synths supporting this. My future synths/samplers (for example the soon to be released Helios 2.0) will support microtuning with native Scala, VAZ and Anamark tuning files, even by drag n' drop on the GUI.

Respect to Rene for all of his wonderful synths by the way!

Cheers

Toby

www.tobybear.de

Hello all,

[gangster]
I think we're not understanding each other...[/gangster]



I see that is an -advantage- of supporting native .scl files instead of .tun... correct? No conversion required. And even using the great Tobybear's gizmo, no conversion process is faster than no conversion.

I take this opportunity to thank you Tobybear for all the great stuff you drop on the Virtual Community daily. I hope we as users could be appreciative enough with that.




Scala does something extremely interesting from my point of view: it completely insulates the concepts of 'tuning system' and 'keyboard layout', turning them in two cohesive but non-intersectant objects.

So, base tuning and the rest of the keyboard layout specification resides in a separated file (.kbm). I really enjoy the concept purity of this idea.


Ok, i'll try to expand a bit why .scl was the choice:

1- standard TUN files can't represent precisely a infinite-set of tuning systems due it's based on integer or fixed-precision numbers, not ratios.

2- standard TUN files don't tell the instrument how many notes the tuning system is composed of.
In this way, if you select a 5-notes tuning system and, for instance, use two oscillators detuned one-octave, they won't make a unison interval. This is also the case when using the built-in arpeggiator.

Both of this situations are cleared with .scl files.

3- there are 3000+ files already available for free from the net as .scl. Some of them are created by researchers of alternative tunings, so they have a scientific value added to the musical character. No alternative system provides such a free library.

4- Scala is a freeware program, which allows to create and analyze alternative scales as -no other- program. Drag a .scl file on z3ta+, and all is set. AltTuner's dream.

It has also set a -open- and -un-endorsed- program, which was not created by a instruments manufacturer. This is a -very- important aspect for us.


Hope this helps.

Cheers,
René

Rene,
Is it possible that you add the same
Scala compatibility of Z3ta+ to sfz+?
I think it would be it would be an absolutely
tremendous!!
On a side note, I have tried sfz standalone and
VST, and it seems the latency of the standalone
is very high from the Midi in, while sfz VST in Brainspawn Forte as host has excellent latency.

Just to set some things right / add some comments...



AnaMark TUN files don't use fixed-precision numbers, but scientific notation. So you can reach the same precision as with ratios. When handling ratios, anywhere in your code, you have to calculate the resulting value, and then you also "only" have a floating point numbers in scientific notation with limited precision.



AnaMark TUN-files allow setting the octave-loop-point according to your wishes. So it's no problem to declare any octave-system you wish. Note, that AnaMark TUN-files are more than the crude "note #x has frequency y"-system. The format has an algorithmic component.



IIRC, the same library is also available in AnaMark-TUN-format from Tobybear.



For creating AnaMark-TUN-files, you won't even need a special software, just a text editor. And in my opinion, the format is easier to understand and to handle than the format of scl-files. Is there any other software than Scala for creating SCL-files? What if you don't like Scala?

Another point: As far as I know, there are more plugins, which support TUN-files, than plugins which support SCL-files.

Erm... this is not intended to start a format-war here. I think, both formats have their advantages and disadvantages.

Hello,

Thanks AnaMark for your insights about AnaMark system. A few insights:




Almost. If you transpose a fixed precision number, you end with an error. I don't really think it can be perceived in real-world apps, but a ratio has -zero- error. Zero error is always better than a non-percievable error.




I see. However, other TUN applications don't feature this propietary tweak afaik. It seems AnaMark features 'TUN 1.1' or 'Enhanced TUN'.



If you mean as 'converted from scala files', you're probably right. However, those files were originally created in Scala, and you can tweak existing ones and reload them in z3ta+ natively. I think that's cool.

Haven't found the 3000+ files TUN lib it in the web tho.



A text editor will do Scala files as well. Easier to understand a zillion of floating point numbers which don't mean anything without a calculator? I honestly don't agree. Looking at a Scala file I can precisely tell you many things about the tuning I'm about to play which I can't get from a TUN file at all.

Easier to handle... you just click on the 'load tuning' dialog, then select the file. Same for both.

If you don't like Scala, then you use Notepad, as for TUN files. Works great.

Cheers,
René

As soon as you start applying this ratio to frequencies, it also will have an error. Zero error is a theoretical construct, which is not achieveable in real software.

A ratio is nothing else than two numbers with fixed precision. An when you consider error propagation in computer maths, you will end up with nearly the same - in fact, handling a ratio may also end up in a higher error than handling the result directly - especially when you use standard double-math in your application.



As far as this kind of calculation is concerned, there is no zero error in reality.



There's a difference between VAZ tuning files and AnaMark tuning files. AnaMark tuning file format is downward-compatible to the VAZ-format which is widely used, but has some enhancements.

I made the source code to handle the format available for everyone. This code can immediately be implemented in each VSTi without changing it's structure, without too much work.

As you told about the arpeggiator-problem, or the OSC-detune-problem: A true handling of SCL-files respecting this aspect will make changes necessary which go deeper into detail of VSTis. This is a lot more work.



I didn't want to tell you, that your way is the wrong one or that it's uncool. I didn't want to tell you, that "my" format is better than "yours". I also would never argue about "TGA graphic files" vs. "BMP graphic files". Both exist, both are used.

I think, the best way is to implement both: SCL and TUN-support. Because there are so much plugins which only support TUN. And when your plugin comes with SCL only, this is a problem to the user who wants to use the same files in all VSTi. What to the user who has his scale in TUN only? There are converters SCL -> TUN. AFAIK there is no converter TUN -> SCL. So he has to recreate his TUN-Files in Scala from the scratch, when he wants to use them in your plugin.



www.tobybear.de

Search for "ScalaConverter", there the complete archive is included.



In fact, sometimes and for someone it is easier to understand 21,... than 58974 / 2684.



I think, we shouldn't discuss about subjective taste here.



That's O.K.. SCL-files fit to your taste and to your way for handling/using tunes.

My tunes don't base on simple 7/3-fractions. The pure fractions end up in unnatural tunes, so I don't use them. In fact, while creating tunes, I use software to model certain sounding conditions. And there, it's easier and better to let the software output scientific notation values than integer-based ratios. But this is "only" my way of doing those things.



I mean easier to understand. Give someone a SCL-file and a TUN-file. Which of both is easier to read/understand, to create from scratch without special software (or with selfwritten software), to edit without special software, is also a subjective thing.

Hello,

Thanks for your comments again. My comments to your comments. Please don't take this personally, I just like to go as deep as possible into technical facts expecting the users can realize what the advantages are of each system.





If you specify 0.3333333333333 as the result of 1/3, you have an error. You can keep the 1/3 ratio all the time, transpose, pitchbend, pitch envelope, lfo (change pitch by any means that is) and calculate the result at the end of the process, and you're introducing error just once in the final step. Anyways, it's deep chinese for most (non-chinese) users, so I won't go deeper on this here.



I didn't feel you did. I feel this as a constructive discussion about advantages and disadvantages of both used formats.



Behind the decision of implementing SCL files in z3ta+ there are several fundamental facts for me:

1- SCL is open, free, and not endorsed or technologically backgrounded by any company.
2- SCL is technically perfect. All what I've heard about TUN format is 'it is not worse' rather than 'it is better'.
3- SCL has a program (Scala) which allows a zillion analysis and research behind tuning systems. It was designed to do that, and zillions of mathematicians and alternative tuning musicians are using it. And it's free.
4- There's a -extensive- library of tunings already created for it.
5- It deals with ratios, which are what tuning systems are made of. All the rest are real-world translations of it.

I naturally see those facts as definitive, and that's why native Scala support is in z3ta+.

Naturally, it would be cool to implement both. However, I don't see any synth implementing both out there, possibly due it takes more resources than implementing one, with about the same results.



Been there several times. Unfortunately, as soon as I click 'download' a nice BuyDomain.com ad appears






Here's an example .scl I took from the Scala page:

This might be highly subjective as you say.

But I honestly understand perfectly the numbers at left and can recreate them out of my mind, while the ones at right tells me absolutely nothing and I couldn't remember them noteven if I'd study the table for weeks.



Above file can be edited with Notepad, and can take 1 minute for a slow typing cow like me. You don't need calc.exe to create the Scala file. It's created much faster. And it works.

Cheers,
René

Right. And when you calculate 1000Hz*1/3=333.3333333333, so you will have exactly the same error. It makes no difference.

Each calculation step increases the error, in the best case, the error remains the same.

1000Hz * 0.3333333333333

Is one calculation step -> one possible error source.

1000Hz * 1/3

Two calculation steps -> two possible error sources.




O.K.. I think, the differences in "error" between both systems are of theoretical nature.



Interesting. What's the difference between the developer of Scala and me in your eyes? What makes me a company, while he's not one? The only difference is, that Scala is freeware. But Star Office also is free - nevertheless, there's a company behind it.

Both formats are open. For SCL there is no open source for reading/writing (AFAIK, I may be wrong here). For TUN, there is.

And why is "comes from a company" a disadvantage?

Erm... you are a "company" too, aren't you? Especially more than I?



*laugh* Yes, here you may be right. But BetaCam and Video2000 were also technically perfect compared to VHS - and what was the system, the people used?

Unfortunately, technical perfection is no guarantee. It seems that you come from an "ideal point of view" here (wanna improve the world, eh? ), while I just looked about what's used and took that in an improved way. I may be wrong, but hey, no risc, no fun!



There, I don't agree. By limiting your tuning systems to simple ratio-like ones, you exclude many possibilities, many details.



I wonder... Aren't real-world tunings that people are looking for? A real instrument doesn't show clean simple-ratio tunings.



A very good thing, no discussion. I also plan to implement native Scala-files into AnaMark (in addition to the existing TUN-support), but currently there are so many other things eating my time.



No idea. Maybe I can tell you more after implementing Scala in AnaMark.

Hello,



In such a trivial example, it doesn't. Transpose 0.333333 two octaves, and it does.



A 'company' runs a (expectable) profitable activity.

StarOffice is free, but it serves as advertising or 'market balancer', so it's not exactly free from a marketing point of view. Same goes for our Triangle synths and any freeware piece released by companies which have commercial products as well.



When you decide to implement in a product any feature whose spec was defined by a competing company, things go almost always badly. I still wish VST would have been vst.org, as all the nightmares we're still living wouldn't had happened. There are many examples of this in different software fields, and in this one too.

This kind of technology use always give the 'leading' company (the technology developer/poster) a competitive advantage, as it can change the spec anytime and offer 'backwards compatibility' while all other parties following the original spec have to go and watch what they changed and pray they can implement the new things as the license terms didn't change.

There's no fundamentalism in this though: I've used technologies from third parties: we've just licensed Hermode, released some other gizmos using SoundFont (emu), etc. It's all mostly a matter of customer demand, and company relationships.

Source code to implement both is extremely trivial, that couldn't be a reason to choose the format.



I don't know what people is looking for, and I believe there's no exclusive answer. I can absolutely tell you that people looking for z3ta+ is not looking anything they can find in a 'real' instrument in a inmense proportion.

I'm not sure what you have in mind when you say 'real instrument' though. For example, any brass instrument is played abusing extensively of harmonics. Harmonics, are just ratios. Same for the strings. You can see that many scales (ie Pythagorean) is based on stacked fifths, a natural consequence of third harmonics.

Let's start by thinking that the fundamental concept behind all our occidental music is the octave, which is just a ratio.

Frequencies are a measurement of a physical phenomena, which is unrelated to how we perceive the sound. Ratios are used everywhere in tuning systems research, as they allow transposing the tuning system spectrally as a whole unity. In fact, all things I realize you do know, but probably see thru a different glass.



Focused from a 'ideal point of view'... sure.
Want to improve the world... definitely.

No offense. I did research what was used as well. I also feel Scala is a better offer than anything else out there, and that's why it's in its place.



I don't use risc processors tho. But sometimes I have fun anyways

Cheers,
René