glide between 19tet tones
I'm building a kind of self-performing ambient patch using a series of chords based on a 19-tone equal temperament scale. Tuning is rather important. I want the tones (based on cycle~ and rect~ objects) to glide from one frequency to another. I'd like to keep the frequencies pretty strict, but I'm finding the line, line~, and curve~ objects truncate the decimal numbers. Suggestions?
Perhaps you can post a bit of your patch so far, so we can see how you're currently attempting it. Might be easier to give you some concrete feedback that way. Keep in mind that, typically speaking, 2 decimal places is usually sufficient accuracy for tuning, so a little bit of lost precision may not actually be audible - depending on the context, of course.
i usually work on the linear layer when dealing with note event, so a 19tet scale would simply contain floating point note numbers such as 64.3765.
the key for building a glide or portamento mode then is, in my opinion, to first go to the signal layer, then doing the mtof~ there as last step after the (possible) glide. this way it is very easy to perform linear (or distorted versione of linear) portamento fades, and it is also easy to implement different key modes for it.
if you plan to implement vibrato, too, that can be done the same way, and i would suggest to do it _after the gliding
you said line~ would truncate the input? ... it shouldnt. there must be something else wrong in your patch, line~ would be the right way.
a simple example for my model suggestion in the picture below. this is how i drive a line~ object from incoming note number messages, which creates a signal representing the above mentioned note number of 64.3765 on the signal layer - including the portamento offset.
you can also easily use this as a poly~ patcher to add further modes, such as "use highest note in a chord as trigger" or whatever.
"64.3765"
[110.portamento]
[line~ 0.]
it has 4 modes: off, on, only up, only down.
possible scaling of the time values must be done outside before going into the rightmost milliseconds inlet.
-110
init the pack object like that:
[pack 0. 0] or else floats autoconvert to ints
Ah yes, something simple, of course. Thank you. I should have thought of it.