Here’s the original thread for XRNI Microtuner, with detailed specs and screenshots:
Edit: In the thread is Diptera, participating, so he’s probably already aware of this. Still worth posting it for historical reasons, less mistakes repeat themselves, IMHO.
Ah yes, I remember that script. Thanks for putting it here, very relevant bit of history.
Anyway, scripting is definitely one way to alleviate the tedium of making new sample copies, but some serious problems remain:
The deeper issue in my opinion is that Renoise doesn’t have tuning in mind. If tuning is treated as the important element of music that it is (at least to people in other cultures), we won’t have to “hack” quite so much.
Although I would love to see Renoise go alphanumeric for command names I will point out there are a few spare in the Fxyy range. Although this area are generally global commands, rather than local/sample ones so not an ideal place.
Did wonder about having more coarse adjustment via a pan/vol command but not much free. 8x but 80 is the same as 79 so avoided. Cx but C0-4 is used in Pan column for MIDI things… Again solved by going alphanumeric.
100% agree on automation of the Finetune, both from pattern commands and the Automation Curves.
i think you make some good points for better tuning in Renoise here. you should also be applauded for stating your feature requests so clearly, and accompanying them with mockups as well. really well done. i agree with you that it would be a good thing if the Renoise devs would consider implementing something like this.
the only thing i would want to a add to this is the combination of this with other often requested features, some of which are said to be in the pipeline for Renoise development. the main thing i am talking about here is the a future .xrni rewrite. there are a people having issues with the way instruments are currently set up in Renoise, and i can imagine the devs wanting to tackle that first before going into tuning, especially since if they do tuning first that would simply increase the amount of stuff that needs to be rewritten. so i think it should be done the other way around: first the instruments, then the tuning.
Thank you very much for saying so. I wanted to make sure I got it right.
Huh, interesting! I’m curious to know how XRNI is gonna change. Anyway, what you say makes a lot of sense. First fix the foundation, then expand the tuning capabilities. But I do hope that the changes to XRNI will be made with tuning in mind.
thank you. i must say your summary is very good, couldn’t have said it shorter myself. i also hope the tuning will be relevant enough for the dev team to consider when they are rewriting the xrni structure. i suppose we’ll have to wait for one of the devs to chime in on this discussion to let us know some more about how they look at this.
(only thing i could find about rewriting the .xrni structure, maybe someone else can find some more:)
https://forum.renoise.com/t/controlling-instrument-filter-cutoff/31227
DONT USE THAT OLD BUGGY THING!! It’s deprecated, as in broken, and has been for some time. But I see the point, for the discussion’s sake. Just wanted to point out that it would only result in headache to try and make it work.
–
Participating in the brainstorm
So, my understanding of this is that we basically have two different approaches to this - tuning the instrument as we play it, and preparing tunings in advance (via instrument settings/editor).
For the first part (and I’m no expert in these matters), I’d guess that that when musicians are playing in something like a quarter-note scale, this is often achieved by means of bending the strings, or by other playing techniques that produce a similar result. The point here is, that the instrument isn’t really microtonal to begin with, but because of the way it is being played, the result is.
Now, I find that Renoise is already severely lacking in regard to “realtime pitch modification”, as we don’t have a pitch-bend control for sample-based instruments (VST instruments are fine, as they have the MIDI Control device). But if we were to get such a thing, it would be wonderful if the pitch bend could be configured to “quantize” the pitch slide to a predetermined scale, as defined in the instrument.
But bearing in mind the fact that the otherwise exciting idea of realtime microtonal control of pitch via a quantized pitchbend relies on some existing mechanism for describing the scale, this is most likely not the first thing to be realized - still, I wonder how far a scripted solution could take this idea? Listen to external MIDI, and write pattern commands on the fly…
The other approach is to prepare the instrument in advance. There’s a lot of different approaches, and IMO the one which would interfere the least with any existing workflow, and take the least time from the developers, would be to allow finetune per sample keyzone. In this way, we don’t get the problem of multiple identical samples taking up unnecessary RAM and disk space, and it would be possible to write a script/tool that could take an existing instrument and re-arrange the keyzones when provided with a .scl/.tun file
@Diptera: great to see that your interest in microtonal scales is a lasting one. I have to admit that mine was more of a fleeting moment. Might come back for a second round though 
Makes it a lot harder if you then want to tune the whole sample as you have to work out and select every keyzone that sample is used in to adjust. You can already do it by laying lots of Slice Markers on top of each other at the start and then setting slice playback to continues playing, rather than place slice only.
Great summary/overview Diptera!
I’ve relentlessly bumped microtonal threads in this suggestion forum in the past to no avail, hopefully your post will spark something for the coming Renoise update! 
Will bump this thread with suggestions, once I get rid of a nasty virus 
Granted, but isn’t this a shortcoming of the Renoise instrument as-it-is? I don’t think it’s a bad approach to generate a set of keyzones, rather it’s the lack of being able to alter the global transpose afterwards.
Oh, and you’re right about the slice thing: a lot of slice markers in the beginning of the sample, playing continuously and unlooped could in fact be used to create microtonal instruments.
Damn, that’s one clever workaround!!
Awesome, I’m glad people are still interested! Thanks everyone for participating. I’m excited to see where this goes.
Danoise, you have indeed summed up the two different approaches to creating microtonal music on computers in any software: real-time pitch bend of individual notes (in this case FX commands, automation, MIDI pitchbend) vs. creating an instrument with a different tuning framework.
Having built prototype instruments in Max/MSP and others, in my opinion doing things the second way above (“right way”) is not as much of a challenge as people think – it’s just that it’s a new concept to many software developers (and even musicians).
This does work! The problem, though, is that you only get ONE note for every slice. Currently you cannot map slices to anywhere on the keyboard, or to multiple keys – it’s automatic and locked. That brings up the pattern editing/readability issue in my original post. However! It does mean we could script a workaround for tuning now…
As your notes are NOT the standard 12 notes apart you are always going to have to do so anyway are you not? There is also a white key only option which may make more sense when not using standard tunings flats and sharps.
I personally do not think something that will make something easier which a small minority are going to be interested in should make something that is more general use harder to do.
Of course there are ways around this and still give when you desire, finetune per keyzone. My preferred method would be to keep the Instrument Settings tunings affecting the whole sample, but add an extra Finetune selection next to Basenote when you have Keyzones selected. An alternative would be to have a (right click) option to select all keyzones a sample is used for and then change it, but that way seems a little counter intuitive.
good summary!
restating my (perhaps a bit out there 
) opinion on the matter:
give the user an option to create new note symbols (with three alphanumeric chars as it is now for example c#4) and map those to playback rates/pitches. (the editing of those maps could be done in a tool outside of renoise… no need for that in the settings)
that would give us support for microtonality with rational note names… in addition to that we could do cool stuff like drum maps with easily readable note symbols like ohh, chh, bd, sn, rs, gn, ss.
think of the srsly weird arps one could write 
It depends. Examples, from least to most extreme:
What if my custom scale does have 12 notes, such as a well temperament or Werckmeister tuning? Then it’s just like a normal Renoise instrument, except that every C# is X cents flat, every D is Y cents sharp, and so on. Tuning pattern repeats at the octave.
What if I want my 9-note scale to repeat every 12 keys? Just like above, except there would be 3 blank keys mapped in every octave.
What if I want my 9-note scale to repeat every 9 keys? Or what if my scale has 17 notes? Well, that would require a little UI change and introduce some extra options. But it’s definitely conceivable – Renoise would need to be flexible about where to repeat the tuning pattern, or in other words, how many keys until the next octave.
What if my scale does not repeat at the octave, or has a stretched octave? Then yes, the way things work now, I will have to manually edit every single note.
I am going to think up some designs for an Instrument Settings panel which would clarify these issues and present potential solutions.
I completely agree. That’s why my first suggestion is automation and effect commands. Changing the Instrument Settings panel would be a hairy issue that takes lots of care not to disrupt what people know. I do have UI ideas for this though!
Originally I thought the introduction of alternative symbols would complicate things very quickly, but I like your idea of a custom symbol field. Simple and open-ended. I’ll think about that for my next design.
Had forgotten about some alternative tuning where only a small number are different. Sure extra work for these, but a Tool could make the majority of that automatic.
I don’t get this. This is always going to be the case unless the idea my maes of being able to have your own note names can somehow be introduced, but then you are still going to be playing from the 12 note repeating design of the keyboard too. If you want a 9-note scale to repeat always starting at a C on the new octave then you will need three slices inbetween, each with the same volume set to 0, but I don’t really see why that is too much of a problem…
Thinking through the maths (eg being able to get people to define the note spacing formula and how many notes to an octave, if you want to have silent keys, etc) and then creating a Tool for generation based on this may be a good way to go.
Although I do still 100% support this idea!
OT: maybe good to have this post stickied?
Alright, everypeople. I just spent many hours with GIMP and canker sores to bring some new designs to the table. They contrast my original post in that they are more of a long-term, ideal solution for tuning. We should still get the FX commands and fine-tune automation I described, but what follows is what would be a permanent solution to our tuning woes.
This might be crazy, but I couldn’t help myself…
Long-term solution: Tuning panel in Instrument Editor
I have [b]set up a small webpage[/b] containing the following images (plus a couple more) and their full-sized counterparts, as well as a thorough but concise explanation of the design. You don’t have to read the text, you can just look at the pretty pictures! But the text is meant to clarify and justify the design.
One of the designs. Standard 12-tone equal temperament.
Same design, with a different scale entered.
…and more! All on my small proposal webpage. [sub]Check?[/sub] [sup]It?[/sup] OUT.
Can’t say I would mind that!
looking at the site, i like the design for the small keyboard the best. if it has more notes than there is room, a scrollbar can be used.
you have forgotten one very very very important thing in your design though. can you guess what it is?
presets man, presets! so you make a totally rad tuning and you cannot save it anywhere? or you make a 2nd instrument and you want that same awesomeness of tuning contained in that as well? presets! saveable, loadable, adjustable presets!
Yes, I think the small clavier is better too.
Aha! Actually, I did not forget, I thought about it! But I was running on fumes and didn’t bother to put it in the mockups. Maybe I’ll add them later.
A presets menu such as the ones in native DSPs would be good. And if that didn’t exist, we could still depend on the (hypothetical) XRNX tool to save ‘n’ load tunings. But you’re right, why treat these settings as a second-class citizen of Renoisia?
Nice visualizations diptera!
Some words from the devs in this thread on the possibility of microtuning in Renoise would be nice 