Frequency Table Read for Alternative Tuning

#10

add a +64 offset. Then the range will be 0-127, instead of -64 to 64.

#11

Yes thats what I did a while ago , but keep having strange output. Negative numbers and other unexpected results.
It might be all wrong from the way I coded inside the table , and as you said @jaffasplaffa, the object cant handle the floats for some reason .

Will try tomorrow with your initial suggestion of converting them to int´s , and if that doesnt work , I just store 2 numbers of the ratios then multiply by a root note .

asfasgadgadgag.PNG1074x601 32.4 KB

#12

Yes, that was what I wrote, that I think you migh be overflowing one of the formats in the conversion from floats to ints. The result of overflowing is exactly negative numbers.

And yeah, all this conversion, is one of those things with Axoloti that can be a real pain and can take a while to get used to. I do a lot of work in Pure Data too and some c++ stuff too and everything is just soo much easier with floats :wink:

#14

Same here , I'm too used to convert "freely" or without much impact on the system , I'm gonna need a time to get used to this BUT !

I found out that is not about the floats , at last not only. There is something much simpler that Im missing...

Here I tried to read from a 8 index array of integers , this didn't work as expected . Not even with phasor frequency input or any other translation that I can think of . Feeling overwhelmed and lost here myTableArray.axh (6.7 KB)

aaaaaaaaaaaaaaaaaa.PNG1259x555 49.2 KB

I ignored the oscilator part for a while cause I was reading in the docs about the -64 64 range. But then all sorts of questions comes to my mind . Why even with frequency input it doesnt output from the table/read as expected ? if selector sends integer 3 , it should go into the table read and return the index 3 of myArray[i]. But all I got is negative numbers and all sorts of misleading reads.

#15

I think maybe you should just get to know Axoloti a bit better before attempting further. Ad you said, you are very new to Axoloti, I think you should explore a bit, then some of these things will probably fall in place over a little bit of time.

Again, the minus and the weird values are probably because of overflowing a type some where in the chain.

To me it does not look like you are using the input to actually read the array.

Drop the for loop stuff, I dont think you need it to be honest. If you want to read out the myArray, try something like this:
outlet_X = myArray[inlet_Name]
Then you use the inlet to read the table values.

Anyway.... Ill still suggest to explore a bit. There are so many other things you can do, that you can play around with and when you have a better understanding of everything, then try again.

#16

Hey Carlo,

welcome to the board :slight_smile:

I tried chaning the table to 16b and that will give not these weird overflows.
The next thing is that I think the values you have in the table are somehow scales to the range of 0-64 that axoloti uses for float values.

If you want to hook up a frequency value to a (note) pitch input of an oscillator you need to convert it. This what I found about this.

#17

Pasting your data to the init section of table/load array seems an efficient way to get your frequency data in there. Hang in there you’ll get it working..

Those overflows that Jaffasplaffa mentions are tricky...

The biggest thing for me is to start thinking about the way the axoloti does a lot of its work in integer. The great thing about the axoloti is you can go really deep into things and the board and software is so well provisioned.

#18

Hey @bds I would really like to see how you did that, use the init to load table data. I did try this before but with no succes, I got some error I didnt know how to fix.. Would you care to share a screenshot? I would highly appreciate :slight_smile:

Thanks!

#19

I have been trying to understand how the numbers you write in the table translate into the axoloti environment.

With an 8bit table it's clear.

0-127 as integers will translate to a range of 0-63,5 so you get always value of table divided by 2.

float numbers didn't work!

Bildschirmfoto 2018-10-22 um 14.42.24.png1206x1412 114 KB

When using a 16bit table the results where not that consistent...

#20

Hey there just hooked everything up with the 16bit table, and the result is 13Tet!

BlindDoctorKoma.axh (8.3 KB)

However from playing around with values in the init of the table I don't think the table really accepts floats.

That means you will have the frequencies rounded. In practice this means you will have more discrepancies from the intented tuning in the lower range and less in the higher.
(imagine you have 1hz and a 1,49hz value, theorically almost the intervall of a perfect fifth (practically out of the human hearing range) this would be rounded to to 1, resulting in the same intervall.

The more you go up the less dramatic this effect will be.

Eventually I think the best would be a dedicated object that can read multiple frequency files from sd card and convert them nicely.

EDIT: @johannes made an object that accepts scala files during Mtf 2 years ago, wich could be frequenciy lists as far as I know. Unfortunately I can't find the patch anymore...

#21

this can be made much more precise of course.

look at the remapaxis object i made the axis49 controller. while it is not what you are looking for exactly, it will give you strong hints.

the section in the k-rate code:


outlet_out= (reMap[(inlet_in >>21 ) + 63] - 64)<<21;

should get you started. i am reading out the reMap array (defined in the local data) with the values that come into the inlet. since those are fixed point numbers that represent midi values i shift them left by a factor of 21. (means 21times divided by 2) that gives me 7 bit numbers. i add 63 to that to get them into a range from 0-127.

now for your approach leave the - 64 and left shift out for the moment.

ask yourself this, how much precision do i want?

if you have a frequency for midi note number 60 (so the 60th place in your array) and it reads something like this in float: 320.32347 (just an example), you would

multiply that value x-times by two. if you want to go full resolution you would multiply the value 21 times by two and would not need the <<21 at the end of the code.

the -64 will then also become a much larger number. i.e. -64 multiplied by 21 times 2 as well (if you choose to multiply that much.

i hope this helps.

(as an aside i would still recommend to recalculate the values to something that represents midi notes rather then pitch. it would just work much better in the axoloti universe. so basically your 320.3247 hz would become something like 60.212393939 or whatever. you would then do the things i described above to that number)

the formula to convert from frequency to midi note number should be widely available...

#22

@lokki I’m using conversion from frequency to midi -64 to 64 and converting to 32uint outside of the axoloti but following the research I’ve been doing thanks to the thetechnobear’s advice you really need to be doing any conversions on the axo or another device that supports fixed point math and the Q number systems used on the axo.
Having said that the best way forward seems to be to follow johannes and the others model and use functional tuning on the axo itself. This could mean an init routine that sets up a array maybe even multi dimensional i.e. with an offset indexing scheme like thetechnobear hinted at. Try thinking about the intervals as functions. 2/1, 7/4 etc or algorithmic forms rather than floats then your using the number system on the architecture itself. Much much simpler.

I’m still working on it...I’m attempting to write a parser for files on the SD.

The axo is by all means a highly flexible system to use and should reduce the kinds of rounding errors and problems with overflow ( especially in the smaller Edo’s ) you’ll get trying to do things elsewhere and bringing them in from outside.

I forget where I saw it on here but I think it was lokki’s Remapper? that could also be pressed into service for keymappings too..

By the way Op de Couls Scala is a beast.

#23

@jaffasplaffa Floats have spoiled me too.

I'd love to know if this object still works on the axo.

#24

I love to work with floats.... When I can use them as they are and not having to do all the scaling/bitshifting.

I made a good bunch of modules for VCV rack and also made a couple of simple vst's and its just soo much simpler without all the scaling.

but Axolotis shines in other ways, but yeah, it would shurely be nice to atleast have a simple way of working with floats in Axoloti world, even though they maybe not be as efficient. Its not always about efficiency, in some cases simplicity is more important. By that I mean its not every patch one make that pushes axoloti to the limit. Sometimes I would rather use a little bit more dsp/memory and get to the result easily and quickly, using floats, than having to break my brain in the scaling process :slight_smile:

Microtonal patches broken in 2.0
#25

I've found the maquam synthesizer patch from music tech fest 2016 that contains @johannes scala file importer. I think johannes ported it from another open source synth.

Maqam Synthesizer.axp (17.1 KB)

#26

Amazing!!
Thanks for sharing this, I am going to spend some time pouring over this, pure gold.
I'll fire it up later today. :star_struck:

#27

How to use axolotis polyphonic voice assignment for this?

#28

I think you put the scale loader and the table in the mainpatch und have the table read in the subpatch, refering to the table in the mainpatch.

#29

true its working now....super yeah

#30

Yes so much fun!

Does someone have any Ideas how to turn this into a system that can load different scala files?

Could you replace the attribute with the filename with in inlet and then hook up several strings?

I tried this but I'm not so good with code. I guess I need to move the load aspect out of the init secion in the code but I don't know how.

Bildschirmfoto 2018-10-22 um 22.36.15.png1066x770 34.4 KB